My wish would be an OpenVDB-based Flip solver variant. (…)
You can use a VDB sdf directly into dops for collision (…)
PS: I don't know if Houdini convert internally to standard volume primitive, (…)
AFAIK it does convert it. (Although the net result might be faster, easily).
What I'm talking about is to use VDB volumes to represent the velocity volume field of a flip fluid, for example. Ideally, this would mean much more efficiency and precision.
Right now one thing you can slow flip fluids to death is to try to simulate multiple thin strands or “squirts” of fluid, because:
- you need a very low particle separation value to get the fluid details right (if you don't have it, Reseed might even just kill your particles and you'll have practically no emission) – this means a high velocity volume resolution, internally
- once there's multiple streams, the simulation's overall bounding box starts to grow, and due to the high-resolution velocity (etc) fields, it slows down after the first few frames.
There might be technical difficulties I'm not aware of, but if all the internal volume fields of FLIPs were represented with VDBs, it would probably be much faster and more accurate (due to VDBs adaptive resolution nature). Even the FLIP solver's volume limits would became an utility instead of a necessity (ie. it's there to limit the growth of the flip fields).
Same thing goes with the SDF representation of rigid bodies. I find Houdini's RBD solver quite stable and accurate, but the SDF representation can be difficult to generate for things like:
- thin geometry that are not axis-aligned (e.g. a long thin box, rotated 45 degrees around two axes)
- self-intersecting geometry (e.g. parts of a skinned character)
Again, the sparse or “adaptive” nature of VDBs would help a lot.
FX Supervisor | Senior FXTD @ Weta Digital
qLib -- Houdini asset libraryhttp://qlab.github.io/qLib/