ArticulationBody with multiple parents

Unity Engine
,
1

The new ArticulationBody component is a much needed addition to enable stable physics joints for simulating machinery.

However, I have some cases where a single body should be connected to multiple parent bodies (see attached image). As far as I know, this is currently not supported.
Is there a workaround? Is it something that is planned to be added in future releases?

In the attached image, the lower (blue) frame is suspended by two (red) hinges to an upper (blue) horizontal bar. The lower frame swings, depending of the orientation of the whole machine, and should stabilize itself.

6047198--653753--DMS.JPG

2

It would be great to get some feedback on this :wink:

3

Yes, I’d love to know more as well. Summoning @yant … :wink:

4

You can’t have loops or multiple parents in articulations, it has to have tree like hierarchy. This isn’t Unity or PhysX limitation either, it’s basic limitation of the algorithm used on it.

There is a workaround for this though and it is to connect articulation bodies with regular physx joints. You will not get similar level robustness for these connecting joints as you get for the articulation ones but with clever design you can probably minimize the negative impacts from this. Unity supports regular joint connections to articulations since 2020.2.0a15.

As example, Nvidia did showcase dual wishbone vehicle suspension with articulations:

Obviously this can’t happen with pure articulation setup so one of the links on the suspension chain had to be a regular joint.

2 Likes
5

Thanks for your tip for working around this limitation!
Do you have by any chance a link to the example of the dual wishbone suspension you mention?

6

I dunno if there’s some nvidia provided examples for this but they won’t do you any good with Unity as you assemble things differently through Unity’s physics wrappers anyway. Doing the basic setup for a thing like that should be pretty straight forward though.

7

Is this still not supported?

8

Condering it’s this way by design (as in, how the algorithm behind this works), why would it be any different now? :slight_smile: This feature is essentially a wrapper for Physx functionality and there’s no multiparent setup on their articulation.

9

Is this still not supported?

10

Let me emphasise what @rz_0lento posted above. It’s a current limitation of PhysX, directly inherited from the specifics of how Featherstone’s forward dynamics work.

11

While this is technically true, PhysX provides a method to get around this: Here

"Articulations are tree structures and do not support closed loops natively. PhysX can simulate closed loop systems by the use of joints. Additionally, contacts between links and other rigid bodies (e.g. the ground) can form loops if more than one link has contacts. These joints and contacts are solved by the rigid body solver during PhysX simulation, but it is often desirable to factor these constraints into inverse dynamics.

To facilitate this, PhysX provides a mechanism to register loop constraints with the articulation:"

PxJoint* joint = ...;

articulation->addLoopJoint(joint);

articulation->removeLoopJoint(joint);

I doubt Unity exposes that stuff though

12

From my previous post in this thread ( https://discussions.unity.com/t/798453/4 ):

13

It’s hard to tell from the wording on the Physx documentation site that I quoted, but it seems to me the the addLoopJoint method is the more proper way to do it whereas the connect a articulation to a rigidbody via joint is more a workaround. Not sure though

14

I have a similar situation/requirement. When connecting rigidbodies via fixed or hinge joint to articulationbodies, force that acts on the rigidbody doesn’t seem to get transfered to the articulationbody, in my case this means drive input (prismatic type) on the articulation body that moves the rigidbody towards a collider makes the rigidbody somewhat stop at the collider, but without impeding the motion of the articulation body.

Is there any workaround