Collision particle node

Specifies the SOP to use.

Path to the SOP (when Geometry source is set to Use Parameter Values).

Particles normally use the object space of the SOP being cooked. Turn this parameter on to not transform into the space of the cooking SOP.

Gives the operator a hint about whether the target geometry is moving. This lets the operator choose more effective algorithms for detecting collisions.

Distance from geometry at which particle is considered to have collided.

Controls how the motion of particles is affected by the collision.

Generate this event when any point collides with the target geometry.

The name of a group that will be created to contain the particles that collided. Subsequent operators can use this group to select the particles to affect.

If the group named in the Collision group parameter exists, add the collision particles to the group instead of replacing its contents.

Controls what Houdini sets as the “hit ID” (the identity of the geometry the particle collided with). This lets you distinguish a particle that collided in this POP later.

Number to set in the “hit ID” of collision particles. This lets you distinguish different types of collisions.

Available when Hint (on the Collision tab) is Translating Geometry. Oversamples the motion of the geometry for more accurate collisions.

Available when Behavior is Bounce on collision. The maximum number of inter-frame bounces a particle will perform.

Energy loss tangent to collision.

Energy loss normal to collision.

You can optionally choose a different behavior to use when a particle’s impulse falls below a minimum. For example, if you want particles to stop instead of traveling imperceptibly slowly, set Final behavior to Stop and Minimum impulse to a low number.

Available when Final behavior is not Bounce on collision. The impulse value below which a particle will switch to using Final behavior parameter.

Ensures that the normal component of a bounce on successive collisions is consistent with the first bounce in that frame, when multiple collisions occur within a frame.

Suppose you have set the normal gain on a bounce to be small. This means the particle will tend to bounce parallel to the surface, not away from the surface. Once the particle is traveling parallel to the surface, Houdini could detect another collision, perform a bounce, but because the particle was traveling slightly away from the surface, the particle ends up passing through the geometry when it reflects.

To prevent this, the Enforce Orientation setting records the orientation of the initial bounce with respect to the normal of the surface, and does not apply the normal gain to any bounces with the “wrong” orientation.

You would very rarely turn this off. Some conceivable reasons, however, are:

• To preserve backwards compatibility with a particle system from an older version.

• In your scene it might be legal for a particle to bounce against both the “inside” and “outside” of a piece of geometry within a single frame. In this case, you would have to turn Enforce Orientation off to allow that.

Uses an attribute to ensure orientation consistency across all frames.

The same problem that makes enforcing the orientation within a single frame desirable exists across multiple frames. A legal bounce could occur one frame, and then three frames later the only bounce could be an “illegal” bounce. To detect this, Houdini must keep track of the relative orientation from the first bounce in the earlier frame for each particle.

The name of the attribute to use to enforce orientation across frames.

This attribute should be unique for each Collision POP in the particle simulation which needs to use one, hence the strange default name. Any automatic method of naming this attribute might fail if you have an initial state of a particle system from a different particle network.

It is possible for bouncing particles to leak through the collision geometry. This option adds a corrective step in the collision algorithm which attempts to use the normal of the previous collision to detect and correct leaks.

Turn this on when particles are leaking through the collision geometry with a velocity mostly normal to the surface.

Normal Step Distance and Back Step Distance are the maximum distances to use when performing the respective corrective steps. A back step allows the detection of leaks even when the particle velocity is mostly parallel to the collision geometry.

Increasing the distances will generally tend to reduce the number of leaking particles. There are trade-offs, though: larger distances can cause more stuttering when the corrective step passes through some curvature of the surface.

The name of the attribute to use to store the normal from the previous collision for the normal step correction. This should be unique for each Collision operator in the simulation. This is similar to the Hit Test Attribute parameter.

The maximum distance to use when attempting the normal step correction.

The normal step correction can fail, particularly if the particle has leaked through a sharp corner in polygonal geometry. In that case, it is still possible to detect and correct the leak, but by having the particle step backwards. This parameter is the maximum distance to use when attempting the back step correction.

This correction is done only if the user has specified a hit test attribute and a non-zero back step distance.

This correction does not generally work well on surfaces with smooth curvature and can result in particles moving backwards as they bounce.

Number of times collided ($NUMHIT).

Hit ID ($HITID).

Time of collision ($HITTIME).

Position in space where collision occurred ($HT{XYZ}).

Parametric position on surface where collision occurred ($H{UV}).

Normal where collision occurred ($HN{XYZ}).

Diffuse color at collision ($HC{RGB}).

Texture uv at collision ($HMAP{UVW}).

Distance from current position to collision ($DISTANCE).