(This is a topic moved from this thread [sidefx.com] to avoid distracting from that generally useful topic of H13 wishlists.)

riviera
This is an “interesting” shortcoming, especially that there _are_ SDF-related vdb functions, so clearly it's an intended use, but this behaviour complicates things. Is there no workaround for this behaviour?

For FLIP a collision SDF only needs to be accurate within a certain bandwidth, namely enough to correct any particles that end up inside the collision objects, using the gradient to push them outwards. You can increase the bandwidth generated by VDBFromPolygons using the Exterior Band and Interior Band parameters, in either voxel or world space.

I've had success using 4 * FLIP particle separation for cached .vdb's, using the largest particle separation I'll frequently be testing with. While the resulting VDB won't be quite as compact as with a really thin bandwidth, you'll get good collisions.

This is a simple test of using VDB From Polygons to create both a collision SDF and collision velocities at the same time, then brought into FLIP using SourceVolume:

https://s3.amazonaws.com/vfx/zombie_vdb_source_vol.mp4 [s3.amazonaws.com]

Then those same cached VDB's are used as a VolumeProxy and sampled at half-res into a StaticObject for use in a (totally gratuitous) whitewater sim:

https://s3.amazonaws.com/vfx/zombie_vdb_source_vol_ww.mp4 [s3.amazonaws.com]

I tested at higher-than-necessary res for the VDBs: the VDB file containing both the SDF and collision velocity was about 28Mb per timestep, at a max res of . A character walking through water like this is a bit of a torture-test for FLIP, so good collisions are a must.

I can make post the .hip (without geometry I'm afraid) if anyone's interested.

alejandro
Hi Johner,

What type of collision method did you use? particle or move to iso?
Because I have serius problems with the particle based method (particles leaking thought objects) only when I fetch the collision field and velocity with a source volume.

The Particle collision method doesn't work with SourceVolume collisions (which I'm afraid probably isn't documented.) That method uses the DOPs particle/SDF collision detection, which is very accurate and fairly fast, but it only works with DOPs collisions, i.e. when the collision is represented by an actual DOP Object that has its own collision representation; it's not using the collision field at all.

With SourceVolume you're directly manipulating the collision field, so there's no DOP object representing the collision. So you have to use Move Outside Collision, which you really should prefer anyway as it's faster and generally yields “smoother” collisions. However, it's not as accurate with thin or fast-moving geometry, which is why it's not the default.

Note that any DOPs/particle sim like Whitewater needs an actual DOPs object for collisions, as there's no collision field in that case. As you pointed out in that other thread, you can use VDB's as collision sources for DOPs objects by pointing the VolumeProxy parameter at it and using VolumeSample as the SDF method.

But for complex, hi-res deforming characters in a FLIP sim (where I'd recomend VDB), you're probably better off just going straight from cached VDB files into SourceVolume. The dataflow in that case goes:

- SourceVolume asset creates a source field aligned with the collision field
- A SopSolver fetches from your VDB source, cooking either a VDBFromPolygons or (better) cached File SOP
- Once the SOPSolver cooks, it samples that VDB into the source field (multithreaded)
- SourceVolume uses a GasCalculate to merge the source field into the existing collision field (aligned and multithreaded - very fast)

Note this workflow does not use FluidSource for the collision SDF; it uses VDBFromPolygons for creating both the collision SDF and velocity fields, as it's faster, more robust, and creates smaller files.

The alternative is to convert the VDB to .simdata files and cache them, but you're still loading from disk then sampling into a field the size of the collision field, i.e. only slightly less work than with VDB/SourceVolume, but adding another file on disk.

I've attached the zombie_walk file that shows this setup, without the geometry unfortunately. And a cleaned up version of this discussion should end up in the documentation.

And here's a similar setup applied to a really nice file from Igor Zanic (aka CeeGee).

The whale has a regular setup then one with a custom sticktion force applied to get more sheeting as it emerges from the water. That works reasonably well, but then messes up the splash afterwards; I should have animated that force down before it re-enters the water.

For the whale, each VDB file was 11MB for SDF and vel, for a max res of .

Flipbooks:
https://s3.amazonaws.com/vfx/whale_vdb_sourcevol.mp4 [s3.amazonaws.com]
https://s3.amazonaws.com/vfx/whale_vdb_sourcevol_sticktion.mp4 [s3.amazonaws.com]

Hi Johner,

Thanks for the tips!!!

Really great tips, thanks a lot Johner!!

Hey Johner,

This seems like a very good tip however i can't get this to work. Cached my vdb volume to disk, try reloading it in DOPs with a source volume plugged in the volume velocity input of the flip solver but I don't get any collisions..

Am I missing something ?

Cheers,

Steven

I believe you have to turn off the option “Use Volume Based Collision Detection” on your RBD Object DOP to use the Proxy Volume parameter set to your VDB surface volumes to use as collisions.

Silly me… All good thanks a lot Jeff

Thank you Johner for this VDB tips!

I have just one question that really puzzles me (relatively new user so bare with me hehe). I noticed in your file that you have value of -1 on “scale source volume” parameter in the “source volume” node in DOPs. If I change it to 1 (which is the default value when sourcing from shelf tool for example), the fluid just collapses down.
Does it have anything to do with the way that volumes are created by VDB and “regular” fluid source node?

Thanks in advance to anyone who can explain this.

Cheers,
Sasa

Only problem with this workflow, and correct me if I'm wrong,
is that DOPs internally is still using regular volumes to
represent fields or grids.
So it is quite efficient to create the SDF using VDBs but
when they are added to the collision grid they are converted
to regular volumes, loosing most of the benefit of the VEBs.
Which will be great is to have the option to create VDBs
grids in DOPs.
Thanks for the examples.
Cheers

sabudimir
Thank you Johner for this VDB tips!

I have just one question that really puzzles me (relatively new user so bare with me hehe). I noticed in your file that you have value of -1 on “scale source volume” parameter in the “source volume” node in DOPs. If I change it to 1 (which is the default value when sourcing from shelf tool for example), the fluid just collapses down.
Does it have anything to do with the way that volumes are created by VDB and “regular” fluid source node?

Thanks in advance to anyone who can explain this.

Cheers,
Sasa

This is because DOPs collisions works with the original SDF signed order, positive values inside and negative values outside.

alejandro
This is because DOPs collisions works with the original SDF signed order, positive values inside and negative values outside.

Thank you very much for the explanation Alejandro, much appreciated!

Is there a way to use an OUTPUT DOP to save the simdata collision from inside the dop object?

I hope it makes sense.

Thanks.

Sure! You can use a dop node to save the Volume subData to then reuse again, like a naiad workflow, compute and save collisions then fetch collisions to less overheat sim.

alejandro
Sure! You can use a dop node to save the Volume subData to then reuse again, like a naiad workflow, compute and save collisions then fetch collisions to less overheat sim.

Thanks for the feedback.

My question is what subdata exactly? I tried to use a DOP ROP in the /out directory and pointed it to the “volume2” node inside the DOP object a RBD static object to be more precise, but if I try to use the simdata to be read in the object DOP that I got an error saying that is not recognizing the data, can you tell me what I could be doing wrong?

Use a file data dop node and look for the Geometry/Volume subdata, save the it, and then you can load it with the same file data dop node.

Hope that helps, the dops data thing is a bit obscure sometimes.

I'll try that thanks!

It seems that only the file data DOP and Isooffset SOP save .simdata files, to make it work I have to set file mode to WRITE and play the animation, I couldn't find a way to use an OUTPUT ROP to save this kind of data to the disk, so how I would use a farm to save it?

Any tips?

Why aren't you just generating the sdf in sops and using it in dops for your collisions?

With the simdata I can use DOPs format directly without have to sample them from SOPs into DOPS, but yeah I can create them on SOPs but they will be sampled in DOPS either way, so saving them directly in DOPS data seems a good option. Am I wrong?