Constraint Networks 3: A new hope.
I've been building my own constraint lines so far because it made it nice and clear in my head. Since 17.5 there's been a bunch of sops to help make these things for you. When they arrived I had a quick play, couldn't make them work, swore, didn't touch them again.
Well we're now at 18.5, I'm on a project that needs RBD again, seemed a good time to dive back in.
Multi outputs and modularity
The new RBD tools take a few ideas from Vellum:
- RBD sops function like Vellum sops, you chain them together to define behavior, constraints, stuff
- RBD sop nodes have multiple inputs and outputs like Vellum sops (grr), first is geometry, second is constraint geo, third is proxy geo.
- RBD now has a solver in sops to hopefully handle most of the stuff you want to do, so you don't have to wire up complex dopnets every time.
My initial frustration stemmed from not really understanding Vellum at the time, much less ported Vellum concepts to RBD, hence confusion and fury.
If you remember from the previous section the way to pin an rbd object was to:
- Duplicate the point
- Create a line between those points
- Give the line prim a @constraint_name
- Set one end of the points to have @name = ""
- Create a constraint network in dops (which is another 4 or 5 nodes and easily broken).
Quite a lot of work, lots of places to make mistakes. Here's how you do it with the new workflow:
Yep, a single checkbox.
The RBD Configure sop makes this setup trivially easy to do, and because it presents itself like a regular sop should, you can use groups to define the pinned geo, or a bounding box selector built into the sop. It's pretty handy. However...
Download hip: File:rbd_pin_slidey.hip
Most of the time you want a pin locked down, immovable, and that's the default behaviour. But as you can see in the gif I had an issue; if the shapes intersected while pinned, they'd go on intersecting. The pins are too strong, and didn't allow for any play.
From inspecting the geo attributes and thinking about it just now, I realised my original method wasn't really pinning as suggested by Sidefx; they use attributes to pin, while I was making constraints to lock things in place.
At any rate, the default behaviour doesn't give you any controls over the pin strength. This little setup takes the pins, removes the pin specific attributes, and renames them to be default constraints. This now allows for hard-but-slippy constraints as shown in the middle, which allows shapes to push past each other, or soft constraints, which allows for a little bit of spring behaviour.