Difference between revisions of "ConstraintNetworks3"

From cgwiki
 
(11 intermediate revisions by the same user not shown)
Line 5: Line 5:
 
Well we're now at 18.5, I'm on a project that needs RBD again, seemed a good time to dive back in.
 
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 ===
+
=== New workflow ===
  
 
[[File:rbd_sops.png]]
 
[[File:rbd_sops.png]]
  
The new RBD tools take a few ideas from Vellum:
+
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 them together to define behavior, constraints, stuff
+
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 (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.
+
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 to fight it. I have to make myself content with complaining on this wiki. And twitter. And social media. And to 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.
 +
 
 +
Fun side fact; these tools don't require packed geo. In fact for some of the constriant tools, they work better without packing (eg, constraints can be made between the surfaces of things rather than from centroids), in those cases just let all your polys hang out, and the RBD solver sop will helpfully pack for you.
  
 
=== Standard constraints ===
 
=== Standard constraints ===
Line 25: Line 29:
 
Chain of things, a rope bridge, a collapsing sidefx logo, you know the deal.
 
Chain of things, a rope bridge, a collapsing sidefx logo, you know the deal.
  
* Assemble sop, ensures you have names on things
+
* '''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 Constraints from Rules''', one of several ways to create the lines between the RBD geo. Note that it ONLY makes the lines, for this to work with RBD requires attributes, which you get with a...
* 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 Constraint Properties''' - Set constraint type, stiffness etc.
* 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 Configure''' - Used to configure the RBD geo itself. You can select by group, or direct selection, or in this case intersecting with some boxes. The selection is used to pin the left and right sides.
* rbd bullet solver sop - do the actual solve.
+
* '''RBD bullet solver''' sop - do the actual solve.
  
 
=== Pins ===
 
=== Pins ===
  
If you remember from the previous section the way to pin an rbd object was to:
+
If you read the previous sections then you'll know my workflow for creating constraints:
  
 
* Duplicate the point
 
* Duplicate the point
 
* Create a line between those points
 
* Create a line between those points
* Give the line prim a @constraint_name
+
* Give the line a @constraint_name
* Set one end of the points to have @name = ""
+
* Set one of the points to have @name = ""
 
* Create a constraint network in dops (which is another 4 or 5 nodes and easily broken).
 
* Create a constraint network in dops (which is another 4 or 5 nodes and easily broken).
  
Line 55: Line 59:
 
Download hip: [[:File:rbd_pin_slidey.hip]]
 
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.
+
...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.
 
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.
 
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.

Latest revision as of 21:25, 4 January 2021

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.

New workflow

Rbd sops.png

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 to fight it. I have to make myself content with complaining on this wiki. And twitter. And social media. And to 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.

Fun side fact; these tools don't require packed geo. In fact for some of the constriant tools, they work better without packing (eg, constraints can be made between the surfaces of things rather than from centroids), in those cases just let all your polys hang out, and the RBD solver sop will helpfully pack for you.

Standard constraints

Rbd sops simple2.gif

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. Note that it ONLY makes the lines, for this to work with RBD requires attributes, which you get with a...
  • RBD Constraint Properties - Set constraint type, stiffness etc.
  • RBD Configure - Used to configure the RBD geo itself. You can select by group, or direct selection, or in this case intersecting with some boxes. The selection is used to pin the left and right sides.
  • RBD bullet solver sop - do the actual solve.

Pins

If you read the previous sections then you'll know my workflow for creating constraints:

  • Duplicate the point
  • Create a line between those points
  • Give the line a @constraint_name
  • Set one 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:

Rbd pin setup.gif

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...

Slidey pins

Rbd pin slidey.gif

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.