Why use gimbals?

Question

With all the gimbal lock problems, quaternions, and stuff like that - why do we even use gimbals for rotation? Why not use local rotation instead of gimbals?

Answer 1

If I understand you correctly, by local rotation you mean something like this:

void RotateCamera(float horizontalInput, float verticalInput) {
    // Apply an incremental rotation about our current vertical axis (local yaw)
    camera.Rotate(horizontalInput * horizontalSpeed, camera.up);

    // and an incremental rotation about our current horizontal axis (local pitch)
    camera.Rotate(verticalInput * verticalLookSpeed, camera.left);
}

The trouble with doing this on its own for something like a first-person camera is that these rotations compound in somewhat non-intuitive ways. Consider the ring your forward vector traces across the visual sphere as you turn left to right:

• Starting from zero pitch, looking straight outward, spinning with local yaw will keep your forward vector trained on the horizon, tracing out the equator of your visual sphere.

• Starting from a viewpoint that's looking 45 degrees upward, spinning with local yaw traces a ring that's slanted 45 degrees to the horizontal plane. (Since your local up vector pivot is tilted)

  So by the time you've turned 180 degrees to look behind you, you're now looking 45 degrees down instead of 45 degrees up. A horizontal input became a vertical output. If you want to turn around while continuing to look up at the same angle, you need to provide more complicated input to compensate.

When we compound a lot of little local rotations like this frame over frame, the player's reference to global up/down/left/right can become confused:

This is because combining local pitch (x) and yaw (y) rotations can turn into roll (z) rotations - something we're not used to controlling manually in most first person controls (but might be perfectly at home in flight sims or space exploration games)

One common way to fix this is to perform the yaw rotation about the global vertical axis, instead of whichever direction the object's vertical axis is currently pointing. This has the effect of acting like a set of gimbals: An outer gimbal pivoting vertically to control yaw, and an inner gimbal pivoting horizontally off the outer to control pitch.

This keeps the horizontal and vertical input roles more strictly separated, and eliminates unwanted roll:

But this isn't the only solution we can use. Another method, common in flight simulators or spaceship games, is to allow local rotation input to twist and roll the view as shown above, and then apply a compensating rotation to "untwist" it, like an autopilot restoring you to level, so the player doesn't have to manually control a third axis of rotation.

So, the choice of which rotation scheme to use boils down to what kinds of inputs you want to accept, and what kinds of outputs you want them to map to. For some applications, a gimbal-style scheme helps us get an intuitive mapping. For others, it's less appropriate.