mParticles collision with animated surface


#1

Hi there,

while mParticles in general seem to be quite buggy (at least in max 2014), I´m having a particularly hard time making them collide correctly with animated surfaces.

What I´ve tried so far:
-Lower integration step to 1/8
-use custom shapes in mPShapes OP
-decrease interpenetration tolerance in mPShapes OP
-in Pflow Collision Shape modifier switched between “fit by current frame” and “fit by minimization”
-give more thickness in Pflow Collision Shape modifier (there is a limit how far you can go without the collision shape differing too much from the original).

I´m still having way too many interpenetrations where the particles just go through the animated object.

Is this just based on some restrictions or can I somehow improve this?
What are your experiences so far?


#2

Enable all but Selected Only of the Collision Shape animated mesh options (ie Vertices, Edges, and Polygons) then Select the World and increase your Subframe Factor, I usually go straight to 10 depending on (speed/size/count/glue binds/ect. will of course determine help your minimum subframe steps) then either increase or decrease from there.


#3

Ok, so now I´m confused:

I thought I could make the sim more precise by increasing the Integration step in the Render Op/ Cache Op…

So why do I have to controls now for step size and when do I need which?

Also I just noticed that I had some maxscript warnings about my collision hull and when I checked my mesh again, I noticed that I had some open edges.
Fixed those first and then applied your tips and now it seems to work WAY better.
I don´t have more time to test this with higher steps then your recommended 10, but i can take care of the interpenetrations via the incredibly useful Data preset “Delete by ID”.
Which I now can use since I also fixed another issue:

The incredibly bad playback after caching.
As far as I knew I only had to cache the flow and then it should play back smoothly.
But apparently i also have to turn of the mPcollision OP after caching and now it doesn´t take forever to update whenever I scrub the timeline.

I also used the Cache Op to exclude the shape from caching.
I previously thought this wouldn´t make much difference and I wasn´t sure this would work properly with mParticles, but apparently it does and I feel like it also speeds up cache generation considerably.


#4

wow. Cache file size went down from 8 MB per frame to less then 50 kb per frame with “Exclude shape”…


#5

The Viewport Integration Step, which is really what you are using to run your simulation, not the Render Step, was not accurate enough at only 1/8 frame, equivalent to 8 Subframe Samples. It was discovered early on that having the ability to add more substep calculations were needed when there were: really fast moving particles, a high number of collisions, then when glue was introduced later in beta that you needed a great deal more to ensure proper binding/breaking.

Truly the parameter name of Subframe is not accurate either, you are getting xNumber of Subframe samples per Integration Step. So in reality if you were patient enough you could get 1600 samples per frame! Ten samples per tick @30fps :slight_smile:

Excluding the Shape is mostly useful if you plan to exchange a low level of detail particle with high LOD particle. Is it certainly the largest portion of the cache file, somethings like the transform matrix, a vector location for every vertex of the shape, not totally sure which other data is associated with Shape off of the top of my head. The rest are just a few vectors, position, velocity, rotation, ect. IIRC.

Scrubbing a cache has always been a bit off. If you turn on the Particle View-> Options Menu->Track Update->Update Progress you will notice what operators/tests are being evaluated during playback. Try turning those operators off, except for Display of course, your particles will not be visible.

In a Cache Disk scenario only the Render, any Excluded Channel operators/test, and Display should be evaluating. That is of course assuming your Cache Disk is in the global/Source node. Local/Event nodes can have there own Cache Disk too in which everything downstream from the Cache Disk Event will get cached. Then Evaluation exclusion should start from the Cache Disk event downstream.


#6

Ah, great…yeah, that was very confusing, thanks a lot for the detailed explanation!
I always prefer actually understanding what is going on and why, instead just “hotfixing” it…

I´ll check the “update progress” option next time I´ll have to deal with this, that sounds like a great way of troubleshooting!

My particle shapes are usually not THAT hipoly, unless you consider 7-8000 polys hipoly, I don´t know though if particle count makes any difference with Hipoly Particles, but I remember having had Pflows with 50 MB or more per frame cache files.

So what kind of range should I be dealing with with lots of collisions/glue bindings etc? would you consider 10 Steps be on the lower end of things?