pyro collisions

Something that a lot of people have trouble with is pyro and collisions. Often smoke will be “eaten” by the collision object then just disappear all together. This happens pretty much all the time if you have a large object moving quickly into small amounts of smoke. I spent some time trying to figure out how to solve this problem and I found some pretty interesting things about pyro and collisions. The smoke solver doesn’t seem to have “real” collisions. I came to that conclusion after adjusting the incoming velocity on my static object. Take a look at the gif. After disabling the velocity, literally nothing happens. Actually, the collision object will just delete the density inside the collision, but I disabled correct collisions for this illustration. After doing additional tests, it seems pyro collisions are doing two main things:
1. Delete any density that gets inside the collider.
2. Use the velocity of the collider to affect the motion of the simulation

That being said, if your static object is moving you need to make sure your velocities are setup correctly otherwise the collision won’t work as it should. To help solve the problem of the density being “eaten”, I usually will add more substeps, add more multigrid iterations, and multiply the incoming velocity on the static object to a higher value. If all else is failing, I will turn off the “use correct collisions” feature.

NaN, RBD, pop drag and Arnold

I was recently working on a RBD simulation with packed objects and I noticed that after a few frames the geometry would stop rendering in arnold. The strange thing (at the time) is mantra did not have this issue. I added a attribute/group delete to delete all the extra attributes, but I was still having the same problem. This issue would go away if I disabled my pop drag/pop spin drag forces. After messing around I noticed that turning on my drag forces caused some of points to have NaN values when the simulation collided with the ground. After adding a clean sop and checking remove NaN’s, the geometry seemed to render fine. If any of the points had NaN values, arnold would not render anything. While removing the NaN’s is one way to fix the problem, I found another solution: Increasing the substeps in the bullet solver until there were no more NaN values. Both these solutions can be used hand in hand to make sure no NaN values make it to arnold. The pop drag/spin drag (in my testing) only created NaN values for packed objects (with low bullet substeps). If I use those drag nodes on proper pops, the issue is non-existent. The issue is particular to bullet solver.