| 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/04/30 16:52]
151.202.25.206 |
| ====== HingeJoint ====== | ====== HingeJoint ====== |
| | |
| | === Things That Are Not True About 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**. | 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**. |
| |
| 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''**. | Another common misconception ((Again, by me, this author)) 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''**. |
| |
| 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! |
| |
