|On this page|
The constraint network defines pairs of RBD objects that should be constrained together.
With the constraint network, SOP Geometry is specified which defines what
objects should be constrained. This makes it easy to procedurally generate a
set of constraint relationships, including constraints of different types. Each
point in the geometry represents a constraint anchor, according to the
P attributes. Each two-point polygon represents a constraint, according
to the constraint data specified by the
Advanced users can use the
attributes to dynamically change constraint types with animation or a
If a constraint is broken by a solver (such as when sufficient force is applied
to break a glue bond), the primitive will be placed into a primitive group
broken. That primitive group can be used in a SOP Solver
to trigger events such as emitting debris when a constraint breaks. Any
constraints that are in the
broken primitive group will be ignored by solvers
on subsequent frames. Currently, only glue constraints will be broken by the
Constraints can also be broken by using a SOP Solver to delete primitives from
the constraint network’s geometry. For linear constraints, the
distance primitive attributes are updated by the solver to contain the force
applied to satisfy the constraint and the distance between the anchors,
respectively. For angular constraints, the
attributes are updated by the solver to contain the torque applied to satisfy
the constraint and the angle (in radians) between the anchors. For glue
impact primitive attribute is updated
by the solver to contain the accumulated impulses for the glue bond. These
attributes can be used to remove a constraint when certain conditions are met.
Each point in the constraint geometry represents an anchor. All constraints are
made up of two anchors. Currently there are 4 different types of anchors,
specified by the
anchor_id point attributes.
A World Space Anchor is an anchor that is simply placed at a static world space
position, specified by the
P attribute on the anchor. If an anchor has an
empty value for the
name attribute, then the anchor is treated as a World
Space Anchor. If the
name attribute specifies an invalid name, the constraint
A Relative Offset Anchor is an anchor that is placed at specific position
relative to a simulated object. This position is fixed to the object’s initial
rotation, so if the object is rotated during the simulation the anchor rotates
with it. If the
name attribute specifies a valid object, and the
attribute is set to
-1 (or is not defined), then the anchor is treated as a
Relative Offset Anchor, with the
P attribute specifying the offset from the
A Point Anchor is an anchor whose position is bound to that of a certain point
on the geometry of a simulated object. When the
name attribute is valid and
anchor_id attribute is a valid point index, then the anchor will be
placed at the specified point. Alternatively, if the
anchor_type attribute is
vertex (the default is
point) then the anchor will be placed at the
point referred to by the vertex with the index in
In cases where the geometry of a simulated object changes over the course
of a simulation, anchoring to a point by specifying a point (or vertex)
index in the
anchor_id attribute may not yield correct results. This is
because as the geometry changes, point and vertex indices may also change,
meaning the Point Anchors could end up referring to different points than
at the beginning of the simulation.
To fix this, add the integer point attribute
anchor_pid or the integer
anchor_vid to the simulated object whose geometry may
change. If either of these attributes exist, then the
on the anchor will match to the first point (or vertex) with the same
anchor_vid) value on the simulated geometry. This way as
the geometry changes, the attributes will stay the same.
An Agent Anchor is an anchor that is attached to a transform in an agent’s rig.
The transform does not need to be associated with a simulated object (i.e. the agent’s collision layer does not need to have a shape attached to the transform).
agent and the
name attribute references an agent’s transform (e.g.
local_orient attributes can be used to specify the local transform of the anchor.
You can create attributes on the geometry to customize each constraint’s behavior and type.
If a primitive attribute with the same name as a constraint property (such as
damping) is present, the attribute value will be multiplied with the value from the constraint sub-data if the data type is
For other data types, a primitive attribute will override the value from the constraint sub-data.
The following attributes can be used to control the type of constraint described by each primitive.
Specifies the Data Name of the constraint to create. If this attribute is not present or the name is invalid, no constraint will be created from the primitive. This attribute can be modified in a SOP Solver to change the constraint’s type during the simulation.
Specifies whether the constraint affects
Specifies a new value for the
Specifies a new value for the
Specifies the number of impact propagations for all glue bonds in the constraint network.
In Houdini 17, the number of propagation iterations can instead be varied per glue constraint with the
The following attributes are created by the solver to provide information about how the constraints behaved during the previous timestep. These attributes can be used to control when constraints are broken.
||Primitive||Float||The current angle (in radians) between the two anchors.|
||Primitive||Float||The current distance between the two anchors.|
||Primitive||Float||This attribute stores the magnitude of the force that was applied to satisfy the constraint during the previous timestep.|
||Primitive||Float||For glue constraints, this attribute is updated by the solver with the accumulated impulses for the glue bond, as impacts occur and propagate through the network.|
||Primitive||Float||This attribute stores the magnitude of the torque that was applied to satisfy the constraint during the previous timestep.|
The following attributes can be used to control how the anchor points are attached to objects.
If this attribute is defined and refers to a valid point (or vertex depending
on the value of
If the value is set to
Specifies if the anchor is attached to a
If the number of constrained degrees of freedom is 1, this value defines the normal of a plane that the object can move along or rotate about any axis in. If the number of constrained degrees of freedom is 2, this value defines an axis that the object can move or rotate about.
Identifies the number of constrained degrees of freedom for an anchor:
Identifies the object to which the constraint is attached. An empty name indicates that the constraint is attached to a world space position.
For the Bullet solver’s glue constraints, attaching to a world space position is not supported.
For RBD Packed Objects, the
Identifies the initial world space orientation of the anchor. If
||Point||Vector||Identifies the initial world space position of the anchor.|
Identifies the initial world space orientation of the anchor as Euler angles.
||Point||Vector||Identifies the velocity of the world space position to which the constraint is attached.|
Identifies the angular velocity of the world space position to which the constraint is attached.
For RBD Packed Objects, the name point attribute from the DOP object’s geometry is used to identify which object to attach the constraint to. Since multiple RBD Packed Objects may contain packed primitives with the same names, the identifier can optionally be prefixed by the DOP Object name (e.g.
object2/piece3) to avoid name conflicts and uniquely identify the object. For all other types of objects, the DOP object name is used as the identifier.
When switching a setup from using an RBD Packed Object to an RBD Fractured Object, ensure that the anchor names are not prefixed with the DOP Object name so that the constraint network is compatible with both object representations.
Specifies the source of the constraint network geometry.
Use the SOP specified by the SOP Path parameter.
First Context Geometry
Use the SOP connected to the DOP network’s first input.
Second Context Geometry
Use the SOP connected to the DOP network’s second input.
Third Context Geometry
Use the SOP connected to the DOP network’s third input.
Fourth Context Geometry
Use the SOP connected to the DOP network’s fourth input.
The SOP geometry to use to determine the constraints.
Use Object Transform
Turn on this option to embed the transform from the parent object of the SOP along with the geometry.
Overwrite with SOP
This flag will re-import the network whenever it is set, allowing a completely animated constraint behavior.
Show Guide Geometry
Turning on this option causes guide geometry to be displayed in the viewport representing this constraint.
Attach Internal Constraints to Object
The default behavior is to attach the constraint geometry to a relationship between the objects, which allows constraints to be anchored to multiple DOP objects.
If constraints only need to be between packed primitives in a single DOP object, this option allows the constraint geometry to be attached to the DOP object’s
ConstraintGeometry subdata instead of a relationship.
In this mode, constraints can be modified during the timestep with a SOP solver that processes the object’s
ConstraintGeometry subdata (for relationships, any attached solvers are run at the beginning of the timestep before solving any objects).
Specifies the affected DOP objects in the created relationship.
A unique name that will identify the relationship.
Determines if this node should do anything on a given timestep and for a particular object. If this parameter is an expression, it is evaluated for each object (even if data sharing is turned on).
If it evaluates to a non-zero value, then the data is attached to that object. If it evaluates to zero, no data is attached, and data previously attached by this node is removed.
Objects To Be Processed
The objects to apply this relationship to, that will be eligible for being constrained by the object name attribute.
Constraints To Create
The constraints that can be created using the primitives in the SOP geometry.
SOP solvers may be attached to update the constraint network dynamically in response to events. Only a single geometry is shared by all the objects, so this solver is executed once per relationship, not per object.
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.
This value is the simulation time for which the node is being evaluated.
This value may not be equal to the current Houdini time represented by the variable T, depending on the settings of the DOP Network Offset Time and Time Scale parameters.
This value is guaranteed to have a value of zero at the
start of a simulation, so when testing for the first timestep of a
simulation, it is best to use a test like
$ST == 0 rather than
$T == 0 or
$FF == 1.
This value is the simulation frame (or more accurately, the simulation time step number) for which the node is being evaluated.
This value may not be equal to the current Houdini frame number represented by the variable F, depending on the settings of the DOP Network parameters. Instead, this value is equal to the simulation time (ST) divided by the simulation timestep size (TIMESTEP).
This value is the size of a simulation timestep. This value is useful to scale values that are expressed in units per second, but are applied on each timestep.
This value is the inverse of the TIMESTEP value. It is the number of timesteps per second of simulation time.
This is the number of objects in the simulation. For nodes that create objects such as the Empty Object node, this value will increase for each object that is evaluated.
A good way to guarantee unique object names is to use an expression
This value is the number of objects that will be evaluated by the current node during this timestep. This value will often be different from SNOBJ, as many nodes do not process all the objects in a simulation.
This value may return 0 if the node does not process each object sequentially (such as the Group DOP).
This value is the index of the specific object being processed by the node. This value will always run from zero to NOBJ-1 in a given timestep. This value does not identify the current object within the simulation like OBJID or OBJNAME, just the object’s position in the current order of processing.
This value is useful for generating a random number for each object, or simply splitting the objects into two or more groups to be processed in different ways. This value will be -1 if the node does not process objects sequentially (such as the Group DOP).
This is the unique object identifier for the object being processed. Every object is assigned an integer value that is unique among all objects in the simulation for all time. Even if an object is deleted, its identifier is never reused.
The object identifier can always be used to uniquely identify a given object. This makes this variable very useful in situations where each object needs to be treated differently. It can be used to produce a unique random number for each object, for example.
This value is also the best way to look up information on an object using the dopfield expression function. This value will be -1 if the node does not process objects sequentially (such as the Group DOP).
This string contains a space separated list of the unique object identifiers for every object being processed by the current node.
This string contains a space separated list of the names of every object being processed by the current node.
This value is the simulation time (see variable ST) at which the current object was created.
Therefore, to check if an object was created
on the current timestep, the expression
$ST == $OBJCT should
always be used. This value will be zero if the node does not process
objects sequentially (such as the Group DOP).
This value is the simulation frame (see variable SF) at which the current object was created.
This value is equivalent to using the dopsttoframe expression on the OBJCT variable. This value will be zero if the node does not process objects sequentially (such as the Group DOP).
This is a string value containing the name of the object being processed.
Object names are not guaranteed to be unique within a simulation. However, if you name your objects carefully so that they are unique, the object name can be a much easier way to identify an object than the unique object identifier, OBJID.
The object name can
also be used to treat a number of similar objects (with the same
name) as a virtual group. If there are 20 objects named “myobject”,
strcmp($OBJNAME, "myobject") == 0 in the activation field
of a DOP will cause that DOP to operate only on those 20 objects. This
value will be the empty string if the node does not process objects
sequentially (such as the Group DOP).
This is a string value containing the full path of the current DOP Network. This value is most useful in DOP subnet digital assets where you want to know the path to the DOP Network that contains the node.
Most dynamics nodes have local variables with the same names as the node’s parameters. For example, in a Position node, you could write the expression:
$tx + 0.1
…to make the object move 0.1 units along the X axis at each timestep.
This example demonstrates how different anchor positions can affect pin constraints.
This example demonstrates how angular motors can be used with pin constraints to create a denting effect.
This example shows how to use a SOP Solver to break spring constraints in a constraint network that have stretched too far.
This example shows how to create a chain of objects that are connected together by pin constraints.
This example shows how to gradually remove glue bonds from a constraint network and control the crumbling of a building.
This example shows how to create a constraint network to glue together adjacent pieces of a fractured object. It also shows how primitive attributes such as 'strength' can be used to modify properties of individual constraints in the network.
This example demonstrates how to use pin constraints to create hinges between objects.
This example shows how to create a basic constraint network with point anchors.
This example shows how to create a simple network of soft constraints, which are used to allow an object to bend before breaking.