Jump to content

H12.1 FLIP sim changes with resolution


Recommended Posts

I've got a very basic and standard setup for a sphere moving through a rectangular container half filled with water. All other settings being the same, when I vary particle separation, the simulation changes significantly. It looks like the collision velocities increase with increase in resolution, as demonstrated in the images below.

Velocity Type: Point

Collision Type: Volume

Collusion Velocities: Point

Smoothing: 0 (i.e., Purely FLIP)

Ignore Mass of particles: True

Particle Separation: 0.2


Particle Separation: 0.1


Particle Separation: 0.05


As you can see ... the high the resolution, the more "reds" there are in the velocity field. I think this is causing the significant change in simulation results across different resolutions.

Any ideas why this happens? or how I might work around it?

  • Downvote 1
Link to comment
Share on other sites

For the last 1231255135454543 years, every time I changed the resolution of a fluid simulation I got different results, and not just in Houdini but in every fluid dynamics software.

For SPH methods this is usually pretty easy to explain: more particles = more interaction between them = different behaviour.

Regarding FLIPs,even not knowing the code "inside" Houdini´s FLIP solver, if I understand it correctly, we´re talking about a solver copying the particle’s velocities onto a grid. At the grid the solver uses a non-divergent magicthingamajicwonderfulthingy method to calculate a new velocity field, and then copying this new velocity field back onto the particles.

So, again it makes perfect sense to me that more particles change the actual behaviour of the simulation.

Now, as for how to obtain the same results on higher resolutions, you´re basically asking for an upres method for FLIPs, which AFAIK it´s not included into Houdini...yet.

If you plan to do or prototype one yourself, this might prove interesting http://zaharidichev.com/2012/02/velocity-transfer-particle-data-expansion/

Hope this helps.

Edited by Netvudu
Link to comment
Share on other sites

You can always run the low res simulation, cache the vel volumes to disk and then run a high res sim copying those vel fields directly in to the high res vel volumes in to the vel fields.

What you get is a higher res sim but heavily influenced by the lower resolution flip sim.

If you have watched Jeff Lait's recent how to build a fluid solver from scratch or have read the flip paper you will know that the smoothing control implemented on the Flip Solver DOP controls how much of the previous frame's particle velocity to mix in to the result of the vel fields after running through the Project Non-Divergent step. So in this up res flip simulation, the smoothing parameter allows you to add in more or less of the particle behaviour on top of the overridden vel field.

You get the bulk of the motion from the low res flip sim along with some more of the high res detail.

Just one way of many of running an up-res flip sim on a low res sim.

The technique of using sampling of a high res particle field on a low res one from the link reference above is yet another and isn't very hard to set up in Houdini. Although it does look very fluidy with not too much control. It does look like high res particles driven by a low res particle sim with no added "behaviour".

I like to convert things to volumes taking the hit just once (in the low res flip sim) and then sample the high res particles in to the low res volume field. Faster than constantly doing a point look-up and you have similar control. If you use masks to control where to apply the low res velocity, you can get even more control. Up to you.

To get more of the high res flip behaviour mixed in, you would have to take greater care in how you composite the low res vel volumes in to the high res field. To do this, copy the vel field to say vel_low_res, copy the vel volumes from disk in to vel_low_res then use a Gas Linear Combination to mix the vel_low_res in to the vel fields.

This is VFX so what looks good rules and not some super accurate fluid simulation.

More ideas:

Solve the initial flip sim with a huge particle separation and see how far you can push the low-res to high-res up-step and still have something that looks like a liquid fluid simulation.

Try a three level up step: Very low res vel cache. Low res vel cache. High res sim influenced by the very low and low vel volumes.

Calculate the boundary of the velocity on the low res sim and scatter points within that boundary, transfer the vel to those particles and then use these to influence the high res simulation. That way you can keep more of the up res bulk motion and constrain the areas that are of interest to the lower res simulation.


Link to comment
Share on other sites

Here's the base low res sim:


Then the upres flip sim driven by the low res vel volumes cached to disk. Same bulk motion as the low res simulation but with reduced velocities across the board:


And finally the straight flip high resolution sim identical to the up res without the influence of the low res vel fields. Considerably different behaviour than the low res sim:


What's interesting is that the low res sim and the last high res sim have similar velocity values while the high res flip sim driven by the low res vel fields has on average lower velocities. Possibly in part due to the fact that there are more particles to carry the same amount of velocity per unit area means less velocity as you increase the resolution of the sim to get a similar behaviour...

Btw the black regions after the sphere in the last high res straight flip sim image is due to my lazy ass placement of the velocity plane at the lower half of the sphere and not through it's middle therefore you are seeing the the velocity vectors straight down and are looking at the velocity vectors edge on.

Edited by old school
  • Like 1
Link to comment
Share on other sites

@old school

Hi, was just wondering if you can point me in the right direction regarding the @name= syntax. It is the first time I have seen it, and although I can imagine what this command is specifically doing, I would like to know where in the help docs is this topic covered.


Link to comment
Share on other sites

I don't know if it is documented per se...

The @ ampersand is used as a prefix when you want to evaluate an attribute in the group field as all SOPs now respect this.

If you had a Cd Color attribute you could work on all geometry that had red greater than 0.5 by typing:


with NO spaces.

Many conditional operations are supported: ==, !=, >, <, >=, <=


in a group field that works with volume primitives would now only work on any volumes with the primitive "name" attribute set to "vel.*" which expands to vel.x, vel.y and vel.z.

This group syntax is being used more often these days as it is pretty convenient.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...