I'm just starting out and am doing a quick refresher on linear algebra / trigonometry to set the stage for delving into 3D programming. Math has never been my strong-point, and while I have an intuitive understanding of the literal analogy of a gimbal and its 3 rings and why that would physically happen, I'm afraid I don't understand the mathematical connection here as to WHY this happens.

I feel like I'm missing something obvious in the following explanation (quoted from "3D Math Primer for Graphics and Game Development 2nd Ed." by Fletcher Dunn):

"if we head right 45 deg and then pitch down 90 deg, this is the same as pitching down 90 deg and then banking 45 deg. In fact, once we chose ±90 deg as the pitch angle, we are restricted to rotating about the vertical axis. This phenomenon, in which an angle of ±90 deg for the second rotation can cause the first and third rotations to rotate about the same axis, is known as Gimbal lock. To remove this aliasing from the canonical set of Euler angle triples, we assign all rotation about the vertical axis to heading in the Gimbal lock case. In other words, in the canonical set, if pitch is ±90 deg, then bank is zero."

He lost me early here - "once we chose ±90 deg as the pitch angle, we are restricted to rotating about the vertical axis" - first of all what is the vertical axis referring to here, in this case, the world space canonical Y-axis, the model space Y-axis or does vertical axis refer to the x-axis and the "verticality" of the pitch rotation? Why the pitch axis and not the other axis? Why does ±90 deg restrict the rotation? With a gimbal there is a physical reason because of the rings, but mathematically why does this happen?

I can't seem to find a solid mathematical example with numbers, like a worked example, that explains how and why this happens / how to identify it mathematically etc.

In that example, the writer describes gimbal lock in the context of representing rotations using euler angles. With euler angles, one specifies rotations as a sequence of three successive rotations around predetermined axes. These convention of which axes to use and in which order are chosen arbitrarily, or depending on the application, e.g. one might represent orientation as rotation about X, then Y and then the Z axis.

Since you have three scalars there you can specify rotations with, you have 3 degrees of freedom. If you fix any one of these to a constant value (say y = 25deg), you'd expect to be left with the ability to rotate still in 2 degrees of freedom, because you can still freely manipulate two rotation angles (and so on, if you fix two of these angles to a constant value, you'd expect to be left with the ability to rotate in 1 DOF). But due to the gimbal lock effect, this is not always the case. It is possible to fix only one of the angles to a specific constant value, that constrains the system to only 1 degree of freedom left, instead of the 2 dof that you'd expect.

The problem here is that whichever order we pick for the Euler angles, there exists an angle value for the middle rotation, that causes the first and the third axis to line up (the angle is +/-90degrees, depending on the choice of rotation order), so that varying the angle values for the first and the third rotation axis will both produce an end result rotation about the same axis. If we fix the second rotation axis constant to this value that causes the first and the third axes to line up, we not only freeze rotation about one dimension, but about two dimensions, since we are left with the ability to only rotate the whole object around one axis. Effectively, our expected to-be-2dof system is now only a 1dof system. Altering the angle value for the middle rotation axis immediately breaks off the gimbal lock, giving back the 3dof rotations.

Mathematically we can see this as follows. Let's represent rotation using Euler angles, R = Rx(a) * Ry(b) * Rz©, where Ri(v) is a rotation matrix about axis i by angle v, and use the Matrix*vector convention. Fix b to -90 degrees (I think, or, b=90 if I messed up the sign). Then it can be seen that Ry(-90deg) * Rz© == Rx©. Therefore when b=-90, the rotation equation for the remaining two axes is R=Rx(a) * Rx© = Rx(a+c).

What this equation means is that we have two free scalars a and c left to specify the orientation, but they are both producing rotation about the x axis, i.e. the altering a and c is interchangeable and has the same end effect of rotation about the x axis. Effectively we fixed only one rotation axis to a special value, but managed to kill two degrees of freedom with that move.

It should be remembered that there's nothing intrinsically wrong with using Euler angles, just that having that middle value be +/-90 can be problematic. If you don't need those kind of angles, e.g. in a FPS shooter you can't tilt your head above 90 deg to look backwards, so you can pick such an Euler convention (XYZ/XZY/ZYX/etc. depending on your cooridinate system) for the camera that has the constrained rotation axis in the middle, and you are not going to have any problems.

The other solution (in game development field) to this is to not do your rotation logic as sequences of rotations about fixed axes. Using quaternions implicitly avoids this, not because of some mathematical special property they have, but because with quaternions you don't logically use sequences of fixed axes. Or if you do, and just have QuatYaw, QuatPitch and QuatRoll, you're no better off than when you were using euler angles and are still susceptible to gimbal lock.

Thank you clb for your excellent response - your explanation on the loss of freedom of an axis was the missing part I was failing to understand - indeed, after working through some examples and creating an interactive rotation demo in XNA I see exactly what the problem is

Thanks for taking the time to explain it in such great detail - I was having trouble with several references making the jump from the premise to the conclusion with me being left behind