Ok, imagine a camera that you''re looking through, and imagine what you would call the x, y and z axis in the world. The x axis points to your right, the y axis up and the z axis straight ahead.

So you look through your camera, and you want to rotate it to the right. You then rotate by the y axis (imagine spinning a top, you twist it along the y axis) until you''re pointing 90 degrees to the right.

Ok, so that''s rotating to the right.

Now, say you''re back at the start, facing forward, and you want to pan up. For this, you rotate along the x axis (again, imagine rotating along this line). Now you''re pointing upwards!

Ok, now say that you want to rotate right, then pan up. You turn until you''re 90 degrees to the right. Now you pan up, rotating along the x axis. You''re now pointing upwards, right?

Nope! When you made that first 90 degree turn, you turned so that you''re looking down the x-axis (again, imagine how that would look... you spin until you''re facing to the right, and the x-axis points to the right). When you try to rotate on the x-axis, it''s actually rotating along the z-axis!

It''s hard to explain, but you have to think about it like you''re looking through a camera, and remember that the x, y and z axis stay put during all your movement.

Here's a good article you might want to read, it's about quaternions but if you skip to the bottom the author provides two demos - one using matricies and one using quaternions to demonstrate the problem of gimbal lock.

He also gives a much better explanation than I could about what gimble lock actually is.

Clicky

EDIT: forgot link

[edited by - Spudder on March 25, 2004 5:01:40 PM]

I''ve been doing 3D stuff for a long time now and I''ve never needed to use quaternions for anything other than saving memory (used in a bone animation system), which means I''ve never had a Gimbal Lock situation. The trick is, never to use world axes for doing object rotation, always rotate about the object''s axes. So in sirSolarius'' example, rotate the camera right by rotating about the camera''s up axis. Then rotate up by rotating about the camera''s right axis (which is now pointing in the world''s back, or negative z direction). The camera is now pointing exactly where you''d expect.

Some might say the quaternions involve fewer computations as it''s a 4x1 vector as opposed to a 4x4 matrix. You do have to factor in the conversion to and possibly from a matrix, which is no trivial task and ends up requiring about the same amount of computation overall.

As I said above, I''ve only used quaternions when I needed to save memory: 7 floats for the quaternion method (4 for the quat and 3 for position), or 16 for a matrix. Also, the animation system didn''t require conversion from a matrix to a quaternion, only the other way round.

I like the matrix form, especially when you consider that a matrix can be thought of as four vectors: right, up, at and position.

Skizz

Gimbal Lock is only applicable to systems where the direction is stored as roll, yaw and pitch angles (or Euler angles). If you use matrices to store the direction (you need a matrix for each object anyway for rendering) then you will always be able to incrementally change the direction an object faces, in the way you''d expect. In JohnBolton''s example, step 1 is a rotation about the ''right'' direction of the matrix, step 2 would be a rotation about the ''at'' direction of the matrix. To pitch down again, a rotation about the matrix''s ''right'' axis would sort it out.

So, don''t use Euler angles.

Skizz