Hi Guys,

While I get my head around the new Pop Dop workflow (yes, just updating to it now…) I am wondering what the best way is to handle simple collisions.

I have taken a stab at using the Static Object DOP which seems to work in most cases.

However, I have some really high geo to collide against, and I would like to collide directly against an sdf of the geo. When using the Static Object, there is a very slow caching stage I'd like to avoid.

My next thought was to try using the Gas Collision Detect node directly. However, I have no clue how to get this to work. Or if it is even the right idea…

I have attached a file with my current setup. Any pointers and guidance you guys have on using these heavy colliders in POP Dops is much appreciated!

cheers,
-j

You can already , just make your object a volume and also select it as a proxy volume

circusmonkey
You can already , just make your object a volume and also select it as a proxy volume

Note that in H14 the Deforming Object shelf tool will set this up for you. If your object really isn't deforming, just uncheck Use Deforming Geometry on the resulting Static Object DOP.

Internally the Gas Collision Detect and Gas Integrator use the same code path for SDF collisions, and both were significantly optimized for H14.

Hi Guys,

Thanks for taking the time to reply. I realize my first question was a bit misguided. Circus, I have used the static obj/proxy vol trick in the past with some good successes.

After going through your file, I realize I should have just asked, how can I make POP collisions faster. I have attached an updated file with 3 different sim setups.

1) DOPs collisions with the static object.
2) DOPs collisions hacking a vop sdf collider
3) POPs collisions using a sdf collider

While I can't get the #2 to work properly (DOP POPs seems to have a lot more to think about when it comes to resetting a particles velocity) you'll notice that it is almost 20x faster then #1 (this time difference grows exponentially with an increase in the SDF resolution).

Looking through the performance monitor. For #1, It seems the biggest slow down is the collisions on the particle integrator.

I guess my question is, how can I get #2 to work. That is, read in my own SDF, ignore the POP DOP particle collisions (slow), and have a stable sim? Is there a DOP node that helps achieve my goal, can I achieve it in VOPs, or is it all under the hood.

thanks!
-j

jacob clark
While I can't get the #2 to work properly (DOP POPs seems to have a lot more to think about when it comes to resetting a particles velocity) you'll notice that it is almost 20x faster then #1 (this time difference grows exponentially with an increase in the SDF resolution).

Looking through the performance monitor. For #1, It seems the biggest slow down is the collisions on the particle integrator.

I guess my question is, how can I get #2 to work. That is, read in my own SDF, ignore the POP DOP particle collisions (slow), and have a stable sim? Is there a DOP node that helps achieve my goal, can I achieve it in VOPs, or is it all under the hood.

Ah. The time you're seeing in the particle integrator is actually when it builds the collision object's internal DOP SDF on demand. In other words, that's when the actual Volume Sample from VDB to DOPs SDF is happening, which is why it gets slower at higher res. The actual particle collisions themselves are quite fast once that conversion is done (less than a millisecond in this example) and should scale well to many more particles, at least in H14.

You could use the File Mode on the Static Object to write those converted volumes to disk in the internal DOP format as .sim data, but that just moves most of the time to loading the data from disk since now it's a dense format instead of the sparse VDB. (Though that is a good way to verify that it's not Gas Integrator's collisions taking all the time.)

Unfortunately all the built-in DOPs nodes assume the SDF data is somehow accessible as DOPs data, whether as collision SDFs on objects or scalar fields, so either way you have to first import / convert them to DOPs somehow.

You could write your own POP Wrangle that volumesamples from a VDB directly and uses the result of volumegradient to get a normal, plus maybe point clouds to get the nearest point velocity, but none of that is really easy. Also the internal SDF collision code does a lot to sweep out the collisions over time and get watertight collisions even for fast moving particles. But that would be your best bet.

So I guess the good news is if you use regular DOPs SDF collisions, your setup shouldn't get much slower for very large numbers of particles; the bad news is you have a significant baseline cost at that high a VDB resolution.

Another option is to turn off Use Volume Based Collisions, which skips SDF creation altogether and just uses the polygons. Depending on the resolution of your mesh that may or may not be faster.

Either way simplifying / reducing complexity on the mesh as much as possible is a good idea before sending into DOPs.

Thanks for the thorough reply, Johner.

Due to the nature of the shots I am working on, it doesn't look like the collision shapes will get any simpler. I do enjoy that the Pyro solver can use a straight volume field for collisions. I would love to see a similar simple/quick treatment applied to POPs.

I can stick w/ old POPs for now, and can't wait to see if there are more speed improvements on this collision model ( bypassing of the sdf rebuild? )


thanks again!
-j

jacob clark
Due to the nature of the shots I am working on, it doesn't look like the collision shapes will get any simpler. I do enjoy that the Pyro solver can use a straight volume field for collisions. I would love to see a similar simple/quick treatment applied to POPs.

Hmm, well the Pyro solver does have to import the VDB into DOPs, in this case into a temporary scalar field that it then unions / adds into the existing collision fields, inside the SourceVolume asset. I'm a bit surprised it's much faster, since it's a similar operation of sampling VDBs into Houdini native volumes.

Maybe because the Pyro collision fields are lower resolution than the VDB? Static Object's Volume Proxy mode always creates an SDF of the same size / resolution as the input VDB before sampling into it. So you might be seeing better sampling times just due to the lower resolution collision field in Pyro?

jacob clark
I can stick w/ old POPs for now, and can't wait to see if there are more speed improvements on this collision model ( bypassing of the sdf rebuild? )

Have you tried turning off Use Volume Based collisions and using straight particle->poly collisions? I'm not familiar with old POPs collisions, but I think that's all it's doing. (if maybe using a different code path)

I'm not familiar with old POPs collisions, but I think that's all it's doing. (if maybe using a different code path)

I should have mentioned, I was referring to VOP SDF Pop collisions.

Take a look at #3 in the last file I've uploaded.

I have found one of the best ways to collide particles is to write a custom POP VOP that bounces particles against an sdf. I have put a VERY simple version of this in the POP sim.

The speed gain is tremendous.

Sadly, when I tried to port the same VOP setup to #2, DOPs. The particle integrator did not play well with the custom velocity changes

jacob clark
I should have mentioned, I was referring to VOP SDF Pop collisions.

Sorry, I misunderstood. You're right there's nothing built-in to do particle-SDF collisions without bringing the SDFs into DOPs. It has been requested in the past (RFE: 65193)

jacob clark
The speed gain is tremendous.

Investigating this I realized we were doing an excessive amount of work in Volume Sample mode when the incoming collision SDF has no transform on it (i.e. Use Object Transform is off), as in your case. For that setup we can just copy the raw voxel values into DOPs rather than sampling in world space. I made the following change for tomorrow's build:

Houdini 14.0.228: Wed Jan 28 15:21:45 CST 2015
Optimized the Volume Sample mode for importing collision SDF's
for the Static Object DOP, when its Use Object Transform parameter is off.
Also updated the Deforming Object shelf tool to turn off Use Object
Transform when the collision object has no object-level scaling.

For your test file this dropped the GasIntegrator average solve time from 139ms to 5ms. Total time is not much higher than the VOP solution, although you do still have to deal with the large collision object filling up your DOPnet cache. On the plus side the collisions will be much more accurate, and in general I think you'll find DOP POPs much faster than old POPs once you scale up to high particle counts.

Please let us know if you get a chance to try this fix.

Thank you, sir. I will take a look!

-j