Dynamics node networks
Dynamics network containers
Dynamics node networks exist inside a DOP Network container node (DOP is short for dynamics operators). This node can exist anywhere in the scene hierarchy. For simulations that are used in the current scene, you can create DOP Networks at the Scene level. If a simulation is to be used inside a digital asset, you can create the DOP Network node inside the asset’s hierarchy.
When you use the shelf tools to create simulation objects, by default they will go into a Dynamics network container called
AutoDopNetwork (and will create it if it doesn’t exist). If you have created a dynamics network yourself and you want the shelf tools to use it instead, right click the
Resimulate button and choose the “current” simulation network (the one in which the shelf tools will create new nodes).
Gray and green connectors
Dynamics nodes have two types of inputs:
Gray inputs are “objects plus data”. The connections pass through or modify objects by adding data to them.
Green inputs are “data”. These represent pieces of data that will eventually be attached to an object or objects using an Apply Data node.
Nodes that attach data usually accept either a gray input (an object or objects to attach the data to), or green inputs (an accumulation of data packets to add to). The type of input connection you make to the node (gray or green) changes the output to the same type.
For example, a simple network consists of an object creation node, forces, and a solver.
This might be called an “inline” or “object-centric” style, where the RBD object passes through the gravity node, which adds
Force data to it, and then to the RBD Solver node, which adds
Solver data to it. This is equivalent to this network:
In this “data-centric” layout, pure
Solver data outputs from the Gravity and RBD Solver nodes are attached to the RBD Object using an Apply Data node.
Note that data nodes attach their piece of data applies to all nodes above them in the network.
In the network above, the Gravity and RBD Solver nodes will attach
Solver data to all three RBD Objects, because the objects are above the gravity and solver nodes in the network. Use Merge nodes and connection branching to control which data gets attached to which objects. It’s especially important to make sure that each object only gets one solver attached (but see solvers to learn how to have multiple solvers affect an object).
Display, bypass, and activation
Similarly to a particle or surface node network, the blue Display flag marks the “output” or “endpoint” node of the network: only nodes above and including the node with the display flag will be part of the simulation.
DOPs have a bypass flag so you can check the state of the simulation with and without a given node, usually for debugging the creation of data in the details view (see below).
If you want to animate the presence of objects or data, keyframe the given node’s Activation parameter. When Activation is non-zero, the node is active and affects the network. When Activation is zero, the node has no effect, similar to having the bypass flag on.
Nodes to manipulate data
Empty Data node creates new data (similar to AttribCreate node in geometry networks).
Modify Data node edits the values of data fields.
Delete node removes objects or data based on patterns.
Moving data between nodes with Fetch Data
The Fetch Data node node can copy data from an object anywhere in the network onto another object. This includes numeric data such as velocity, or more complex data such as an object’s geometry. Fetch Data is the only node that’s allowed to know about data not in its inputs.
This is a generally useful technique to use information from one part of the simulation to drive another. For example, if you want a vortex force to follow an object (as in, a tornado following a car), you can fetch the object’s
position data and copy it onto the vortex force.