| Both sides previous revision
Previous revision
Next revision
|
Previous revision
Next revision
Both sides next revision
|
hingejoint [2021/04/30 16:31]
151.202.25.206 |
hingejoint [2021/05/01 16:46]
73.95.178.156 |
| ====== HingeJoint ====== | ====== HingeJoint ====== |
| |
| A common misconception ((Or at least, a misconception held by me, the author of this page)) is that ''HingeJoint'' constrains the ''rotation'' or ''localRotation'' of the ''Transform'' that it is attached to. This is not strictly true. **''HingeJoint'' only constrains the relative rotation between its own ''RigidBody'' and the ''Rigidbody'' in the ''ConnectedBody'' field**. | === Misconceptions === |
| | * ''HingeJoint'' does not constrain the absolute ''rotation'' or ''localRotation'' of the Transform that it is attached to. It constrains the **relative** rotation between its own RigidBody and the Rigidbody in the ''ConnectedBody'' field. |
| |
| Another common misconception is that ''HingeJoint.angle'' and ''HingJoint.axis'' represent the ''rotation'' of the ''Transform'' that it is attached to. This is also not strictly true. That is, **''Quaternion.AngleAxis(hingeJoint.angle, hingeJoint.axis)'' does not necessarily equal ''hingeJoint.transform.rotation'' or ''hingeJoint.transform.localRotation''**. | * ''HingeJoint.angle'' and ''HingJoint.axis'' do not represent the rotation of the Transform that it is attached to. Ex: ''Quaternion.AngleAxis(hingeJoint.angle, hingeJoint.axis)'' does not equal ''hingeJoint.transform.rotation'' or ''hingeJoint.transform.localRotation''. |
| |
| These two misconceptions, taken together, can make a ''HingeJoint'' behave quite differently from what you might expect. | These two misconceptions, taken together, can make a ''HingeJoint'' behave quite differently from what you might expect. |
| |
| An example: Consider a ''GameObject'' with rotation ''(0, 0, 0)'' and a ''HingeJoint'' on the x-axis with limits of ''[-90, 90]''. When played as-is, this ''GameObject'' will be free to rotate between ''(-90, 0, 0)'' and ''(90, 0, 0)''. However, if you rotate this ''GameObject'' in the editor such that it starts with rotation ''(90, 0, 0)'' and play it, the ''GameObject'' will then be free to rotate between ''(0, 0, 0)'' and ''(180, 0, 0)'' - even though the angle limits have not changed. | An example: Consider a ''GameObject'' with rotation ''(0, 0, 0)'' and a ''HingeJoint'' on the x-axis with limits of ''[-90, 90]''. When played as-is, this ''GameObject'' will be free to rotate between ''(-90, 0, 0)'' and ''(90, 0, 0)''. However, if you rotate this ''GameObject'' in the editor such that it starts with rotation ''(90, 0, 0)'' and play it, the ''GameObject'' will then be free to rotate between ''(0, 0, 0)'' and ''(180, 0, 0)'' - even though the angle limits have not changed. |
| | |
| | === Things That May Solve Problems With HingeJoint: === |
| | |
| | In the vast majority of use cases, your ''HingeJoint'' should have a ''ConnectedBody'' assigned. This field is optional, but if left empty it causes your ''HingeJoint'' to be anchored to the global physics coordinate system. If your ''HingeJoint'' happens to be a child of some other object that moves, the joint will continue applying its limits within the global physics coordinate system - not in the joint's local coordinate system. This is usually not what you want. |
| | |
| | A good way to ensure that your ''HingeJoint'' behaves nicely is to create a ''RigidBody'' on the parent object (if one doesn't already exist) and set that as the ''ConnectedBody''. The parent body can have ''IsKinematic'' enabled if you don't want it to act like a physics object. In this configuration, the ''axis'' and ''angle'' of the ''HingeJoint'' will actually correspond to the ''localRotation'' of the ''Transform'' (though it will still be relative to any initial ''localRotation''). This makes the joint behavior much easier to reason about! |
| |
