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.
The new RBD tools take a few ideas from Vellum, namely configure tools in sops, those sops have multi inputs/outputs, and a RBD solver in sops.
RBD sops function like Vellum sops. You chain together several RBD sops to define behavior, physics attributes, constraints, stuff
RBD sop nodes have multiple inputs and outputs like Vellum sops. This is so you can have your seperate data flows running in parallel through sops, so the first set of inputs/outputs are the RBD geometry, the second is constraints, third is proxy geometry. Generally I'm on board with changes Sidefx make, but I still think this multi in/multi out is confusing and poor design, but I concede its a lost cause. I have to make myself content with complaining on this wiki. And twitter. And social media. And co-workers. And family members. But that's it.
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.
Looking back, my frustration when these nodes first arrived stemmed from not really understanding Vellum, much less ported Vellum concepts to RBD. I think I'm in a better place now, the nodes make more sense.
Download hip: File:rbd_constraint_sops_basic.hip
Chain of things, a rope bridge, a collapsing sidefx logo, you know the deal.
- Assemble sop, ensures you have names on things
- Rbd Constraints from Rules, one of several ways to create the lines between the RBD geo
- RBD Constraint Properties - Only realised very late that the above node ONLY makes the lines, it doesn't set any properties to make them constraints.
- RBD Configure - Used to configure the RBD geo itself, for this example its used to pin the left and right edge. I'm using the bounding type from geometry, so any shapes that fall within the boxes I'm using to mark the left and right edge become pinned.
- rbd bullet solver sop - do the actual solve.
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.