I have a child object with a box collider and a kinematic Rigidbody2D. The parent object is a polygon collider with a non-kinematic Rigidbody2D and a Hinge Joint 2D connected to the world point right in the middle of it.
The “child” is a force-field beam that protrudes from the “parent” which is the base emitter of the beam.
In the old 3D physics, this kind of setup would allow the player to rotate the parent emitter object around a hinge joint and have the child beam object follow the rotation exactly.
However, for some reason in the new 2D physics, the child kinematic RB seems to retain inertia, and attempts to resist its parent’s rotation, behaving as though it weren’t kinematic.
Show me how you have you object setup and I’ll tell you how to fix it. The hinges in the 2D stuff is a tad annoying and kinematic RG’s don’t seem to do what they used to anymore. If you want to send over your scene I’ll take a look and let you know a solution.
Thanks for the offer.
Hopefully this image (right-click/view-image to see at full size) gives an understanding of the most basic possible description of what’s going on. You can see the details of both parent and child locked in the two separate Inspector windows.
The parent is hinged and is trying to rotate.
The child has a Kinematic RB2D and will not move with the parent.
The child would move with the parent if its RB2D was removed entirely, leaving just the box collider, but then its collider simply becomes a compound child collider of the parent’s RB2D… which means any collisions it runs into will slow/stop the rotation of the entire assembly (in this case, the top cube which is a static obstacle).
This all worked dandy in 3D physics as a kinematic child did nothing but follow its parent - and it would not affect or stop the movement of the parent if the child ran into an obstacle.
Just rotating with rigidbody2D.AddTorque(5f); in FixedUpdate().
I’m not sure what the deal is with the gap, exactly, though I also noticed it seems to affect the issue. It seems as though if it’s close, it won’t rotate at all, if it’s medium distance it will rotate a bit with the parent but then glitch out and get stuck behind. At far distance it works pretty well. Doesn’t that look like a bug? I did submit a report last week but no reply yet.
The problem is that in my actual game (which I can’t post/show here) the parent collider is concave, and the child collider is a “beam” that must originate close inside a concave curve of the collider - otherwise its gameplay function isn’t served.
I would love to at least have an explanation of this weird behaviour so I can at least predict when and why these things happen in the future. 3D Kinematic bodies functioned way more predictably in my experience.
Cancel everything good we’ve said about increasing the distance. It still doesn’t move at any distance - only the graphic does! If you keep the child selected and watch it in the scene view while it rotates, the box collider invisibly stays at its original position the whole time - even though its GO is apparently rotating around with the parent.
If (and only if) the child’s Sleeping Mode is set to “Never Sleep,” then even the graphic won’t rotate with its parent at any distance - the whole thing just stays locked in place.
For a workaround you may be able to unparent the child object and use a script to synchronise its position and orientation, eg locking it to a true, but non-RB, child. It is naff but might be ok as a workaround.
This bug has been fixed and has been released to an internal alpha release.
The change not only involves updating child kinematic bodies but also ones that may be sleeping. Also, the update order is now based upon the transform hierarchy, identical to 3D physics.
And when will this fix be available to the general public?
I’m running the latest Unity and I’m still experiencing this problem. And my children don’t even need to be kinematic, regular rigidbodies2d don’t behave normally either!
