Quaternions: How Rockets and Games Rotate Without Falling Apart

On 16 October 1843, William Rowan Hamilton was walking along the Royal Canal in Dublin with his wife when the answer to a problem that had stumped him for over a decade hit him all at once. He was hunting for a way to multiply triples of numbers the way you multiply pairs — an algebra for three-dimensional space, symmetric with the one that already worked so cleanly for the plane using pairs of numbers (what we'd now call complex numbers). Triples wouldn't cooperate, no matter how he arranged them. What suddenly clicked, standing on Broome Bridge, was that the answer needed four numbers, not three, and a rule that broke one of algebra's oldest assumptions: multiplication that doesn't commute. In the kind of flash mathematicians tell stories about for centuries, he carved the defining relation straight into the stone before he could lose it: i² = j² = k² = ijk = −1.

The vandalism — a small plaque marks the spot today, the carving itself long worn away — named a new kind of number: the quaternion. For a century it was mostly a curiosity, elegant but sidelined once ordinary vector algebra proved easier to teach. Then computers arrived, and it turned out Hamilton had accidentally solved a problem nobody in 1843 knew was coming: how do you describe a 3D orientation — a spacecraft's attitude, a game character's turn, a robot arm's wrist — compactly, continuously, and without the machinery quietly breaking under your hands? A hundred and eighty years later, that bridge graffiti runs inside every smartphone, every 3D game engine, and the guidance computer of any rocket that has ever left the atmosphere with a human on board. This is why: what's wrong with just using angles, and what four numbers buy you that three angles never could.

The obvious way to describe an orientation is with three angles — yaw, pitch, and roll, the same words a pilot uses. Rotate this much around one axis, then that much around the next, then a third amount around the last, and you've described any orientation you like. It's the most human-readable representation there is: intuitive to picture, easy to type into a form field, and the one everyone reaches for first.

It's also broken in two specific, well-understood ways. The first is that composition order matters — rotating yaw, then pitch, then roll lands you somewhere different than rolling first and yawing last, so "the" Euler angles for an orientation aren't well-defined without also fixing which axis goes first, second, third. Written as a yaw-pitch-roll product of rotation matrices, a full orientation looks like this:

The second failure is the one that actually breaks things at runtime: gimbal lock. Push the pitch angle $\theta$ to 90° and the yaw and roll rotations — normally turning around two different axes — collapse onto the *same* effective axis. One of your three independent degrees of freedom disappears, not from a bug, but from the geometry itself: you can no longer reach every nearby orientation by adjusting yaw and roll independently, only their combined sum. Try to sweep smoothly through that region and the motion visibly snaps or spins in a way no camera operator asked for.

The classic mental picture is a camera rig with three physical gimbal rings — outer, middle, inner — each free to spin about its own axis, each ring's axis carried along by whichever ring sits outside it. That's the exact hardware Euler angles are describing, and it's where the name "gimbal lock" comes from: point the camera straight up, and the outer and inner rings, which were pointing in two independent directions a moment ago, are now both spinning around the same vertical line. You haven't lost precision. You've lost an entire axis of motion, and no amount of careful floating-point arithmetic buys it back — the fix has to be structural, not numerical.

Quaternions fix both failures by refusing to factor a rotation into pieces at all. A unit quaternion — length exactly 1 — packs an entire orientation into four numbers, a scalar and a 3D vector, built directly from one axis and one angle:

where $\hat u$ is the unit vector you're rotating around and $\theta$ is how far. One axis, one angle, no sequencing, nothing to get in the wrong order — Fig. 1's cube is that idea rendered directly: the orange line is $\hat u$, baked straight into the quaternion's vector part, and the entire cube turns as one rigid motion around it, never three.

To actually rotate a vector $v$ with a quaternion, you don't just multiply — you sandwich it between $q$ and its inverse:

Why the sandwich, and not the simpler $qv$? Because $q$ was built from the *half* angle $\theta/2$, not the full one — a structural fact of the algebra, not a stylistic choice. Multiplying $v$ by $q$ once only carries it halfway there; conjugating with $q^{-1}$ on the other side applies that half-angle turn a second time, and the two halves add up to the full rotation by $\theta$. The sandwich also guarantees $v'$ comes out as a pure vector, with no leftover scalar part — $qv$ alone doesn't promise that.

Composing two rotations is now just quaternion multiplication: apply $q_1$, then $q_2$, and the combined rotation is $q_2 q_1$ — one multiply, full stop. Compare that to Euler angles, where composing two orientations means building two full rotation matrices and multiplying 3×3 grids together, tracking which axes moved relative to which parent. A game engine chaining a camera's rotation onto a character's rotation onto a bone's rotation does it with three quaternion multiplies, not three matrix constructions.

There's a small piece of bookkeeping worth knowing about. Floating-point rotations, chained across thousands of frames, slowly drift away from length 1 through accumulated rounding error, and a quaternion that isn't unit length stops representing a pure rotation — it starts scaling space, not just turning it. The fix is cheap: renormalize, dividing by the quaternion's own length, every so often. That costs one square root and three divisions, against the alternative of a visibly warped, shearing model that only gets worse the longer the simulation runs.

Four numbers is also just less to carry than the alternatives. A rotation matrix stores nine, six of them redundant once you account for the orthogonality constraints a valid rotation has to satisfy — three numbers' worth of real information hiding inside nine stored floats, with rounding error free to nudge the matrix away from a legal rotation entirely (shearing, not just turning, exactly like an unnormalized quaternion). Three Euler angles store the theoretical minimum, but at the cost of the two failures above. A unit quaternion sits at the practical sweet spot: one redundant number beyond the true three degrees of freedom, in exchange for cheap composition, cheap interpolation, and no gimbal lock anywhere in its domain.

Rotating a fixed orientation is only half the problem — games and animation systems also need to *interpolate* between two orientations, sliding smoothly from a starting pose to an ending one over some fraction of a second. This is exactly where Euler angles fail hardest: linearly blending three separate angles ignores gimbal lock entirely and can drag a character's head through a path that has nothing to do with the shortest turn between the two poses, because "halfway between the angles" is not the same thing as "halfway between the orientations."

The naive quaternion fix — linearly interpolating all four components, then renormalizing back to unit length (nlerp) — is closer, but still lies: it moves along the straight chord connecting the two quaternions, not along the sphere's own surface, so a uniform step in $t$ produces a non-uniform step in angle, fast in the middle and slow at the ends. Spherical linear interpolation (slerp) fixes this by moving along the great-circle arc itself, weighting the two endpoints by the angle between them instead of by straight-line distance:

where $\Omega$ is the angle between $q_1$ and $q_2$, recovered from their dot product. Step $t$ from 0 to 1 at a constant rate and the orientation sweeps at a genuinely constant angular velocity the entire way through — no easing in, no easing out, exactly the smooth, mechanical turn a camera pan or a robot joint actually wants.

None of this stays theoretical. Every major game engine — Unity, Unreal, Godot — represents an object's orientation with a `Quaternion` type under the hood, even when the editor's inspector shows you friendly Euler angles for convenience; rotations compose and interpolate as quaternions internally precisely because artists and camera systems need exactly the guarantees above. Spacecraft attitude-determination systems report orientation as quaternions directly — star trackers and inertial units on modern satellites and launch vehicles output them natively, the lineal descendants of the gimbal-based platforms Apollo flew. Robot arms describe an end-effector's orientation with them to dodge the singularities that would otherwise appear mid-reach. A phone's sensor-fusion stack blends accelerometer, gyroscope, and magnetometer readings into an orientation estimate exposed through APIs like Android's rotation vector — a quaternion under a friendlier name — which is what keeps a maps app's compass arrow smooth instead of jittery. And any 3D animation package blending between two keyframed poses is running slerp, or a higher-order relative of it for whole skeletons, underneath the timeline scrubber. Hamilton's four numbers turned out to be the right shape for describing "which way is this thing facing" everywhere the question comes up.