Creates relationships between simulation objects.
The Apply Relationship DOP creates one or more relationships between a group of objects. Relationships control the way that objects interact with each other, as well as controlling the order in which objects are solved in the simulation. Some examples of relationships are constraints, collisions, smoke sources, and simple groups.
In a relationship there are two sets of objects, the affector objects and the affected objects. The same object or objects can be in both groups, in which case there are mutually affecting objects in the relationship. When solving objects, any object that is an affector of another object will be solved before the affected object. The exception to this is mutually affecting objects, which must be solved at the same time.
It it also possible to set up mutually affecting relationships indirectly by creating circular relationships between groups of objects. You can inspect the entire set of affector relationships in a simulation by looking at the Affector Matrix in the Details View for the simulation.
Each relationship type node (Constraint and Collision Relationship, for example) is capable of creating a single relationship between two groups of objects. The Apply Relationship node augments these capabilities by allowing a large number of relationships to be created using a small number of nodes and stamping.
This node’s parameters are divided into two parts. The first part describes the number of relationships that will be created, and the sets of objects that will be the affector and affected objects. The second part defines the stamp variables that can be used by the attached relationship nodes to customize each relationship.
Relationships must each be given a unique name which identifies them. This name can be used to access relationship information using all the same methods that are used to access data on simulation objects.
Tip
Create Relationships should be set to Number of Relationships Per Object Pair when building mutual constraints between two DOPs. This is necessary for the constraint to find the goal objects. You should also enable Make All Objects Mutual Affectors to avoid the one-way affector relationships.
Parameters
| Create Relationships | Controls the primary mode of operation for creating relationships.
| ||||||||
| Affected Objects | These objects are the affected objects in the created relationships. This parameter will be re-evaluated for each relationship if the Create Relationships parameter is set to Number of Relationships Per Affector Object, or Number of Relationships. Otherwise it is evaluated once. | ||||||||
| Affector Objects | These objects are the affector objects in the created relationships. This parameter will be re-evaluated for each relationship if the Create Relationships parameter is set to Number of Relationships Per Affected Object, or Number of Relationships. Otherwise it is evaluated once. | ||||||||
| Number of Relationships | The number of relationships created per affector object, per affected object, per object pair, or an absolute number of relationships, depending on the Create Relationships parameter value. In all but the Number of Relationships setting, this parameter is re-evaluated for each affector, affected, or pair of objects. | ||||||||
| Relationship Name | A unique name that will identify the relationship. This parameter is re-evaluated for every relationship created by this node. If this parameter evaluates to the name of a relationship that already exists (whether or not the relationship was created by this node) it will replace that existing relationship. | ||||||||
| Unique Relationship Name | Turning this parameter on ensures that the name generated by the Relationship Name parameter is unique, thus avoiding any chance of overwriting existing relationships. It can result in longer, harder to use relationship names. | ||||||||
| Make All Objects Mutual Affectors | Turning on this parameter causes each relationship created by this node to put all affected and affector objects into both the affector and affected object list of the relationship. This parameter does not affect the number of relationships created by this node. | ||||||||
| Activation | If this parameter is zero, no relationships are created between the input objects. This parameter is evaluated before creating each relationship, and so can be used to turn off certain relationships. | ||||||||
| Number of Variables | Sets the number of global parameters that will be set for each relationship that is created. These global parameters are accessible from the input relationship nodes using the stamp expression function. | ||||||||
| Variable # Name | The name for this variable. This is the value that must be passed as the second argument to the stamp expression function to access this variable. | ||||||||
| Variable Evaluation | Controls the way in which this variable is evaluated.
| ||||||||
| Variable Type | Specifies whether the global parameter is a floating point number or a string value.
| ||||||||
| Float Value | For a Float Variable Type, when the Variable Evaluation is not Evaluate Once, One Token Per Copy, this parameter controls the value that will be assigned to this global parameter. | ||||||||
| String Value | For a String Variable Type, or when the Variable Evaluation is Evaluate Once, One Token Per Copy, this parameter contains the string value or series of numeric or string tokens that will be used to set the value of this global parameter. |
Inputs
| First | The first input to this node supplies the objects that can be used when defining the relationships. |
| Subsequent | The remaining inputs to this node define the nature of the relationships that will be created. |
Outputs
| First | The objects or data input to this node are sent through the single output. |
Local variables
| REL | The current relationship number. This value will range from zero to (NREL-1). It can be used to set stamping variables, or otherwise customize the relationships. This index does not take into account multiple relationship inputs. For that, the |
| NREL | The total number of relationships that this node will try to create. This value is equal to the Number of Relationships parameter value. It is re-evaluated for each cycle of relationships, as defined by the Create Relationships parameter. |
| INPUT | The index of the relationship input being processed. |
| RELID | This is a simple counter for the number of relationships actually created by this node so far this timestep. Because of changing Activation parameter values and the various Create Relationships methods, this is not something that can be calculated from the other local variable values. |
| AFFECTEDID | If the Create Relationships style is Per Affected Object or Per Object Pair, this variable will contain the object id of the single affected object for this relationship. Otherwise this value will be -1. |
| AFFECTORID | If the Create Relationships style is Per Affector Object or Per Object Pair, this variable will contain the object id of the single affector object for this relationship. Otherwise this value will be -1. |
| ST | 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 |
| SF | 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). |
| 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. |
| SFPS | This value is the inverse of the TIMESTEP value. It is the number of timesteps per second of simulation time. |
| SNOBJ | 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
like |
| NOBJ | 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). |
| OBJ | 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). |
| OBJID | 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). |
| ALLOBJIDS | This string contains a space separated list of the unique object identifiers for every object being processed by the current node. |
| ALLOBJNAMES | This string contains a space separated list of the names of every object being processed by the current node. |
| OBJCT | 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 |
| OBJCF | 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). |
| OBJNAME | 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”,
specifying |
| DOPNET | 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. |
Note
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.
Examples
| ApplyRelationship | Load | Launch |
This example shows how you can use the Apply Relationship DOP to add pin constraints to wire objects. | |
| BridgeCollapse | Load | Launch |
This example shows how to use the Apply Relationship DOP to propagate constraints automatically and create an RBD simulation of a collapsing bridge. | |
| ConstrainedTeapots | Load | Launch |
This example demonstrates how the Apply Relationship DOP can be used to create multiple constraints with the RBD Pin Constraint node. | |
| MutualConstraints | Load | Launch |
This example demonstrates how to build mutual constraints between two DOP objects using the Apply Relationship node. | |
Examples that use this node
| Example for | Example name | |
|---|---|---|
| RBD Angular Spring Constraint | DampedHinge | Load | Launch |
| ||
| RBD Hinge Constraint | Pendulum | Load | Launch |
| ||
| RBD Pin Constraint | Chain | Load | Launch |
| ||
| RBD Solver | PaddleWheel | Load | Launch |
| ||
| Reference Frame Force | ReferenceFrameForce | Load | Launch |
| ||