I made a simple example where two packed rbs (one animated and one active) are constrained via one hard constraint. I would expect the active object to fall and swing under the animated object. But instead everything stays still... If I change the name on the constraint geometry point that attaches to the animated object to an empty string "" then the active object will swing as expected below that constraint point- so I believe the constraint is working.

In the attached example notice everything stays still- and if you enable the wrangle on the bottom right (sets name to "") then it "works"...

It almost feels like a bug- that the constraint doesn't work when attached to the animated rbd...

I think this has to do with the location of the constraint anchor points (the 'AnchorPins' helpcard example is a good visualization of how the anchor locations affect the behaviour). The hard (pin) constraint works by enforcing that the two anchors have the same position and/or orientation.

In the scenario where 'restlength' is being used, internally this just shifts the first anchor point towards the second anchor by that distance. In your setup, this means that both anchors are initially positioned in the middle of the active object. Since the inactive object can't move, the two anchor points essentially stay at the same position and prevent the active object from moving.

I think you want to flip this around so that the anchors are positioned on the static object, letting the active object rotate around that pivot. You can use a Reverse SOP to flip the vertex order on your constraint primitives.

cwhite
I think you want to flip this around so that the anchors are positioned on the static object, letting the active object rotate around that pivot. You can use a Reverse SOP to flip the vertex order on your constraint primitives.

Thanks- that does then behave as you desribe.. Using "anchor logic" then I can also co-locate both anchor points at the center of the inactive object, and use a restlength of zero (same as not using restlength I guess) and get the desired swinging relationship (active object swinging around the location of the inactive object) and not have to worry about the point order... Maybe that is a more robust way of setting this up on a larger scale since point order never has to be considered? Though maybe the downside there is it's harder to visualize which objects are constrained to which via the constraint geometry in SOPs.. hmm..

Thanks for pointing out the meaning/importance of anchor relativity