Timeline for Does gimbal lock occur only when a combination of local and world rotation axis are used?
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 26, 2020 at 6:51 | comment | added | Jon | In practice, if you have your own physics engine to play with, you can illustrate this quite well. In the angular velocity integration step, if one does not convert to quaternions before integrating (and then convert back, if the storage requires it), one will find that objects will experience gimbal lock quickly after a few full axis rotations. | |
| Nov 25, 2020 at 17:29 | history | edited | DMGregory♦ | CC BY-SA 4.0 | Automatic, not inescapable |
| Nov 25, 2020 at 17:25 | comment | added | DMGregory♦ | I gave several examples above where we don't use a gimbal model. A gimbal model is entirely avoidable in 3D programming. You can use Euler angles or not, and still avoid gimbals, if you're thoughtful about how you compose your rotations together. | |
| Nov 25, 2020 at 17:21 | comment | added | PentaKon | Ok, so if I understand it properly, it is possible to not use a gimbal model but that's not really the case in 3D programming right? We use Euler angles with intrinsic rotations | |
| Nov 25, 2020 at 17:14 | comment | added | DMGregory♦ | Right, because that example was NOT tracking a total angle around x and a total angle around y, incrementing them individually, and then composing the totals to make a result. It's not using a gimbal model, so it does not experience gimbal lock. Each of those motions the coffee cup goes through are applied as local increments as I show in the latter part of the answer above, to an orientation that is stored as a quaternion, not as three angle totals I'm incrementing independently. | |
| Nov 25, 2020 at 17:07 | comment | added | PentaKon | But in the coffwe cup example you give in your other answer (the one with the animations) there are no gimbal issues when rotating it 90 degrees around x and y. The whole basis gets rotated after each individual rotation | |
| Nov 25, 2020 at 16:35 | comment | added | DMGregory♦ | If what you store from frame to frame is "I have this much yaw and this much pitch and this much roll" and you update those by saying "I'll increase my pitch in isolation" - then you have gimbals. You're pretending these are three independent variables when really they influence each other. It is not unique to any particular engine. If you apply a rotation to a local frame all at once, not by layering multiple rotations about their own axes (gimbals) in sequence, then you can avoid the problem. | |
| Nov 25, 2020 at 16:31 | comment | added | PentaKon | so you're saying that whenever we construct a rotation from a sequence of pitch, yaw, roll we always end up with a gimbal type of system? Or is it that Unity for example and all these engines have gimbal like implementations. My understanding was that if a rotation is always applied in the local frame, then the frame itself rotates which means the axes always remain orhogonal thus no gimbal alignments | |
| Nov 25, 2020 at 14:54 | history | answered | DMGregory♦ | CC BY-SA 4.0 |