The system was integrated for industry applications like realistic physic simulations for robotics or the training of neural networks. But it can also be used in games where a high precision physics simulation is needed. For example physics-based puzzles.
Some parts of the feature are still buggy or not completely implemented yet. Especially the spherical joint seems to exhibit a lot of bugs that crash Unity’s physics system and should be avoided at the moment.
The feature is still new and documentation is rare. If you need more detailed information look at my documentation post. It’s a list of the best documentation sources I found on the internet so far. Following is a short overview of the advantages and constraints of articulation bodies:
- Accurate physics simulation with high mass ratios, drive models and better dynamic stability. It’s built for the modelling of real-world physics for industry applications.
- Guaranteed no jitter and simulation errors because it uses a constraint coordinate system. The constraints and limits are always respected which makes the joints not stretchable.
- Scales with DoF (degrees of freedom) instead of the number of rigidbodies. The number of articulation bodies the DoF are distributed over is irrelevant. The system doesn’t scale with the number of bodies.
- Mixed setups with articulation bodies and rigidbodies are possible. They affect each other and collide correctly. There is no need to use articulate bodies exclusively.
- Easy to edit with built-in gizmos and a small set of variables.
- No transform manipulation. Really, you can’t move these things by changing the transform component. The change will be ignored. The bodies are stable because they can’t be manipulated outside the physics calculations. Side effect: you can’t move articulation bodies in the editor at runtime using gizmos. At the start, it’s super annoying but you get used to it.
- Must use forces or the drive property of the articulation bodies to manipulate them. Only the root is an exception and can be teleported in code by calling ArticulaionBody.TeleportRoot.
- Can’t be kinematic. If you want to make an articulation body kinematic connect it with a fixed joint to a kinematic rigidbody.
- Constrains object setup. The object hierarchy defines the relation between the articulation bodies.
- No circular dependencies because the objects must be ordered in a tree structure for the physics solver to work. This constraint can be bypassed by making the last link with a rigidbody joint.
- The force applied to a joint can’t be retrieved.
- Hierarchy is fixed. It’s difficult to change the articulation body hierarchy at runtime because it will reset the physics simulation of the complete articulation tree. The objects lose their state. Every object in the hierarchy will snap back to its original state.
- GameObject.SetActive is problematic. Disabling an articulation body has the same implications as changing the hierarchy. The physics state is reset. But it can be coped with by storing the current state of the articulation tree and restoring it on enable. My solution for this inconvenience is here.
- Prefabs are problematic. Don’t try to make parts of an articulation body hierarchy into a prefab. It breaks the physics hierarchy and behaves oddly.
The documentation states that the articulation bodies are more expensive to simulate but I didn’t see any major performance bottlenecks so far.