1
\$\begingroup\$

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?

\$\endgroup\$
1
  • 2
    \$\begingroup\$ They are easier to understand for the player. Quake 3 with Quaternions feels really weird, because you can bend over backward. \$\endgroup\$ – Almo Jul 15 '18 at 2:43
5
\$\begingroup\$

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:

Animated example of compounding rotations leading the view to twist & roll sideways

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)

Demonstration showing that stacking local rotations x+90, y+90, x-90 is equivalent to z+90

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:

Demonstration of x+90 globalY+90 x-90 eliminating roll seen earlierExample of FPS controls in this scheme

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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.