You can use a network of Fetch ROP nodes in /out to do this. Create a FileCache node to save out your RBD sim, then point one Fetch ROP at its internal “rop_geometry1” node. Then use another Fetch to point at the import_fluid's “render” node.

Plug both of these ROPs into a Merge ROP, then just Render from the Merge. The default order is Frame by Frame, so for each frame the RBD will write out, then the fluid.

You could just use merged Geometry ROPs instead of Fetch-ing if you like, but I personally prefer the workflow of having FileCache and DOP I/O inside my network.

roughsporty
So I recreated the whole scene and it worked. The shaft_emission generates constantly fluid particles. After saving yersterday and opening it up today I have the same problem as in the beginning.

There is a problem with the Emitter_River that I believe is causing your problem, although I don't know offhand why it would suddenly work and then not work. To confirm this you can just disable that emitter temporarily and see if it fixes the problem.

A little background on FLIP emitters: A FLIP emitter generates both particles and a surface SDF, the latter being used to union with the existing surface SDF in FLIP. The SourceVolume DOP uses the surface SDF to cull any newly-emitted particles so that excess particles aren't added where the surface already exists (assuming Kill Inside is still on, which it is here.) In setups like yours with multiple, custom emitters, it's very important that each emitter create the proper SDF, since it's used to cull particles for any later emitters. An incorrect SDF can lead to particles from later emitters getting incorrectly culled, which I believe is happening here.

Your setup Emitter_River tries to ensure that the emitter tightly fits the carved-out part of the riverbank, using an SDF of the extruded riverbank for culling. This is correct for the particles, but not the surface SDF. You've got volumemix1 just copying over the riverbank SDF to use as the emitter's surface SDF, which isn't correct. This should be doing an SDF subtraction, so in this case you need to invert the riverbank SDF and Maximum it with the emitter, i.e. change the Source Pre-Mult to -1, and set the Mix Method to Maximum. The incorrect SDF was killing particles that came out of the Shaft_emitter, since it came later in the DOP Network.

sabotage3d
I tried to do a simple surface tension test which was working perfectly in 12.1.
Now it seems the solver breaks with certain values. Is that an expected behavior. The error is in the Gas Project Non Divergent Variational - Projection solve failed .

Pretty unusual for the projection solve to fail, but I imagine it's because the sim is blowing up due to a bug in GasSurfaceTension in 12.5.

You'll need this fix:

Tuesday, April 23, 2013
Houdini 12.5.384: Corrected a problem in GasSurfaceTension that led to incorrect forces being applied for face-sampled velocity fields.

alejandro
Thanks for the info Johner, I'll give a try!!!

Great, let us know how it goes! Just to be clear, the fix didn't make tonight's build, so it's “tomorrow” as in Thursday, I believe.

alejandro
The default surface tension node works, but is very slow.

The good news is the GasSurfaceTension DOP was multithreaded and optimized for 12.5. The bad news is there was a bug in it that made it give incorrect forces. This is fixed in tomorrow's build (12.5.384), so I'd encourage you to give that a try as well.

stooch
actually upon closer investigation your surface tension does impart some tumbling. Sorry, I had allot of unresolved flip particles which were concealing and reducing the apparent effects of your microsolver. After tuning sub-steps and sampling distances, i got the particles to stay resolved (its a pretty high speed sim).

As you may know, you can turn off the unresolved behavior altogether by setting the Under-Resolved Particles to No Detection. For a high surface tension look you might want to do that, coupled with increasing the Particle Radius scale by a bit, say to 1.5-1.7 or so.

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]

I started a new VDB / collisions thread here [sidefx.com] to avoid cluttering up this thread.

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.

(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.

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?

Well, for FLIP the 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.

Use a Name SOP, and just give the primitive numbers the proper names:

0 -> surface
1 -> vel.x
2 -> vel.y
3 -> vel.z

As you've found, that attribute is used for more accurate particle collisions, basically storing the previous position so it can do some interpolation to avoid interpenetration.

If you switch the Collision Detection to Move Outside Collision that attribute will not be created, and collisions with moving or deforming geometry will be less accurate (but they will be faster!)

JordanWalsh
cool, thanks for the tips!
So is the cache just there for collision objects and not the actual sim?

No, it's there for the sim, and very helpful with medium-sized simulations. But past a certain size simulation, there's not much chance that it will all fit in memory (even on a 24Gb machine), at which point it starts paging to disk and gets pretty slow.

Glad to hear things are working now.

On that note, whats the best way to use the cache amount?

I'd recommend turning off Allow Caching on the FLIP FluidObject, since then you'll never risk running out of cache due to particle count. I also usually turn off Allow Caching to Disk on the DOPNet, since 1) it can be slow once you hit the disk, and 2) you're not surprised when things work differently in the UI from hbatch or hython.

With those settings a 1Gb cache or so should usually be plenty, since you only care about caching the collision objects.

What do the Cache settings on the DOPnet look like? If you're using DOPs collisions (i.e. your collision object is a Static Object), then DOPs needs the previous frame in the cache to compute good collision velocities, especially while substepping the FLIP sim.

It's possible that if you have really small cache settings, then that one frame is not fitting in memory and is being cached to disk when running in the Houdini UI. But Cache to Disk defaults to Off for non-interactive sessions like hython or hbatch, so you won't get good velocities when simulating on the farm.

Just a theory. What do those parameters on the DOPnet look like?

Edit: another thing to try is to turn off Allow Caching on the Creation tab of the FLIP Object, since it's really only important that the collision objects are cached.

Houdini 12.1.30: The FLIP Solver has a new option to add a unique id attribute to each particle. Additionally, the Reseeding operation has been updated to properly create new ids when generating new particles.


Also in 12.0.706

Did you set the animated parameters on the Fan Force to “Set Always”?

icarus551
I was shown a similar solution which is correctly theoretically, but if you compare it against the dop computed curl they don't even look similar.

I ran a 2D smoke sim (xz axis) to compare. Curl vectors of a 2d field should all point along one axis (y axis). The dop computed curl does this but none of the sop solutions do.

Hmm, I'm not seeing much discrepancy. The attached 2d smoke test creates a curl attribute from both a DOP GasAnalysis-generated field, and the SOP solution. The values aren't identical, but are very close. Switch the smoke sim to 3d and the values are still very close.

The VolumeAnalyis SOP should really have an option to calculate the curl, but in the meantime you can compute the gradient of each velocity component and calculate the curl by hand in VOPs (thereby doing a little extra work: nine derivatives instead of the six minimally required).

See attached for an example of computing the curl of a FLIP sim (and turn on the curl attribute visualization).