(17-11-2021, 02:32 PM)spakment Wrote: but doesn't the physx engine's solver takes care of the distribution across the articulation?
Yes, but no: I mean, when you call articulation.AddForce(), PhysX does this stuff under the hood for you. The problem with this is that
you can only call this from Unity's main thread. Obi is fully multithreaded, using Unity's single-threaded API would absolutely obliterate performance: stall the task queue, bring impulse data to the main thread, call AddForce for each one, then write back data and resume simulation.
Also, this would only take care of one-way coupling: particles would be able to affect articulation bodies, but articulation bodies would not be able to affect particles (since they know nothing about them).
Obi internally uses its own representation of
all collider types as well as rigidbodies. At runtime it keeps both PhysX's representation of these objects and its own representation in sync. This allows it to interface with PhysX as if both were part of the same simulation. This is what ObiCollider and ObiRigidbody components do in a nutshell.
So we need to similarly replicate articulation bodies and implement a good chunk of their functionality in Obi.
(17-11-2021, 02:32 PM)spakment Wrote: Each articulation has a collider (in my case it's usually a capsule on each articulation) to have the rope be affected by the articulation with a collider component can I just add a ObiCollider to it? So long as the articulation affects the rope it doesn't matter in this instance that the rope doesn't affect the articulation body...
Haven't tried it, but there's a pretty high chance this will work. Colliders are completely independent from rigidbodies, so a collider in an articulation body would seem like a regular static collider to Obi. The articulation will behave as if no rope was present though.