The POP solver will always enforce this minimum number of substeps.

This should only rarely need to be changed.

The POP 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 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 the size of the smallest particle in a substep.

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.

An overall scale applied to the actual timestep. This parameter can be animated.

The drag described by targetv and airresist can be turned into an explicit force. This will result in particles not coming to a stop, but instead bouncing around the desired dragged location. Alternatively, you can turn on implicit drag and a more accurate damping will be done that stops the particles.

This will also affect how targetw and spinresist are integrated.

The force of drag will be proportional to the difference between the target velocity and the particles velocity. This difference can be linear (drag exponent of 1) or quadratic (drag exponent of 2) or something in between.

A value of two is a more realistic drag model which more quickly slows down extreme velocity differences and has less of an effect on small velocity differences.

This affects the angular velocity drag as well.

The age attribute will be updated for each time step and the particles flagged for deletion if they exceed their life attribute.

This controls whether external DOP forces will be added to the force model prior to integrating velocities.

The v attribute will be updated according to targetv, airresist, and force. The w attribute will be updated by the targetw, spinresist, and torque if this is turned on.

Controls if the mass attribute will affect how forces are added to the velocity. If use mass is set, the forces will be divided by the mass to get the acceleration of each particle.

The particles will be moved according to their velocity. They will also be re-oriented according to their angular velocity.

All particles with the dead attribute set to 1 will be deleted.

Dead particles will be removed after all solving is complete. In this mode, you will not see any particles with a dead value of 1. Otherwise, they will be deleted before the Pre-solve. Leaving them in the geometry allows one to tween dying particles to their final location.

Determines if any collision detection is done at all by the POP Solver. If mixing with another system, such as Bullet, you may wish to still use some of the integration options of the POP Solver (such as force) without including the collision component.

If you wish to do more than just bounce off other DOP collision objects, you can add hit attributes to inspect how the bounce occurred, and perform secondary animations using the result.

The hitnum attribute is often most useful to detect if particles just collided. You can either directly apply additional rules here, or use the POP Collision Behavior to layer more effects on top.

While attributes are added to all particles that collide, the following collision behaviors will only apply to the particles in this group. For example, if you wish particles to die after their first bounce, use @hittotal>1.

All particles that just hit, ie, @hitnum>0, will be added to this group.

If the group isn’t preserved, it is cleared out first so the only particles in the group will be those that just hit. If it is preserved, the group will accumulate all particles that ever hit.

Particles that are just hit will have their Cd attribute set to this value. This is useful for quick visualization of hits.

Adds to the integer hittotal attribute any hits that occurred due to this collision detection.

Often if you want to trigger an effect off a particle’s collision, such as birthing more particles, you want the particle at its hit location, not where it ended up at the end of the frame. This will move the particle back to its hit location. This consists of @P = v@hitpos;.

Controls what happens to particles that collide.

Enables the addition of Impact data onto the particles. Normally these are not added to save memory, and particle collision attributes are more easily created by enabling the Add Hit Attributes parameter.

Enables the addition of Feedback impacts onto colliding objects, which are required for two-way interaction.

Particles that remain near-stationary for sufficient time will be put to sleep by setting their stopped attribute to 1.

On the first frame all particles will be marked asleep.

How slowly particles need to be moving before they are eligible for sleeping. The amount of time they remain below this speed is accumulated in the deactivation_time attribute. If they exceed this speed, the deactivation_time is reset to zero.

How many seconds particles need to remain at or below the velocity threshold before they are put to sleep. See the Wake Up POP for methods to wake the particles back up again.

Particles that are asleep will be colored this color.

The name of the simulation data to apply the POP node to. This commonly is Geometry, but POP Networks can be designed to apply to different geometry if desired.

For nodes with local expressions, this controls where ch() style expressions in VEX are evaluated with respect to. By making this ., you can ensure relative references work. It is important to promote this if you are embedding a node inside an HDA you are also exporting the local expressions.

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.

Total number of machines that have to synchronize. Sometimes this can be determined from the operation, so this parameter will be absent.