Evolves an object as a FLIP fluid object.
The FLIP Solver DOP evolves an object dynamically as a particle fluid.
A FLIP solver is a type of hybrid between a particle based and volume
based fluid simulations. All fluid data is stored in the particles and
only particles need to persist frame to frame, ensuring no unwanted
mixing or loss of fluid can occur. However, the pressure projection
step is done on a volume that is created just in time. The fluid is
represented by particles with their
pscale, and can be moved around
with POP and DOP forces.
When FLIP fluids are solved, a temporary velocity field is made. The particle velocities are transferred to this grid and the grid is used to perform the fluid projection. This is what prevents the particles from all going on top of each other and start moving in similar directions.
Advanced users can also add volume velocity forces at this stage as well.
FLIP fluids are faster than SPH fluids, if you don’t need to substep the FLIP fluid. If you need to substep the FLIP fluid because of fast moving colliders, you may find SPH just as a fast or faster. FLIP fluids are also useful because particles can be placed on top of each other without destabilizing the system. SPH tends to blow up if you move particles too close.
The advantage of the FLIP Solver is that you run with only a few time steps per frame while SPH requires anywhere from 7 to 20 time steps or more per frame to stabilize. FLIP utilizes a few grids (volume fields) to help tame the instantaneous impulses that can arise in a fluid sim.
Various fields are used to tame the FLIP Solver so that you can run far fewer points at far fewer time steps and the inter-spacing between particles can be random. You can introduce new particles at any time with little to no consequence. This opens up so many new work flows in POPs that were simply not possible with SPH. For example, introducing splash particles with their own property attributes is now possible.
For emitting large numbers of particles, the Source Volume DOP can be much faster than the Particle Fluid Emitter DOP. You can set up surface emission using the Source From Surface shelf tool or volumetric emission using Source From Volume from the Populate Containers shelf.
In some cases, especially with thin collision objects, the FLIP Solver may not resolve the collision properly when simulating at relatively low resolutions. Enabling Collision Separation on the FLIP Object and setting this value to the Particle Separation or smaller will create a higher-resolution collision field that will help the solver resolve the collision better. With very thin objects you may even need to create proxy collision geometry that generates a thicker SDF.
Move Outside Collision is the fastest collision handling method, although not the most accurate.
If your scene is modeled in units besides meters, be sure to set Spatial Scale correctly. Otherwise the FLIP Solver will adjust particle positions with more accuracy than required for the scene scale. The resulting performance degradation mostly affects Reseeding and the Move Outside Collision collision detection method.
Turning off Use Preconditioner might improve solve performance if simulating on a system with multiple CPU cores.
Use the Performance Monitor to detect bottlenecks in your FLIP simulations. In general the FLIP Solver should consume most of the solve time for a typical DOP Network. If emitting particles is taking a large amount of time, consider using Source Volume emission as described above and possibly even caching the points created by the corresponding Fluid Source SOP.
If writing out large FLIP simulations to disk using the Dop I/O SOP, enable Save In Background to allow the simulation to continue while the disk writes occur in the background. Deleting any unneeded attributes using the Compression tab will also save disk space and write time.
Enable Reseeding to help preserve surface detail, possibly increasing Surface Oversampling to 2 or more.
The Velocity fields are heavily blurred and thresholded for large changes in velocity, which is completely tunable if the FLIP solver appears to be exploding. The Pressure field is used to monitor any areas of very high and very low pressure and then the fluid sim can compensate the Velocity fields which then push the points around. This is where the controls for cavitation, entrapped air, and fluid escape are managed to a great extent. The Surface field can be used to test the past if some particles have flown far too far off the surface and then constrained back.
The FLIP solver will always enforce this minimum number of substeps.
This should only rarely need to be changed.
The FLIP solver will not break the simulation down in to more substeps than this value.
The CFL condition is a factor used to automatically determine what size substep the scene requires. The idea is to control the distance that a particle in the particle fluid object can travel in a given substep.
For example, when this parameter is set to 0.5, the solver will set the length of each substep such that no particle travels more than 50% of its particle separation in a given substep.
|Particle Advection CFL|
The CFL condition for particle advection. This can be set lower than the CFL condition for the entire solver, as it only affects the accuracy of particle advection in the velocity field.
|Apply External Forces|
Standard DOP forces, such as gravity from a Gravity DOP, will be applied to the particles.
This would only be turned off if you are combining a FLIP solver as part of a larger solver system.
|Ignore Particle Mass for Forces|
Do not take into account particle mass when applying DOP Forces.
If enabled, this attribute will disable the volume forces wherever it is 1 on the particles, and enable it when where they are 0. Ie, particles with this attribute at one will fly ballistically with no reference to other particles. Note that their motion will still affect other particles which have volume forces, however.
Depending on the values of the Particle Radius Scale and the volume Grid Scale on the FLIP Object DOP, individual particles can become under-resolved on the grid and “disappear” from the pressure solve. This parameter controls how the solver treats such particles:
If the Particle Radius Scale / Grid Scale >= sqrt(3) / 2, then particles will never be under-resolved.
Controls handling of collisions between particles and other objects.
|Collide with Volume Limits|
For Closed Boundaries as specified on the FLIP Object DOP, particles will be constrained to stay inside the extents of the volumes as specified in the Volume Limits tab. This setting is useful for closed “tank” type fluid simulations.
|Kill Outside Volume Limits|
Kill any particles outside the volume limits.
|Use Friction and Bounce|
Enable support for particle Friction and Bounce as specified on the Physical tab of the FLIP Object DOP. Only enabled if Collision Detection is set to Particle.
|Add ID Attribute|
Add a unique ID attribute to each particle.
Create new particles in voxels where the particle count has dropped too low to properly represent the fluid surface, and delete particles in voxels that have become too crowded. Reseeding can help avoid collapsing pockets of air forming in the fluid near collisions, as well as provide a smoother surface from which to generate a polygonal mesh.
|Particles Per Voxel|
The goal number of particles per voxel.
Scales the goal number of particles by when within Oversampling Bandwidth of the surface.
Oversample within this number of voxels from the surface or any Surface volume boundaries, if Oversample at Boundaries is enabled.
|Oversample At Boundaries|
Oversample within Oversampling Bandwidth voxels of the fluid volume boundaries. This setting helps avoid collapsing pockets of fluid at the boundaries of a “Tank”-type simulation.
Particles will be added to a voxel once the current number drops below the product of this parameter and the goal number of particles.
Particles will be deleted from a voxel once the current number rises above the product of this parameter and the goal number of particles.
Setting the various Reseeding values too high can lead to fluid gaining volume over time in very splashy fluid simulations. Decreasing the Particle Radius Scale or the Death Threshold can reduce the volume by causing overcrowded voxels to be pruned earlier. Decreasing the amount and/or bandwidth of Surface Oversampling can help alleviate this problem as well.
|Apply Particle Separation|
Despite the velocity projection stage, particles can end up closer
together than their
The number of times to perform the separation relaxation step. This value can usually be set to 1 since successive frames of separation will have the same effect.
How far to move the particles towards their desired separation locations. This can be reduced to get the effect of a fractional iteration.
A fudge factor to account for the inability for the particles to
actually pack at the
The result of the velocity projection is a suggested change to the particles velocity. The force scale allows you to scale this change. A value of 1 will update the particles to the new desired velocity, 0 will leave them unchanged.
Particles can either update themselves with the change in velocity determined by the projection, or update themselves with the actual new velocity from the projection. The latter causes particles to smooth out as they share more of their velocities with their neighbors.
Controls how the surface SDF is updated at the end of each substep to match the particle positions.
Because particle positions are updated last in the solve order, the surface SDF will lag slightly behind the particle positions if Update Surface is set to None.
Controls how the velocity field is updated at the end of each timestep to match the particle positions.
Because particle positions are updated last in the solve order, the velocity field will lag slightly behind the particle positions if Update Velocity is set to None.
If stray particles fly off too far, the resulting volume grid can become unwieldy even with constant tile compression. This tab allows you to set maximum bounds.
Display the guide showing the maximum limits of the simulation. The actual simulation size will most likely be smaller if Dynamically Resize Fields is enabled.
The size of the maximum volume.
The origin of the maximum volume.
|Dynamically Resize Fields|
Resize the volumes each timestep to contain the particle geometry, within the limits specified. The volumes will be padded by the number of voxels specified in Max Cells to Extrapolate.
Scale the input collision velocities, increasing the effect of moving objects on the fluid and creating bigger splashes, for example. This value should usually be 1 or greater.
Use Transparency to reduce the overall effect of collisions on fluid.
The method used to calculate collision velocities for colliding DOP Objects. This setting does not affect collision velocities introduced by a Source Volume DOP.
When the fluid surface is within this voxel distance of a collision, the solver will consider it part of the collision object. This extrapolation helps fluid flow smoothly along curved surfaces, but can create a slight stickiness. Decreasing this value can create more dynamic splashes from collisions, especially as objects enter the fluid.
|Volume Fraction Method|
The solver uses fractional estimates of collision volumes to increase the accuracy of the pressure solve around curved or sloped surfaces.
|Samples Per Axis|
How many samples are taken per axis when the Volume Fraction Method is set to Collision Supersampling. Increasing this value makes for a more accurate estimate, but note that the total number of samples taken is the cube of this number.
Make all collision objects “transparent” to the fluid by this amount, decreasing the effect of objects on the fluid and allowing some fluid to flow through the objects.
If using Transparency, the Collision Detection method of the Particle Motion tab should usually be set to None, otherwise the particle collision detection will not allow any particles to intrude into collision objects, no matter what the Transparency value.
|Stick on Collision|
Causes the fluid’s velocity to match the collision velocity when close to collision objects.
The amount of collision velocity to blend into the fluid’s velocity, where a value of 1 indicates fully matching the collision velocity.
Specifies the world-space distance within which to apply the effect.
Specifies the maximum number of voxels within which to apply the effect.
Controls how quickly within the stick distance the effect will reach the full Stick Scale. Values closer to 1 will have more effect throughout the stick distance.
See the discussion of viscosity in the user guide.
Enable the viscosity solver.
|Viscosity by Attribute|
Use the specified attribute to overwrite the viscosity field.
The float attribute on the particles to use for the viscosity amount.
How to blend the point attribute with the existing viscosity field.
A scale applied to the Viscosity field after applying the attribute effect. This is useful for quickly adjusting the global amount of viscosity.
By default, the fluid has uniform density as set on the Physical tab of the FLIP Object. To simulate fluids of varying density, you can use a per-particle density attribute to control the density throughout the fluid.
If you override the Density field through the Volume Velocity input to the flip solver, you can arbitrarily edit the density field.
|Density by Attribute|
Use the specified attribute to manipulate the density field.
The float attribute on the particles to use for the density amount.
How to blend the point attribute with the existing density field.
A scale applied to the Density field after applying the attribute effect. This is useful for quickly adjusting the global amount of density.
By setting the Mix Method to Multiply, you can use relative density values that scale the default fluid density. A density attribute of 1, for example, will have the density of water by default, while a density attribute of 0.5 would indicate fluid of half that density. Relative density is also known as specific gravity; values for typical liquids can be found here. Note that because the FLIP Solver does not explicitly track the boundary between fluids of different densities, it might be necessary to exaggerate density ratios to avoid excess mixing.
By default, the volume motion is divergence free. These enforces neighboring particles to neither separate nor converge. However, you may want to adjust the particle spacing. Doing this with forces is difficult because the volume projection will undo your forces.
Instead, you can add a per-particle float attribute to store how much the particles should diverge. Positive values cause particles to spread out, and negative values cause them to clump together.
If you override the Divergence field through the Volume Velocity input to the flip solver, you can arbitrarily edit the divergence field.
You must turn on Add Divergence Field in the FLIP Object for this to work.
|Diverge by Attribute|
Use the specified attribute to overwrite the divergence field.
The float attribute on the particles to use for the divergence amount.
How to blend the point attribute with any existing divergence field. The divergence field is not reset frame-to-frame.
A scale applied to the divergence field after applying the attribute effect. This is useful for quickly adjusting the global amount of divergence.
Indicates the scale of the simulation. This value controls the tolerance of various particle operations, particularly moving particles to match SDF iso surface values, and some solver defaults for density and viscosity. If your scene is modeled in meters, then the default value of 1 is sufficient. However, if your scene is modeled in centimeters, you should set Spatial Scale to 0.01.
Choose the correct Unit Length in Edit > Preferences > Hip File Options before you create your DOP network. That way, the FLIP solver node will automatically get the correct Spatial Scale when it’s created.
Indicates the mass scale of the simulation. This value controls the solver tolerance for density and viscosity. If your scene is modeled in kilograms, then the default value of 1 is sufficient. However, if your scene is modeled in grams, you should set Spatial Scale to 0.001.
Choose the correct Unit Mass in Edit > Preferences > Hip File Options before you create your DOP network. That way, the FLIP solver node will automatically get the correct Mass Scale when it’s created.
A scale factor used in applying feedback forces to other objects. A value of zero prevents any feedback from occurring.
The default RBD object has the same density as water, so to balance with the default fluid density a value of 1 should be used.
|Max Cells to Extrapolate|
The number of non-fluid cells that should be filled with velocity values on the non-fluid side of the velocity field. Increase this value for very fast-moving fluids and/or a low number of substeps.
During the pressure projection and viscosity solves, the matrices involved can be preconditioned to speed up the solution. However, this is a single threaded process. On machines with 4+ sockets it may be faster to disable this preconditioning and use a simpler Jacobi preconditioner which multithreads well, but can take more iterations to converge.
Each data option parameter has an associated menu which specifies how that parameter operates.
For any parameters with their Operation menu set to Use Default, this parameter controls what operation is used.
This parameter has the same menu options and meanings as the Parameter Operations menus, but without the Use Default choice.
|Make Objects Mutual Affectors|
All objects connected to the first input of this node become mutual affectors.
This is equivalent to using an Affector
DOP to create an affector relationship between
When an object connector is attached to the first input of this node, this parameter can be used to choose a subset of those objects to be affected by this node.
Indicates the name that should be used to attach the data to an object or other piece of data. If the Data Name contains a “/” (or several), that indicates traversing inside subdata.
For example, if the Fan Force DOP has the default Data Name “Forces/Fan”. This attaches the data with the name “Fan” to an existing piece of data named “Forces”. If no data named “Forces” exists, a simple piece of container data is created to hold the “Fan” subdata.
Different pieces of data have different requirements on what names should be used for them. Except in very rare situations, the default value should be used. Some exceptions are described with particular pieces of data or with solvers that make use of some particular type of data.
|Unique Data Name|
Turning on this parameter modifies the Data Name parameter value to ensure that the data created by this node is attached with a unique name so it will not overwrite any existing data.
With this parameter turned off, attaching two pieces of data with the same name will cause the second one to replace the first. There are situations where each type of behavior is desirable.
If an object needs to have several Fan Forces blowing on it, it is much easier to use the Unique Data Name feature to ensure that each fan does not overwrite a previous fan rather than trying to change the Data Name of each fan individually to avoid conflicts.
|Solver Per Object|
The default behavior for solvers is to attach the exact same solver to all
of the objects specified in the group. This allows the objects to be
processed in a single pass by the solver, since the parameters are identical
for each object. However, some objects operate more logically on a single
object at a time. In these cases, one may want to use
|Fluid to Solve|
The simulation object to evolve as a particle fluid.
This input injects microsolvers after the particle velocity has been updated but before it has been transferred to the volume fields. It is thus the ideal place to add solvers that manipulate the particle velocity or position still farther.
Solvers in the volume velocity input are added after the volume velocity field has been created but before it has been made non-divergent. This is the best place for field-affecting microsolvers to be attached, and the only place for microsolvers that want to add forces to the velocity field.
Solvers attached to this input should not create or delete particles.
Nodes attached to this input can also edit the simulation network’s velocity fields, for example to apply custom forces, after the main simulation steps.
The operation of this output depends on what inputs are connected to this node. If an object stream is input to this node, the output is also an object stream containing the same objects as the input (but with the data from this node attached).
If no object stream is connected to this node, the output is a data output. This data output can be connected to an Apply Data DOP, or connected directly to a data input of another data node, to attach the data from this node to an object or another piece of data.
|DensityViscosity||Load | Launch|
This example demonstrates two fluids with different densities and viscosities interacting with a solid object.
|FlipColorMix||Load | Launch|
This example demonstrates the use of the Flip Solver to mix the colors of a red fluid with a blue fluid to form a purple fluid.
|FlipFluidWire||Load | Launch|
This example demonstrates the use of the Flip Solver and the Fluid Force DOP. The Fluid Force DOP is used to apply a drag force on a wire object according to the motions of a flip fluid. The drag force is only applied at locations where fluid exists in the fluid object.
|VariableViscosity||Load | Launch|
This example demonstrates interaction between three fluids of varying viscosity and a moving collision object.