Creating a Pile of Sugar


#1

https://orig00.deviantart.net/03fa/f/2013/151/3/c/sugar_style_by_sonarpos-d679fqn.jpg

I need to create the flow of sugar over a text SUGAR ,with particles creating a pile like in the image. Text wil be on the floor. I haven’t even tried but, I don’t think it can be solved with the real amounts of partices. I mean do particle systems create such high piles and does the computer handle the particle amounts?
I primarily need help with geometry but an efficient sugar material is also appreciated.


#2

This is for snow, but looks like it can be modified to work for sugar:

http://hasenjager.cgsociety.org/art/snow-maya-arnold-material-studies-17727550


#3

I guess this is for Maya.
I primarily need help for particle piling.

Thanks anyway.


#4

3D application not important, it is the renderer in which the settings are applicable.

For 3ds max a plugin is necessary. Probably this one.

Although, 3ds max 2019 has a fluid sim so you might be able to cheat with the right shader.


#5

Maybe you don’t need “real” physics simulation for this stuff at all.
Try using Pflow with deflector (floor) and UDeflector (text)), and make particle stick to it (maybe a little jump, and slide), after they touched it.
Use Drag spacewarp to slow them up gradually.
That way, you can go with hundred of thousands of particles, even millions (if you’re using Krakatoa, or render in few passes).


#6

but without particle-to-particle collisions, there will be no piles, just a light dusting.


#7

Well, in the reference he provided, there is also no pile… just a flat distributed sugar over the floor and text.

P.S. After all, in some cases, you can fake piles also. Just animate geometry deflector rising . :slight_smile:
II’s not always a best solution, but work pretty well for some. :slight_smile:


#8

If the sugar object is static, not moving, you can do this with displacement or pflow. If it needs to simulate, realflow handles granular particles really well. You can pass that realflow sim through vray via prt loader or use thinkbox’s krakatoa.


#9

Theoretically, it can be done with mParticles in a scaled-up scene where each grain is 10mm. However, I’m not that masochistic.


#10

Indeed, I think Realflow was used for Sandman in Spiderman 3? but quite expensive if you don’t have it already. No, Houdini


#11

Not theoretically…practically…yes I’ve done proof of concept using mParticles…THEN…you bang your head against the wall and say…I’ve got all these cores sitting around do nuffin’ coz it’s not multithreaded !!!

Hey wait just a second…there’s Multi Threading in mP World…lemme try that !!!

meh…modicum improvement…not getting aroused at all…


#12

proof…works…

The faux mountain just needs to have the same texture as the sugar cubes applied and you’d have a hard time spotting it…

//youtu.be/P8lTKfaMSoU


#13

mParticles seems to be workable with a stream of a few hundred-thousand particles over about 200 frames if you insta-bake it. This way not all particles are moving at the same time and you can go and do something else while 3ds max slow bakes it. You can even use the same computer for other tasks because 3ds max seems to use only about 25% of the processor even with muti-threading enabled.

Argh crap. the majority of the particles went through the ground plane. Works with a 20,000 test but something goes wrong with higher numbers for some reason.


#14

I had to go to 1/8 integration step to get it to play nicely…


#15

I think I’ve read somewhere that official limit is 40.000, but yes, also in my expirience, it starts to hang and bug at 20-25.000.

Another option for the starter of this thread (where is he?), is that he can maybe try new 3DS Max fluid system.
I never tested sand, or sugar type of sim, but it should be doable, if he manage friction parameter.


#16

A few months ago, the PhysX SDK had a limit of 65536 rigidbodies, due to some internal counter being an unsigned short data type. Going higher wouldn’t result in a crash, but collisions would start to be missed. That was recently fixed. If you plan to go higher with mParticles you’ll have to wait until they rebuild the official plugin with the latest PhysX SDK.


#17

Mparticles seems to be doing the job.:thumbsup: What is the scaling object under the particles? Is it a deflector or what?


#18

well it’s not scaling…just moving up…think about it…if you see a mountain of sugar cubes do you really need to have the actual 2 trillion cubes ‘internally’ that can never be seen ?

If you WANT to crash your machine with 2 trillion cubes…well that’s one way to work I guess…just not mine…

Just set the friction on that object (collider) to 9999 so whatever it touches, it sticks…


#19

Originally Posted by ivanisavich:A few months ago, the PhysX SDK had a limit of 65536 rigidbodies, due to some internal counter being an unsigned short data type. Going higher wouldn’t result in a crash, but collisions would start to be missed. That was recently fixed. If you plan to go higher with mParticles you’ll have to wait until they rebuild the official plugin with the latest PhysX SDK.

Ugh… dreadful 16-bit limitation (like the cache op memory cap, mostly fixed apart from the UI). It has been there since the beginning, I don’t think Oleg worried about it much simply because one PhysX limitation in 2.8x and none of us could get more than 40k particles to do anything in a meaningful amount of time. PhysX 3.x has been out forever (like 6 years), it has so much more in it by comparison, since max is part of the auto desk juggernaut we have to wait our turn to get any improvement, and sadly who knows when that we’ll be.


#20

and although you can download the physX 3.x 3ds max plugin from Nvidia, it breaks some things altogether. It also messes up the UI when you uninstall it as it overwrites the massFX bit and doesn’t undo the changes it made.