Last updated: 2026-09-18
Computer Graphics and Transforms
Turning a 3D scene into a 2D image on screen is, mechanically, a sequence of coordinate-space changes applied to every vertex in the scene — the transform pipeline1. Each stage answers a different question about where a point is, and each is expressed as a matrix, which is what makes the whole pipeline composable into a single matrix multiplication per vertex.
The Transform Pipeline
(local to the object)"] -->|model matrix| B["World space
(shared scene coordinates)"] B -->|view matrix| C["View space
(relative to the camera)"] C -->|projection matrix| D["Clip / screen space
(what the viewer sees)"]
| Stage | Question it answers |
|---|---|
| Model | Where are this object's vertices, relative to its own centre? |
| World | Where is this object, relative to everything else in the scene? |
| View | Where is everything, relative to the camera? |
| Projection | How does 3D space flatten onto a 2D screen? |
Matrices and Homogeneous Coordinates
Rotation and scaling are naturally linear operations — a 3×3 matrix multiplying a 3D vector can express either directly. Translation (sliding a point without rotating or resizing it) is not linear in the same sense: there's no 3×3 matrix that adds a fixed offset to every input vector, because linear maps always send the origin to the origin, and a translation moves the origin too. The standard fix is homogeneous coordinates: represent a 3D point (x, y, z) as a 4D vector (x, y, z, 1), which makes room for a translation to be smuggled into the fourth column of a 4×4 matrix:
Translation by (tx, ty, tz):
| 1 0 0 tx | | x | | x + tx |
| 0 1 0 ty | × | y | = | y + ty |
| 0 0 1 tz | | z | | z + tz |
| 0 0 0 1 | | 1 | | 1 |
With every transform expressed as a 4×4 matrix in this shared representation, translation, rotation, and scaling can all be combined into one matrix by multiplying them together, and applying that single combined matrix to a vertex does the equivalent of applying each transform in sequence — which is the entire reason the model/world/view/projection pipeline above can be collapsed, at render time, into one matrix multiply per vertex rather than four.
Rotation Representations
Rotation specifically has more than one workable representation, and the choice matters in practice. Euler angles (separate rotations around X, then Y, then Z) are intuitive to specify by hand but suffer from gimbal lock — a configuration where two of the three rotation axes align, collapsing a degree of freedom and producing visibly wrong interpolation between orientations. A unit quaternion — four numbers, (w, x, y, z), subject to w² + x² + y² + z² = 1 — represents a rotation without that failure mode: there is no configuration of a quaternion where a degree of freedom collapses, and interpolating smoothly between two orientations (spherical linear interpolation, or slerp) is a single well-behaved formula rather than a set of special cases for when axes happen to align1. That reliability is why quaternions, not Euler angles, are the standard internal representation for camera and character orientation in real-time graphics, even though Euler angles remain the friendlier way for a human to type a rotation in by hand.
The Same Problem, Differently Framed
Quaternions solve gimbal lock, but they do it by a kind of trick: a 3D rotation is represented using a 4D mathematical object whose connection to ordinary 3D space isn't obviously motivated from first principles — it works, but the "why" takes some getting used to. Vectors, Quaternions, and Blades covers a different way of arriving at essentially the same destination: geometric algebra builds rotations out of rotors, generated directly from the geometric product of vectors already in the space being rotated, with quaternions falling out as a special case of that more general machinery in 3D specifically. Nothing about the matrix pipeline above stops being correct — a rotor and a quaternion produce the same rotation matrix in the end — but the geometric-algebra route motivates why a 4-parameter object is the natural way to represent a 3D rotation, rather than presenting quaternions as an algebraic trick that happens to work.
Once every object in a scene has been carried through this pipeline into a shared coordinate space, a renderer's next question is usually cheaper than it sounds: does a given ray or object actually need testing against a specific piece of geometry at all, or can that be ruled out first with a much cheaper bounding-box check? Interval Arithmetic covers that technique, and the tree structure that makes it scale to an entire scene, in full.