Graphics › Drawing it
Rotations: Euler & quaternions
Three ways to say 'turn it': rotation matrices, Euler angles, and quaternions. Each is fine for something — and quaternions are what engines actually store.
model matrix M = T · Ry · Rx · S
| 0.49 | 0.00 | 0.34 | 1.50 |
| 0.00 | 0.60 | 0.00 | 0.40 |
| -0.34 | 0.00 | 0.49 | 0.00 |
| 0.00 | 0.00 | 0.00 | 1.00 |
The dashed cube is the original; the solid one is M applied to it. Order matters — scale then rotate then translate is the usual recipe (read the matrices right-to-left).
Rotation matrices
A 3×3 (or 4×4) matrix whose columns are where the x, y, z axes go. Composes by multiplication, plugs straight into the MVP chain, and a GPU eats it for breakfast. Downsides: 9 numbers for 3 degrees of freedom, and interpolating between two of them naïvely doesn't give a nice in-between rotation (the result isn't even a rotation).
Euler angles
Three numbers — yaw, pitch, roll — applied in some agreed order. Human readable, great for hand-tuning in an editor. Two problems: order matters (XYZ ≠ ZYX), and gimbal lock — when one axis rotates onto another, you silently lose a degree of freedom and certain orientations become unreachable smoothly. Fine for a turret; treacherous for a free-flying camera.
Gimbal lock, in one sentence
Quaternions: what engines use
A quaternion q = (x, y, z, w) encodes “rotate by angle θ about unit axis a” as (a·sin(θ/2), cos(θ/2)) — four numbers, no gimbal lock, composes by quaternion multiplication, and interpolates beautifully: slerp gives a constant-speed shortest-path rotation between any two orientations (exactly what you want for animation blending and smooth camera moves). Engines store rotations as quaternions and convert to a matrix only when it's time to feed the GPU.
So which one, when?
- Matrix — for actually transforming vertices (the GPU's currency).
- Euler — for artist-facing controls and simple constrained rotations.
- Quaternion — for storing, composing, and interpolating orientations.