|On this page|
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 Geometry Spreadsheet 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.
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.
Controls the primary mode of operation for creating relationships.
Number of Relationships
Specifies an exact number of relationships which will be created. The Affector Objects and Affected Objects fields are evaluated once per relationship.
Number of Relationships Per Affected Object
Specifies that a number of relationships will be created for each individual object listed in the Affected Object parameter. The Affector Objects parameter will be re-evaluated for each Affected object.
Number of Relationships Per Affector Object
Specifies that a number of relationships will be created for each individual object listed in the Affector Object parameter. The Affected Objects parameter will be re-evaluated for each Affector object.
Number of Relationships Per Object Pair
Specifies that a number of relationships will be created for each pair of affector and affected objects. The Affector Objects and Affected Objects parameters will be evaluated once to obtain the list of objects that will be paired up
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.
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.
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.
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.
Controls the way in which this variable is evaluated.
Evaluate For Each Copy
The value for this variable is calculated for each relationship. This option provides the most flexibility in terms of generating the global parameter values, but is the most time consuming if large numbers of copies are involved.
The value for this variable is calculated each time the
variable is set to zero. This depends on the Create Relationship
parameter. This approach will not result in each relationship
being customized, but provides an easy way to pass information
from this node up to the input data nodes.
Evaluate Once, One Token Per Copy
The parameter describing this variable is evaluated each time the
REL variable is set to zero, which depends on the Create
In this mode, the String Value is evaluated regardless of the Variable Type parameter. Then for each relationship, the corresponding token within the evaluated string is used to set the global parameter value. The token is treated as a float or string value, depending on the Variable Type parameter. So for example, suppose the Variable Type is Float, the String Value is "0 1 2 3", and the Number of Relationships is 6. The global parameter value set for the 6 relationships would be 0, 1, 2, 3, 0, and 1.
Specifies whether the global parameter is a floating point number or a string value.
The global parameter is a floating point number. The value of this global parameter will be accessed using the stamp expression function in the input data node.
The global parameter is a string. The value of this global parameter will be accessed using the stamps expression function in the input data node.
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.
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.
The first input to this node supplies the objects that can be used when defining the relationships.
The remaining inputs to this node define the nature of the relationships that will be created.
The objects or data input to this node are sent through the single output.
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
INPUT variable can be used.
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.
The index of the relationship input being processed.
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.
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.
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.
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.