When particles get too close together, a common solution is to apply forces to separate them. Unfortunately, if you are removing divergence, as in the FLIP solver, these forces will be canceled out. The Gas Particle Separate DOP takes a different approach by directly adjusting particle positions to keep them apart. This also ensures no energy is added to the system directly by the separating effect.
The geometry containing the particle set to separate.
An optional point group to specify which points will be considered.
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 scale to apply to all the particle
pscale values when searching for
adjacent particles that may be too close.
A fudge factor to account for the inability for the particles to
actually pack at the
pscale amount due to the sphere packing
Assume Uniform Radius
All particles are assumed to have the same uniform radius as the first particle, and internally a faster algorithm can be used for spatial lookup that scales well to millions of input points.
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.