Hi I’ve been having a lot of grief with my code and having read through the forums now realise I’ve come across this “Gimbal Lock” problem. Originally I was using Euler angles to represent my orientation. Having read an article by Diana Gruber, I decided to rewrite my code to use the Rotation Matrix she discusses – but it turns out that the Gimbal Lock problem is still there! So, I’m about to rewrite it again, this time using a Quaternion as my orientation. I’m not 100% sure how this works though, my understanding is this: 1. I keep my Euler angles and these are updated as a result of key presses etc. 2. At time of rendering, I construct a Quaternion from the Euler Angles. 3. I then get the rotation matrix from the Quaternion. 4. I Apply the rotation matrix Is this correct or am I missing something? It seems a long-winded way to me, and I can’t understand how this fixes Gimbal Lock when I ultimately end up with a rotation matrix anyway? Any help much appreciated. Thanks for reading. Boony.

I suggest you stick with matrices. IMHO they are much more intuitive than quaternions.

1. Keep your rotation state as a matrix. Initialize it to an identity matrix.
2. On keypress, construct a temporary rotational matrix that represents the rotation that is to be added.
Multiply your main rotational matrix with this temporary matrix.
3. When rendering, apply the rotational matrix.

Or, if you want to try quaternions:
1. Keep your rotation state as a quaternion. Initialize it to an identity quaternion.
2. On keypress, construct a temporary quaternion that represents the rotation that is to be added.
Multiply your main rotational quaternion with this temporary quaternion.
3. When rendering, convert the quaternion to a matrix. Apply this matrix.

AFAIK, there are two reasons to use quaternions over matrices:
They are easier to normalize and easier to interpolate.

Thanks for replying.

The first method you suggest (Matrices) is pretty much what I have right now, but if my rotation matrix represents the result of rotating about the Y-Axis by 90 degrees, and then I try to rotate around the X-Axis, it actually rotates around the Z-Axis – ala Gimbal Lock.

Are you saying that this should NOT suffer the problem?

You are correct that if you only add the little bit that you are rotating, you won''t have the gimbal lock.

I implemented quats a little while ago, and they''re working fine for me. The biggest thing to remember is that if you convert your entire euler angle into a quat or matrix every time, you are still going to run into the gimbal lock (at least, from what I understand of it).

What I do so I can keep the degree of rotation is have one euler angle set representing the current rotation, and another set representing the last rotation. That way, I can find my difference by comparing the two sets instaed of converting the actual angles over.

b00ny: unless you recalculate the rot matrix from euler angles every frame, you shouldn''t run in to a gimbal lock with this method (like Dragonskin said). Also check the order in which the rot matrix is multiplied with the temporary matrix. Somebody please correct me if I''m wrong, but I think that pre-multiplying with the temp matrix will result in a rotation around local coordinates and post-multiplying will rotate around world coordinates. The same goes for quat multiplication.

Thanks to all for replying.

I''ve been playing around with the code some more, and have now come to the conclusion that I''m not suffering Gimbal Lock afterall.

I expected that my rotations would be local, that is in object space. As it happens, it was rotating around the world axis.

The last posting by anon prompted me to change the ordering of my multiplication and voila - it seems to work! I can''t verify 100%, but it does indeed seem that if you pre-multiply with the temp matrix you get rotation around the local axis, and post-multiplying gives you rotations around the world axis.

Once again, thank-you all.