🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Is this the Gimbal lock?

Started by
5 comments, last by eu5 2 years, 10 months ago

Hi.

I have a unit vector which is (0, 0, 1). This vector points to forward direction.
So this vector is same with z axis in the below coordinate.

Lusain's Blog ─ Programing & Novel Review +

I rotated the vector 90 degree on the x-axis(Pitch). So now direction of the vector is same with -y axis.

And I also wanted to rotate the vector Θ degree(0<Θ<90) on the y-axis(Yaw). So like this.

outVec = Rotate(UnitVector::FORWARD, pitch(90))
outVec = Rotate(outVec, yaw(Θ))

But, the vector can't rotate properly. Because the vector is same with y-axis.

So this is the Gimbal lock?

And I tried to change the order of rotation like the below. And It's works.

outVec = Rotate(UnitVector::FORWARD, yaw(Θ))
outVec = Rotate(outVec, pitch(90))


But I wanted just one multiplying. So I used a quaternion. because I heard if you use quaternion, it doesn't matter the order of rotation.

XMMATRIX quat = XMQuaternionRotationRollPitchYaw(90.f, theta, 0.f)
vec = XMVector3Rotate(UnitVector::FORWARD, quat)


But the result is same with first. It didn't work. Can I know why?
Am I used wrong?

Advertisement

The problem coming from Gimbal Lock usually has it's origin in using Euler Angles. Seems you have your issue here, as all your approaches, even the final using quaternions, define rotations from Euler Angles.

Euler Angles build rotations as a sequence of 3 rotations around x,y,z directions. That's mostly hard to imagine properly, and depends on conventions which are often not clear. For example, i don't know the order of rotations from the function name ‘XMQuaternionRotationRollPitchYaw’. Is it Roll first and Yaw last? Or the other way around? Not sure, and hard to imagine anyway. I'm even unsure if rotations are done on global or local axis.
For those reasons, Euler rotations are often avoided. Too much uncertainty, too much trial and error. And doing 3 rotations to get just a single one may be slow as well.

The better way to deal with 3D rotations is using an axis and angle instead. There should be a function taking a unit vector and an angle as input and returning quaternion / matrix.
Now you only think of where the axis of rotation should be and how to calculate it. That's often easier. E.g. if you want a rotation from vector A to vector B, you get the axis from normalize(cross(A,B)), and the angle from acos(dot(A,B)).

Euler angles are useful for things like first person camera and other user interfaces.

@JoeJ

Thank you for your answer!

First, I'm sorry! XMQuaternionRotationRollPitchYaw is the function of Direct3D. So I thought you guys know about this.
And this function makes a “Quaternion” from the Euler Angle.

So I thought if I use this function, I will get “Quaternion without Gimbal lock”
And I thought just a quaternion is everything.

I should figure out your way. Thank you.

eu5 said:
First, I'm sorry! XMQuaternionRotationRollPitchYaw is the function of Direct3D. So I thought you guys know about this.

No reason to be sorry, what i meant was ‘Even having good experience on 3D rotations, doing it myself or by using such libraries, the uncertainty is unavoidable.’

eu5 said:
So I thought if I use this function, I will get “Quaternion without Gimbal lock”

It's a common misconception quaternions would avoid or fix Gimbal Lock problems. In fact there is not really a problem at all, it's always our failure to understand a sequence of multiple rotations, and how they may cancel out or map to each other. So it's more a problem of mind than a problem of math. Often a solution can be found with some trial and error, and we still don't understand neither the problem nor the solution, but it works : )

What do you try to do? (Axis and angle is not always the best choice to model rotations, just mostly.)

Gimbal Lock is a problem in the brain, not in the math. It's very common :-)

Every possible composite orientation is representable in Euler angles. Every possible composite orientation is also representable using quaternions. Every possible composite orientation is also representable using axis-angle. All three representations are equivalent.

When Gimbal Lock gets you into trouble is when you try to decompose a single orientation into separate components, and then construct it using “forward reasoning.” Because the original coordinate system changes in each step, you can't assume that some reference point that existed in the original coordinate system, is the same, or is even non-degenerate, in the new coordinate system.

One work-around for this is “Tate-Bryant” Euler Angles, where the rotations are expressed in terms of the new coordinate system. E g, “rotate down” then “rotate around up” would rotate around the new up which in your case is the same as the old forward. This is closer to “airplane” controls – when you're going straight down, and then crank on the rudder, the “forward” still turns rightwards from the new point of view.

Another alternative is to sequence the rotations in a way that they mostly make sense to your brain. For heading/pitch/roll, you will want to apply roll first, then pitch, then heading. Important here is to make sure that the pitch represents the final amount of pitch you want – if you want to go slightly out the right, you can't pitch down 90 degrees; you pitch down however much is the total pitch of the final orientation you want.

Another little-known geometry secret: There's no thing as a “right handed” or “left handed” rotation. A 90 degree positive rotation of the X vector around the Z vector always ends up yielding the Y vector. “left handed” and “right handed” only show up once you start to physically interpret your math. You need to use the same convention when going from physics to math, as you use when going back out from math to physics, but the math itself does not change based on handedness, only interpretation does.

Welcome to 3D graphics :-)

enum Bool { True, False, FileNotFound };

@JoeJ
Ok I got it. I just didn't know about the axis-agular way.
So I meant I need to find out that way. Thank you!

@hplus0603
Thank you for your answer!


When Gimbal Lock gets you into trouble is when you try to decompose a single orientation into separate components, and then construct it using “forward reasoning.” Because the original coordinate system changes in each step, you can't assume that some reference point that existed in the original coordinate system, is the same, or is even non-degenerate, in the new coordinate system.

This is exactly what I did haha.. I need to think more deeply when I use rotating.
And thank you for inviting me 3D graphics!

This topic is closed to new replies.

Advertisement