Hi there;

I have a FLIP sim that I'd like to run for around 1000 frames. I'm struggling with volume loss over that range though, and can't seem to figure out how to fix it. My colliders are slow-moving, and I can verify there's no water “leaking”. I can see my particle count decrease steadily over time, as if my tank is ‘draining’.

The few resources I've seen suggest strategies including:
–enabling Apply Particle Separation (I've done so, left values at defaults, see no visual difference)
–Raising Particle Radius Scale, which feels a bit like a cheat, and which effectively eliminates high-frequency details that result from a low Particle Separation value on the FLIP object.

I know this problem is an inherent one to FLIP solvers, but also know artists often create long FLIP sims to use with time offsets through multiple shots in production. I'm curious what other strategies I can take to minimize or eliminate volume loss?

Thanks!

On the flip solver under Particle Motion/Behavior try turning off Kill Outside Volume Limits.

We have a volume controller you can use to adjust volume up or down. The only real problem with it is figuring out what you want the goal volume to be (especially if you have sources…) But in static sims you can usually compute the volume of your initial fluid and use that.

Put down a Gas Equalize Volume DOP and check its help card for a help card example:

http://127.0.0.1:48626/examples/nodes/dop/gasequalizevolume/EqualizeFlip [127.0.0.1]

Hi Jlait, thanks for this response, I hadn't seen this strategy elsewhere. Could you provide an example HIP file that elaborates on setting this up properly? Or, may I ask for some elaboration?:

–How/where does one calculate the target volume? I'm not sourcing anything; I'm filling a tank with particles using pointsFromVolume at the SOP level.
–Where does the gasEqualizeVolume node itself go? Inside the FLIP solver or as an input to it (and, if the latter, to which input?) Tearing apart the FLIP solver isn't something I've done much of before (though I'm happy to learn).

Thanks!

Jeff's link to 127.0.0.1 indicates that it should be local on your machine.

I found the example file on my system at this location.
C:\Program Files\Side Effects Software\Houdini 16.0.589\houdini\help\examples\nodes\dop\gasequalizevolume

Put down the Gas Equalize Volume node inside of DOPs. Click on the ? on its parameters to get the help for that node. Scroll to the bottom and there are the example files that use that node. The Flip one is the one you want. If you already have the help server running, the link I provided would work.

Compute volumes by using the Measure SOP on polygonal geometry, set to “Volume”. The use Attribute Promote to sum these polygon volumes into a single Detail volume.

Ah, thank you so much Jeff/Enivob; I thought I had checked that help card for an example and missed it but I must have not had my coffee before doing so. This is quite interesting to learn about, thanks!

Though, I also tried Enivob's suggestion of turning off “Kill outside volume”, which, as it turns out, might be a super-useful debugging tool for my animated collider/tank situation here. I noticed before doing so that when I visualized velocity as a color, I had a few ‘pockets’ of what seemed like sporadic, high-velocity areas. I can't quite figure out where this is coming from, but when I disable “kill outside volume”, I see that these areas are creating big ‘splashes’, and I wonder now if my tank draining has less to do with volume preservation and more to do with these ballistic events pushing particles into the interior of my collider and then being killed.

I'm still debugging what exactly is causing this problem. To elaborate slightly, I'm reading my collider via a sourceVolume; it's a VDB with velocity fields, which are being created via a Trail sop. When I visualize the Trail, the velocities look totally sane and have nothing to indicate sudden transitions that might cause ballistic events. I'm curious if anyone has advice about other rocks I might look under to figure out what might be causing this kind of behavior?

Thanks!

Actually, investigating further, it appears that my collider might not be the problem, but rather a VOP force I'm using to impart forces on my flip sim. This VOP force outputs a Force, and is dependent on P of the incoming geometry. I'm using it in place of the default Gravity force. Is this an objectionable way to work? What would be the ideal way to create a custom force for pushing around FLIP particles?

For FLIP, I'd recommend instead to apply forces directly to the particles using microsolvers. You can use the POP VOP wired to the purple inputs to do this. Be sure to add to the force value, not replace it, however.

Hi sir, thanks once again. I'm trying this as you advise, and while it seems to replicate the overall force effects of my VOPforce, it also produces ballistic pockets of velocity. In the event that you have a moment to verify I'm not doing anything totally insane, I'm attaching a culled version of my HIP file here. The full version unfortunately relies on some rather sizable cached geometry, which I'd be happy to share but which I presume isn't appropriate to do so using the forum mechanism (perhaps Dropbox or something would be better?)

You do not need a pop solver, the flip solver already has one. Instead wire your pop vop into the “Particle Velocity” input of the FLIP solver (the first purple input)

Attached I've done that & cleared the paths (as your file refers to stuff not present there…) This causes a sphere to rip apart under your force since you have different gravity in Z than you have in XY.

Note this sort of pressure-force can be unstable, you are relying on pressure projection to remove it, so any asymmetry in your input will cause things to flow.

Hi sir;

Thank you for this. Indeed, I had things wired up this way before sending that last note, but saw no discernible difference in my sim, so I assumed I'd done something wrong, and added the (redundant) popSolver.

I've taken the liberty of tearing apart my scene and simplifying it to something quite a bit, well, simpler, and with no incoming dependencies. It demonstrates the oddness I'm seeing. Note that I'm gotten rid of the asymmetry you noted in the VOP, and things are still unstable. Could this be due to the fact that my collider is rotating, rather than exhibiting linear motion? The more I tear things apart and try to debug, the more confused I get at what I felt should be a relatively straightforward sim.

Another, even simpler test case for this problem. Note, if viewing though the ‘holes’ in the Y axis, the ‘popping’ velocity instabilities and slow drain of the particles through the collider SDF and into the origin. I can't see this behavior with the Gravity force.

I would recommend using deforming collision shelf tool rather than the collision source setup. The collision source works best for Pyro and isn't recommended for FLIP now.

The popping I think is being caused by vacuum forming behind the object as it frees up new fluid cells, the fluid is under pressure from your force so gets squirted into those cells when they become available.

In attached I've also changed it to move-outside collison and delete unmoveable to ensure nothing sinks to the core.

Spending the weekend converting my setup over to using that created by the shelf tools you mention (and fairly extensively trying to debug the very different and even more unstable behavior doing so led to), I think I must conclude this advice does't seem to be moving me in the right direction. The Deforming Object shelf tool, as you say, eschews Source Volume colliders in favor of Static Objects and the Collision Source macro. The latter of which is quite interesting, and through it I learned some new techniques, but the Static Object setup in my DOP sim now produces odd discontinuities in the collision velocity field for reasons that aren't clear to me. Source Volumes seem to produce drastically smoother and more stable collision velocity fields, with no visible discontinuities. It feels like the Static Object is extrapolating velocities in an odd way into empty cells.

First, note that for collisions only the velocity along the surface matter. However, these velocities are determined by finding the closest point on the collision surface & reading its velocity. In this case you have a tube which only has points at the far ends - this means the water near the sphere only ever sees stationary velocities, as there is no sample points along the arms to report local velocities. This causes the water to be surprised when the arms keep moving. To fix this, the attached adds a bunch of scattered points to the arms so there are points to read the velocities from. (This is also important for getting more accurate velocities with rotation as we only read linear velocity…)

Next, I should have checked this with the first file, since it is a very common problem. But with strange acceleration one should always double check colliders are doing what you expect in the sub-frames.

Bottom right corner of the UI, above “Auto Update” is a button to bring up the playbar controls.

Turn off Integer Playback, change step to 0.1. Then display only your collider and step forward. You'll notice it jump forward every half frame. This is because the rotation is set to $F which is integer frame, setting it to $FF will clear that up. As soon as the flip sims started to substep it would get strange teleporting colliders, thus strong discontinuities. The deforming object shelf tool hides this by turning on the “Blend Between Frames” option.

Hi Jlait;

Thanks so much for your patience and tenacity helping me here. I fear that my attempt to get you a good test scene has misdirected your troubleshooting efforts; the substepping thing is one I'm aware of, and exploring the CollisionSource node this weekend taught me about scattering points to gain velocity fidelity (a nice trick, I'm happy to have learned that). To avoid wasting more of your time, I've made a ZIP file that contains my actual production HIP file, a bgeo of some source geometry I'm using, and an example AVI file that shows my sim failing. To avoid weighing down this forum, I've placed the file here:

https://www.dropbox.com/s/es232y5uyydt2k3/flipProblem_production_1.zip?dl=0 [www.dropbox.com]
(this file includes a “_fbx” matchmoved camera which can be ignored…the meat is in “wheel_master”)

To the best of my knowledge, I've followed your advice throughout this thread:
–scattered points on collision geo to enhance velocity fidelity
–no $F dependencies
–use popVOP for my radial gravity force I'm trying to use
–no sourceVolumes, but rather using staticSolver for collisions

If you open this HIP and play it, you'll see that within 100 frames from sim start (which is fr 235), the sim becomes unusably unstable. This instability is much more exacerbated from where I started with this file, so I'm curious what you find that you may be able to advise me on repairing here.

Edit: To add more clues here: in the above-mentioned file, I have my min/max substeps on my flip solver set to 1/1, and substeps on my DOPnetwork itself also set to 1. I did a second test where I reset min/max substeps on the FLIP solver to their default values of 1/2, and set substeps on the DOPnet to 4. This produces the velocity discontinuity boundary artifacts that I mentioned earlier, as noted in the attached image.

Edit 2: I notice that when I compare the CollisionGuide as generated by the static solver to the collisionGuide as generated by the actual FLIP object, the two seem to be different (though they seem to have similar grid sizes). This seems either problematic or misleading: is the collision geometry being rendered onto two different grids (and, if so, wouldn't that inherently degrade accuracy)?


Thanks!
–a

I think the particles streaming to the center is because “Kill unmoveable particles” is off. So when particles inevitably end up too deep in the collision SDF they can't find their way out, they stay live and count against your total volume.

Anyways, from your file, some notes:

1) Large rotations like this might be best with the “Swirly”, or APIC, kernel as opposed to the “Splashy” or FLIP default.

2) Optimization: You can pre-scatter the points on your geometry before animating them. This avoids 0.5 sec substep of scattering time.

3) Optimization: The VDB resolution in collision source defaults to matching the fluid separation. But you can destroy the channel reference and build it at a lower resolution for faster results, especially when iterating & debugging. You can also turn off Fill Interior.

4) Optimization: The volume expression is pointing to the OUT_Volume which is Time Dependent. Thus you recompute that 1 second boolean every frame. Instead add a timeshift after the boolean and delete the $F expression so you only have to compute the volume once.

5) To understand what the equalize volume is doing better, you can turn on Add Divergence field on the flip object, then enable the divergence visualization. By default you get a two-tone plane that lets you know if it is trying to add or remove volume, so you can see if it is getting the desired direction right. You'll see it is desperately trying to add volume, so is correctly detecting the collapse, but isn't doing so with enough force. The “Integral Coefficient” can be boosted to do this. You can try setting the goal volume to zero and watch how quickly the volume collapses. With this test I had to boost it to 100 to keep things from compressing.

6) Substepping. Rotational motion is something that loses volume as the fluid cuts the corners as it rotates.

7) Collisions. In this case you have multiple rigid bodies that you've put into a single collider, forcing VDB creation every frame and risking something odd going on. For example, the VDB rasterization may pop between frames giving some spurious motion. Instead, if you could express them as separate objects and bring them in as non-deforming but rotating objects, it would be a help. This also means you don't have to worry about the extra points as the objects won't be moving locally. I understand this may not scale to other setups, however.

I've done some of those changes in the attached which I've simulated to frame 308 with it looking okay…

This is so, so awesome sir, I can't thank you enough for your thoroughness. May I ask one followup question?:

jlait
7) Collisions. In this case you have multiple rigid bodies that you've put into a single collider, forcing VDB creation every frame and risking something odd going on. For example, the VDB rasterization may pop between frames giving some spurious motion. Instead, if you could express them as separate objects and bring them in as non-deforming but rotating objects, it would be a help. This also means you don't have to worry about the extra points as the objects won't be moving locally. I understand this may not scale to other setups, however.

You know, I thought to try this, but then stopped myself thinking that rotating a VDB volume might be somehow bad, or at any rate would involve re-rasterizing the collision geometry into the solver space. Is that not true? Or, do you suspect that the performance gain offset any quality loss in doing this? I'm not at all opposed to doing it (and, indeed, would love knowing that this is a trick I can rely on in the future).

Oh, also: When using the “deforming objects” shelf tool, the flip solver's collision detection method is left at the default value of “particle”. Because I was advised, in previous versions of Houdini, to use the Source Volume method of collisions, I changed it to “move outside volume” for the scene I sent you.

Can you say which is preferable if I'm using this Static Object method of colliders? I'm a little hazy on what exactly is happening (there's a VDB generated by the collisionSource node, but also some geometry; you advise above that I might statically-create a VDB, and then rotate it, which would mean the vdb wouldn't have any velocity field, so presumably this new method involves calculating a velocity field independently of a collision SDF, true?)

All of this is to ask: if I leave the solver set to using “particle” as the collision detection method, “kill unmoveable particles” seems to be greyed out. Why?

Thanks!
–a