It is often said that you should not parent rigidbodies and esp. not objects connected by joints.
But how do you group together a compound object like a car? Do you really just dump the individual parts into the scene? How about a prefab for the whole car?
I tried just creating a parent object and added a rigidbody and a fixed joint to one of the children. That does seem to do the trick, but feels a bit hacky. After all, I don’t really want this “dummy” rigidbody to influence the physics of the whole object.
I could leave out the rigidbody and fixed joint in the parent object all together, but then the children move independently which is a bit of a nuisance when I want to move the object as a whole.
From my perspective it’s perfectly fine to group any number of rigidbodies under a gameobject.
You should however not parent one rigidbody to another.
Using prefabs to group some interacting or linked rigidbodies is a great idea too. Otherwise instantiating and placing all of the parts would be a real pain, right? Maybe it „doesn’t feel right“ that the parent gameobject doesn’t reflect the position of its children after simulation starts, so translating the whole car to another place might be tricky, but then you can as well just destroy the old car and instantiate a new one easily.
You have to consider that the physics engines (Physx or Box2D) know nothing whatsoever about Unity Transforms or the Transform hierarchy but we have to jump through all sorts of hoops to make them play nicely together.
Placing a Dynamic Rigidbody(2D) as a child of another one leaves us with a problem. Does the user want the Parent to drive the child? Does the user want the Child to move independently? The answer of course is that we have no idea so we have to choose something. What we do is that we only support it when you’re doing Kinematic motion so if the child Rigidbody(2D) is Kinematic then we “follow” the parent.
What actually happens is that we have to sort the Rigidbody(2D) write-backs to the Transform into hierarchy order so that we write the parent poses first followed by the children down the hierarchy. This is because if you set a parent Transform then the children are repositioned. We don’t want this to mess up the child Rigidbody(2D) so we have to write poses from the root to the leafs.
So we do all this even though when the simulation runs it doesn’t know about Transforms. It only knows about bodies, joints etc. The resultant poses have to be written back to the Transforms and there’s a hierarchy there.
It’s worth considering this when thinking about the what, why and how. Unity, its GameObjects, Components and Transforms don’t simulate, an independent physics engine does.
So in short, it’s best to not nest Rigidbody and keep them as close to the root as possible. But if you don’t want to do that then don’t but know we’re doing the work to ensure you get predictable results. Again, the only “physics behaviour” when nesting is when the children are Kinematic, the rest should act like independent Rigidbody(2D) effectively splitting the hierarchy.