|On this page|
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.
The FLIP Solver contains an embedded POP Solver, enabling the use of
POP forces by plugging them into the Particle Velocity input or
inline below any Source Volume emitters. Any
POP node that updates the
force attribute can
be used, as well as others that affect attributes like particle color
or age. The POP Solver also supports other particle behavior such
as aging and reaping particles.
Splashy vs Swirly Kernel
The Velocity Transfer parameter allows you to choose between the default Splashy Kernel and a Swirly Kernel. The Splashy Kernel is typically used for high energy, noisy large FLIP simulations like rivers or oceans, where the surface from FLIP noise isn’t a problem. The Swirly Kernel is typically used for high vorticity simulations where you need to reduce surface noise as much as possible while still retaining the swirling nature of the simulation. For example, for small scale fluids where surface noise can be really distracting or for lava type simulations.
The Splashy Kernel corresponds to the FLIP/PIC method of velocity transfer, while the Swirly Kernel is implemented with the newer APIC method. All of the Viscous shelf tools use the Swirly Kernel.
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.
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.
Increasing the Particle Separation will lower the resolution, which will make your simulation faster to process.
Usually you will not need to increase Substeps with FLIP. However, you may want to increase this value when simulating fast moving fluid that collides with other objects. You can also increase Substeps to improve the look of slow moving viscous fluid. Surface tension is an exception where substepping is likely required to maintain stability.
You can vary amounts of stickiness to different objects, by building your own sticky field. The Fluid Source can be used to take a point attribute like
sticky and make it a varying volume where you want stickiness to occur. Then, in the solver, you can use this field as the control field for the Stick On Collision function on the Collisions tab of the solver.
A good debugging rule of thumb for FLIP when seeing unexpected collision behavior is to immediately enable the Collision and Collision Velocity visualization on the FLIP Object, so you can see exactly what the solver is seeing for collisions.
Turning Reseed Particles off and having the Jitter Scale set to 0 gives a uniform-spaced grid of particles. This is generally not recommended, because you won’t end up filling the voxels as effectively as with jittered points, and as they move around you’ll get an uneven distribution due to numerical error, especially with Reseed Particles turned off.
Accurate velocities for moving collision objects are extremely important for fluid simulations in general, but particularly for FLIP. Incorrect collision velocities can lead to less dynamic splashes or fluid leaking through geometry. For DOPs to calculate accurate collision velocities with moving or deforming DOP objects, the DOP network must have Cache Simulation enabled. However, with very large FLIP simulations, the FLIP object data for a single timestep might not fit in cache memory. In this case, disable Allow Caching on the FLIP Object to remove the FLIP data from the cache, while still caching the collision objects.
Many FLIP simulations use 2 or more substeps. For deforming collision objects, make sure that the input geometry properly interpolate to subframes. The Collision Source SOP handles interpolating the geometry and creating VDB Signed Distance volumes that can be used with FLIP. Use the Deforming Object shelf tool to set up deforming geometry as a FLIP collision object.
Another option for adding collision objects to fluid simulations was the Collide With Object shelf tool, which adds collision volumes directly to the simulation using the Source Volume DOP. However, as of Houdini 14, this option is deprecated and not recommended. Instead use the the Deforming Object shelf tool.
If using Source Volume based collisions, you must use the Move Outside Collision method for particle collisions, because the Particle method only works when a collision is represented by an actual DOP object.
The default velocity scale for Source Volume is 1.5, which will cause larger splashes by default, but for moving containers this should be set to 1.
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 and provides the smoothest splashes, however it is not as accurate with fast-moving collision geometry. It is also the only collision method that works with Source Volume based collisions.
A scaling factor for time inside this solver.
1 is normal speed, greater than
1 makes the FLIP simulation appear speeded up, less than
1 makes the simulation appear to be in slow motion.
Changing the Timescale only affects the timestep of the simulation. If adding velocities calculated in SOPs to the simulation for collisions or pumps with the Source Volume DOP, scale the incoming velocities by
1 / Timescale to match the timestep of the simulation.
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.
Quantize to Max Substeps
Alway use substeps that divide up the frame by Max Substeps. For example, if Max Substeps is set to 4, but the CFL Condition only requires 3 substeps, the solver will take frame steps of 0.25, 0.5, and 0.25. This option can be useful for re-using input geometry that has been cached to file at increments of 1/Max Substeps.
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.
If enabled, this attribute will disable the volume forces wherever it is 1 on the particles, and enable it when where it is 0. Ie, particles with this attribute at 1 will fly ballistically with no reference to other particles. However, their motion will still affect other particles which have volume forces.
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:
Make no attempt to detect under-resolved particles.
Set a float-valued
underresolved attribute on each particle
that indicates the amount it is under-resolved.
Treat as Ballistic
underresolved attribute and combine it with any
specified Force Override attribute to determine whether the
particle should be treated ballistically or as a fluid.
Use Extrapolated Velocity
Use the extrapolated fluid velocity unless a particle is outside the range of valid extrapolated values as specified by Max Cells to Extrapolate. For particles outside the valid range, this setting is the same as Treat as Ballistic. This will reduce stringiness in splashes.
Kill any fully under-resolved 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.
Do not perform particle collision detection. Particles will only avoid collisions as a result of the pressure solve, but due to numerical error can possibly end up inside collision objects.
Perform particle collision detection, including Feedback between particles and other simulated objects. This collision method also supports friction and bounce. It is the most accurate, but slowest collision method.
Move Outside Collision
Perform collision detection by moving particles outside any collision objects. This is faster than the Particle method, but not as accurate for thin or fast-moving objects.
Kill Unmoveable Particles
Kill any particles that become stuck inside the collision SDF (in local minima) when using Move Outside Collision collision handling.
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.
Age the particles over time.
Kill any particles whose age attribute is greater than its life attribute.
Deletes internal attributes that are typically not required in the output of the simulation. Removing an attribute from this list will ensure it exists at the end of the timestep.
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.
The goal number of particles will be scaled by this amount 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.
A seed that controls the time-varying random function used to generate new particle positions when reseeding. Because high-frequency splashes in a simulation are strongly influenced by particle positions, varying this value (e.g. with a Wedge ROP) can generate multiple simulations with similar bulk motion but different splash behavior from otherwise identical simulation parameters.
All attributes matching this pattern will be interpolated to newly
seeded particles from the surrounding existing particles. This interpolation
is more expensive than the default nearest neighbor copy, but yields
a smoother particle sampling for attributes like velocity. For example, the
viscosity attribute might be added to this list for fluids smoothly transitioning
between melting or freezing, while it should be omitted for "multi-phase" fluids
with distinct viscosity values.
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
pscale attribute. When this happens, internal
forces can’t separate the particles because the velocity projection
will remove those forces. This results in the fluid compressing
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
pscale amount due to the sphere packing
problem. To test different values, run a FLIP solve without any
volume or particle forces and see which values cause your initial
particles to retain the desired volume.
Identify particles that separate from the main body of fluid via a
droplet attribute that ranges from 0 to 1. As a particle approaches
full droplet status, it will be less influenced by fluid forces. A fully
droplet particle also does not contribute velocity back to the fluid
simulation, which can alleviate the problem of individual falling particles
causing unrealistically large disturbances on a smooth fluid surface. Enabling
droplets can also break up tendrils on the leading edge of splashes, giving them
a more diffuse look.
Min Particle Density
A particle has a droplet value of 1 (droplet) when the surrounding fluid particle density is below this value.
Max Particle Density
A particle has a droplet value of 0 (fluid) when the surrounding fluid particle density is above this value.
Controls handling of droplet particles.
Blend With Fluid
When a fully droplet particle rejoins the fluid, make its velocity a blend between the the droplet’s velocity and the existing fluid velocity, as specified in the Velocity Blend parameter.
Kill On Detection
Immediately kill any fully droplet particles.
Kill At Fluid
Kill any fully droplet particles that rejoin the fluid.
Controls the blend between droplet particle velocity and the fluid velocity when Behavior is set to Blend With Fluid.
Add Vorticity Attribute
Compute the vorticity of the fluid velocity field and mix it into the
attribute on the particles.
The amount of existing vorticity measurement on the particles to preserve per second before mixing in the current computed value. For example a value of 0.1 will retain 10% of the vorticity measurement over a second.
How to blend the computed vorticity with the existing
vorticity attribute value.
A scale applied to the computed vorticity.
Add Rest Attribute
rest attribute, which can be used to track the position of the fluid over time. Turn this on to map noise or textures in the liquid shader.
Dual Rest Attributes
rest2 attribute that is one back from the the main
rest attribute, allowing you to run longer simulations without popping by blending between the two attributes.
Frames Between Reset
Number of frames before resetting the rest attributes.
Which frame the rest attributes will be reset on. If you are prerolling the simulation, delaying the rest attribute initialization until after the preroll will usually give a better result.
Specifies the method used for transferring velocity from the particles to the underlying grid before solving, then back to the particles.
Transfers the change in velocity from solving back to the particles, along with a small portion of the current velocity as specified by the Velocity Smoothing parameter. This method gives splashy, high-energy simulations, but can also introduce noise at the surface which can be distracting for small scale or viscous fluids.
Transfers the velocity field directly to the particles using additional attributes to preserve the angular momentum of the fluid. This method retains vortices well with reduced noise at the surface, yielding swirling simulations with fewer splashes that can be effective at small scale or high viscosity.
In this case, the transfer radius is based on the voxel size, so using smaller voxels by setting the Grid Scale on the FLIP Object to 1.5 can help retain small fluid details. Because of the larger radius and extra attributes, this method is slightly slower and uses more memory than the Splashy Kernel. Also, the Under-Resolved Particles options are disabled for this method, as particles will always be fully resolved on the grid.
The Splashy Kernel corresponds to the FLIP/PIC method of velocity transfer, while the Swirly Kernel is implemented with the newer APIC method.
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 particle velocities to smooth out as they share more of their velocities with their neighbors.
Use a more accurate algorithm for tracking the surface SDF over time, providing smoother surfaces for stationary or slow moving liquids. This improvement may not be noticeable in very turbulent simulations such as rivers or waterfalls and can be disabled for a small performance gain.
Controls how the surface SDF is updated at the end of each substep to match the particle positions.
Do not update the surface SDF.
Advect the surface SDF through the velocity field. This is the faster than Rebuild, but not as accurate.
Rebuild the entire surface SDF from the particles. This the most accurate method, but also the slowest.
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.
Do not update the velocity field.
Advect the velocity field through itself. This is the faster than Rebuild, but not as accurate.
Rebuild the entire velocity field from the particles. This the most accurate method, but also the slowest.
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.
Fill New Volume
If the Volume Limits change between frames, this option allows particles to be seeded into a new empty region in the volume. Use Waterline and Use Boundary controls how the new particles are created.
If the FLIP Object uses Closed Boundaries, this option will set each corresponding boundary to be open above the waterline. This allows particles to elegantly leave the simulation and reduces reflections at the boundaries. This can also be used instead of the Surface Volume for Fill New Volume and Use Boundary Layer.
Display the waterline plane where fluid above the plane can freely flow out of an otherwise closed boundary.
The Waterline level and Waterline Direction define the waterline plane. Along a closed boundary, simulation voxels above this plane will be set as an open boundary. For Fill New Volume and Boundary Layer, the plane is defines the surface, where particles above the plane are considered to be outside of the surface.
The waterline direction specifies the "up" direction of the waterline plane. The border between the closed and open boundary region is a combination of the waterline level and the waterline direction.
Use Boundary Layer
Maintaining a thin region around the FLIP simulation can be used to imitate the behavior of an infinite tank. By deleting and reseeding particles according to a provided surface and velocity field, reflections at simulation boundaries can be reduced. Particles entering the boundary layer that are above the specified surface (given by the waterline or surface volume option) will be removed. Particles entering the boundary layer that are below the surface will be assigned a new velocity if the velocity volume option is used.
Apply Boundary Velocities
The Velocity Volume is automatically applied along the Closed Boundaries when Use Boundary Layer is activated. This option will also overwrite the velocity field inside the boundary layer according to the Velocity Volume (or the default of zero velocity when using the waterline). When this is turned off, newly created particles will interpolate velocities from neighbouring particles.
The Boundary Layer will be offset into the simulation volume by the specified amount from the lower boundary of the simulation volume.
The Boundary Layer will be offset into the simulation volume by the specified amount from the upper boundary of the simulation volume.
The surface in boundary layer can be maintained by a provided SDF. Particles above the surface will be removed. The volume below the surface will re-seeded. The particles seeded in a new volume region will be created based on this surface.
The velocity of the particles in the boundary layer and new volume will be assigned a velocity sampled from this velocity volume.
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.
The collision velocity of the objects is calculated by treating it as a rigid body. Only the angular velocity and linear velocity will be used, no local deformation will be taken into account.
The collision velocity of the objects tries to take into account deformation by using point history. This only works if the topology doesn’t change.
Uses the SDF representation of the object to detect deformation. Does not require a fixed topology over time, but cannot detect tangential velocities.
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.
Setting this to 0 is not recommended.
Volume Fraction Method
The solver uses fractional estimates of collision volumes to increase the accuracy of the pressure solve around curved or sloped surfaces.
Voxel Face Area
Estimate the fractional collision weight by determining how much of each voxel face is occluded by the collision volume. This method provides the smoothest handling of sloped objects, but can treat square objects as excessively smooth.
Estimate the fractional collision weight by sampling the collision volume multiple times for each voxel. This method handles square-shaped collision objects better, but can introduce some false friction-like forces on sloped surfaces.
Do not calculate collision weights. This should only be used by advanced users for a high degree of control over the collision weights by calculating them manually, usually with a Gas SDF To Fog DOP. attached to the Volume Velocity input.
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. See the Gas Stick On Collision DOP for more information.
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.
Scale the amount of velocity adjustment in the direction normal to the collision surface.
Scale the amount of velocity adjustment in the direction tangent to the collision surface.
Keeping a high Normal Scale and decreasing the Tangent Scale can create a "sticktion" effect, where the fluid flows quickly around the collision but remains stuck to the surface.
Scale the effect by this spatially varying field, which should match the collision field in resolution.
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.
This parameter controls the floating point precision used internally by the viscosity solver. Float 32 bit uses less memory and is generally faster than Float 64 bit. However, the extra accuracy of 64-bit floating point numbers may be needed when simulating fluid with very high viscosity or large variations in viscosity.
Slip on Collision
Causes the collision velocity to match the fluid velocity when close to collision objects. This allows a viscous fluid to slide along the collision object.
The amount of fluid velocity to blend into the collision’s tangential velocity, where a value of 1 indicates fully matching the fluid velocity.
Scale the effect by this spatially varying field, which should match the collision field in resolution.
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 air volume is not simulated and is treated entirely as a void. This assumption causes air regions to collapse or expand based on the motion of the liquid. Enforcing air incompressibility restricts the liquid motion to treat each air region as incompressible.
Enforce Air Incompressibility
The divergence free constraint will now also be applied to the air volume. This will prevent air volumes from collapsing and create rising bubbles. This is useful for capturing realistic air-liquid interaction like a glugging watercooler.
Apply Moving Collision
Moving collisions can interact indirectly with the liquid through an air pocket. Any compression applied to the air pocket by the collision is compensated for at the liquid surface of the air pocket.
Min Air Region Voxels
Air regions containing fewer voxels than the minimum will not have their incompressibility enforced. This is useful for preventing small bubbles from emerging along collision surfaces.
Turn off Dynamically Resize Fields when enforcing air incompressibility inside collision containers. Otherwise the enforcement might not detect the enclosed air region and the liquid could pour through unaffected.
The Enforce Air Incompressibility feature does not solve for the velocity in the air volume. It simply constrains the velocity of the liquid from compressing or expanding the air volume. This approach makes the simulation much more efficient than fully simulating the entire air-volume.
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.
Surface tension flattens irregular features and pulls water into droplets. It is useful for small-scale simulations where the effect of surface tension is often more important than gravity in controlling the dynamics.
For large values, additional substeps are often required to ensure stability.
Enabling surface tension will create the
This field can be used for other effects than just surface tension,
such as suction or avoidance.
Enable Surface Tension
The magnitude of the surface tension. This depends on the mass-density of the fluid, so must be changed if the mass-density is changed.
Given the same object, but reduced particle separation (ie, a higher resolution simulation), you may need to reduce the magnitude of the surface tension to maintain the same qualitative result.
Negative values will cause the surface to rip itself apart in a spectacular fashion.
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.
Controls the method used for extrapolating velocity in the solver.
A fast method that properly handles curved collision containers. This is the recommended extrapolation mode.
A slower method that can be more accurate with fast moving colliders and a low number of substeps.
Automatic Extrapolation By Speed
Improve handling of fast-moving fluid by automatically increasing the extrapolation distance based on the fluid’s speed. In most cases, this avoids tuning the Max Cells To Extrapolate parameter. The final extrapolation distance is the greater of Max Cells To Extrapolate and the speed-calculated value.
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.
Solve the linear systems for viscosity and pressure using OpenCL. This setting is mostly beneficial for high resolution fluid simulations with viscosity, when run on a fast GPU.
The following collision fields are used mainly for creating guiding simulations. They are only connected to the collision fields in both the pressure and viscosity solvers. All other nodes that apply collision information use the internal fields. Please refer to Gas Guiding Volume DOP for more information about creating guiding fields.
The collision surface that is connected to pressure and viscosity solvers.
The collision weights improve the accuracy of the pressure and viscosity solvers.
The collision velocity is applied to the fluid through the solvers at the collision surface.
The following fields are used mainly to maintain FLIP particles for guiding simulations. These fields are connected to a Gas Seed Markers DOP.
FLIP particles are seeded into the source surface. This is useful for allowing the fluid to flow out of a guiding simulation surface.
FLIP particles are removed when they enter the sink surface. This is useful for removing unneeded particles that flow deep into a guiding simulation surface.
When this tab is enabled, FLIP particles are only maintained near the fluid surface. The rest of the fluid is represented by volumes (e.g. surface or velocity).
Removing particles deep inside the fluid reduces the memory footprint and can often improve the performance of the fluid simulation.
Because the fluid is largely represented by volumes, Density by Attribute and Viscosity by Attribute are not supported.
Enable Particle Narrow Band
A narrow band of FLIP particles will be used to update the fluid’s surface and velocity volumes within the Bandwidth of the fluid surface. Any particles deeper into the fluid than the Bandwidth will be removed from the simulation.
The narrow band of FLIP particles will be maintained at this voxel thickness. Very fast moving simulations might require a larger bandwidth to maintain stability.
FLIP simulations are distributed in the same manner as particle simulations; by first specifying a series of Slice planes that divide space up. Each machine then is responsible for the fluid that lies within its slice.
Each substep all particles along the slice boundaries are exchanged. The bandwidth specified should thus be large enough to cover how far particles are expected to move in a substep.
All machines synchronize their substep size automatically, so variable substeps can be used.
What machine will run the simtracker.py process for synchronization. If this is blank, there will be no attempt at synchronization or data transfer.
The port specified when starting the simtracker.py process for communication.
The job name to describe this synchronization or data exchange event. By using different job names one can have machines part of separate data-exchange and synchronization events.
The slice number that this machine should report itself as. Each machine connecting under the job name should have its own unique slice number. Sometimes this can be inferred from the operation so this parameter will be absent.
Number of Slice/Number of Peers
Total number of machines that have to synchronize. Sometimes this can be determined from the operation, so this parameter will be absent.
Distributed Pressure Solve
The pressure projection may be distributed across machines. This avoids any loss of fluid and is required for tank-style simulations, but not needed for flowing rivers. It requires considerably more network bandwidth, so becomes advantageous only with very large simulations.
Each data option parameter has an associated menu which specifies how that parameter operates.
Use the value from the Default Operation menu.
Set the value of this parameter only when this data is created. On all subsequent timesteps, the value of this parameter is not altered. This is useful for setting up initial conditions like position and velocity.
Always set the value of this parameter. This is useful when specific keyframed values are required over time. This could be used to keyframe the position of an object over time, or to cause the geometry from a SOP to be refetched at each timestep if the geometry is deforming.
You can also use this setting in
conjunction with the local variables for a parameter value to
modify a value over time. For example, in the X Position, an
$tx + 0.1 would cause the object to
move 0.1 units to the right on each timestep.
Do not ever set the value of this parameter. This option is most useful when using this node to modify an existing piece of data connected through the first input.
For example, an RBD State DOP may want to animate just the mass of an object, and nothing else. The Set Never option could be used on all parameters except for Mass, which would use Set Always.
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
* before connecting it to this node. This option makes it
convenient to have all objects feeding into a solver node affect
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
to vary the solver parameters across the objects. Setting this toggle will
create a separate solver per object, allowing
$OBJID to vary as expected.
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.