MOPs DOPs Tutorial
Important: MOPs Plus is in early access. This means that it is under rapid development and may change significantly before the first full release. Please report any bugs or strange behavior!
MOPs Plus adds new DOP context nodes to help drive simulations using familiar MOPs concepts. These nodes can interact with any dynamics solvers that are point-based, which includes Bullet (Packed RBD), POPs (particles), and Vellum. This means you can use MOPs to control packed primitives and get realistic collision behavior, or use Falloffs or other forces inside DOPs to guide simulations or modify attributes.
A very important distinction between MOPs in SOPs and MOPs in DOPs is that SOPs are procedural and DOPs are not procedural. In the SOP context, you use keyframes to animate parameters over time. Each frame is entirely independent from any frames around it; each frame is solved "just-in-time". For example, let's say you're using MOPs Apply Attributes in SOPs. You have a starting transform, an ending transform, and a falloff value of 0.5. Every frame will evaluate exactly the same way, with the output halfway in between your starting and ending transforms:
Apply Attributes in SOPs with a falloff of 0.5. Every frame is the same.
In DOPs, however, every frame is dependent on the frame prior to it; this is the nature of a simulation. If you have a static falloff value of 0.5, your object will find the halfway point between its current position and the goal position on each timestep. Here's the exact same setup, but using the MOPs Apply Attributes DOP instead of SOP:
Apply Attributes in DOPs with a falloff of 0.5. Every frame is solved based on the results from the previous frame.
It's very important to remember this distinction! You can't use MOPs DOPs in exactly the same way that you'd use regular MOPs. You'll potentially need to use a combination of animated goals in SOPs, animated falloff values, and the Activation parameter built into every MOPs DOP to control how and when objects meet their goal transforms.
All of the example images below are derived from the example files included with MOPs+.
(examples/mopsdops_examples.hip)
The MOPs Apply Attributes DOP is the most fundamental node of the MOPs DOPs system. Given a set of goal transforms (defined by any SOP or DOP data with matching name or id attributes), Apply Attributes will compute the forces necessary to reach those goals and write them to the appropriate point attributes that will then be read by whatever solver you're using (Bullet, Vellum, etc.). These forces are optionally scaled by a falloff attribute, and can be interpreted in a number of ways: you can directly set the transform without forces, update the velocity and angular velocity directly, apply the forces as wind, or use traditional (and bouncy) force and torque attributes. Apply Attributes also supports "snapping", which will temporarily bypass collisions and force the objects to meet their goal transforms that they might not otherwise be able to meet due to collisions or other impeding forces.
(examples/mopsdops_examples_2.hip)
The first thing you'll want to set up when using Apply Attributes is the Inputs tab. This works just like the Inputs tab of a POP Wrangle. Just specify a context geometry (an input to the DOP network) or a SOP path (or a DOP data path if you're feeling fancy). The goal geometry needs to have an id or name attribute to match your simulation geometry. Once that's done, Force Update is your next stop. This is where you define what kind of forces you want to generate to meet your goal transforms. The default, Velocity/Spin with "Treat As Wind" enabled, is generally the most stable and produces the least "twitchy" results while still allowing for collisions. Position/Rotation mode will simply bypass other forces to reach the goals by directly updating the transforms. This is a brute force method, and won't mix well with other forces, but it always gets to the goal. Note that if you want collisions to be solved in Position/Rotation mode, you'll need to connect Apply Attributes to the "Pre-Solve" input of the solver instead of the typical "Post-Solve" input. Speed limit options exist to prevent Position/Rotation from accelerating too quickly at the beginning of a move; if you need speed limits for other Update Modes, use Houdini's POP Speed Limit DOP.
Snapping options ensure that objects will always reach their goals, regardless of collisions or other forces in the scene. Snap by Attribute is the most common method to use here. By default, if this is enabled, once the falloff attribute reaches 1.0 the object will disable collisions and internally switch to the "Position/Rotation" update mode, blending from its current transform to the goal transform over the length of the Snap Time parameter. If you have other strong forces in your scene, you might notice a "hiccup" as the object transitions between these modes. You can try reducing the Snap Time, reducing the strength of these other forces, or adjusting the Snap Ease curve to minimize any visible artifacts.
If you don't enable snapping and you're not using the Position/Rotation Update Mode, you might notice that your geometry is slightly offset from your goal geometry, often in the Y-direction. This is because of gravity or other forces in your scene. Enabling snapping will fix this.
In most cases, you're going to want to handle the bulk of your animation in SOPs, then use Apply Attributes and Falloff nodes to blend between goals as needed. You can use multiple Falloff attributes, each with their own associated MOPs Apply Attributes DOP set to use that Falloff attribute, to blend between any number of SOP goals. For example, here's an animation that shatters and reassembles a mirror twice. One goal is rotating around the Y axis, the other around Z. The first falloff (a spherical Shape Falloff setting mops_falloff) animates on first, reassembling the shattered pieces to match the Y-axis spinning goal. That falloff is then keyframed off, allowing the mirror to shatter again. A second falloff (a linear Shape Falloff setting mops_falloff2) then sweeps in from the side, and the second Apply Attributes DOP (also set to use mops_falloff2!) uses this goal. You could, of course, blend these goal transforms in SOPs instead and use a single Apply Attributes DOP to link to them. It's up to you to determine what's easier to work with for your setup.
(examples/mopsdops_examples_2.hip)
For more specific types of motion, such as movement along a path, pseudo-random noise forces, or local transformations over time, the MOPsDOPs Modifiers are often more appropriate, but if you really just need things to get to a specific point in space I highly recommend keyframing in SOPs and then using Apply Attributes to attract your objects to those keyframed goals.