Coordinate Systems & Transformations
Geometry & Trigonometry
Chapter 8 · Coordinate Systems & Transformations
Chapters 5-7 handled rotation in real depth, but a rotation matrix alone can't move something — Chapter 5 had to bolt translation on separately with a three-step "translate, rotate, translate back" pattern just to rotate around a non-origin pivot. This chapter reuses homogeneous coordinates, briefly introduced back in Linear Algebra Fundamentals Chapter 5, to fold rotation and translation into one matrix — and builds the full local/world/camera pipeline every real graphics or game engine runs every single frame.
Homogeneous Coordinates: One Matrix for Rotation + Translation
Adding a third coordinate, always 1, to every 2D point turns translation into ordinary matrix multiplication: T = [[cos θ, −sin θ, tₓ], [sin θ, cos θ, t_y], [0, 0, 1]] applied to (x, y, 1) rotates and translates in a single matrix-vector product.
Local, World, Camera, and Screen Space
| Space | What coordinates mean here |
|---|---|
| Local (object) space | Coordinates relative to the object's own center/origin — where its own vertices are authored, independent of where it's placed in the scene |
| World space | The scene's shared, global coordinate system — every object's local space is transformed into this one common space |
| Camera (view) space | World space re-expressed relative to the camera's own position and orientation — as if the camera sat at the origin looking down a fixed axis |
| Screen (clip) space | The final 2D pixel coordinates after projection — beyond this course's own scope, but built directly on everything above |
Change of Basis: Getting From World Space Into Camera Space
The camera itself has a world position and orientation, exactly like any other object — described by its own T_camera_to_world matrix. Going the other direction, from world space into the camera's own frame of reference, needs the inverse of that matrix.
R satisfies R⁻¹ = Rᵀ (its own transpose — a direct consequence of its rows/columns being perpendicular unit vectors, per Chapter 4's own dot-product orthogonality checks), the inverse of a rotate-then-translate matrix doesn't need a full, general matrix inversion at all: T⁻¹ = [[Rᵀ, −Rᵀt], [0, 1]] — transpose the rotation part, and use it to un-translate.
A Full Verified Pipeline: Local → World → Camera
A "forward" marker point at local (1, 0) belongs to an object placed at world position (5, 2), rotated 30°. A camera sits at world position (10, 10), rotated −45°.
(1,0,1) gives (5.866025403784438, 2.5, 1) — matching the hand-check (cos30°, sin30°) + (5,2) exactly. World → camera: computing the camera's inverse transform via the orthogonality shortcut above, then applying it, gives (2.380139..., −8.226462..., 1). Computing the entire local-to-camera transform as one combined matrix product first, then applying it directly to the original local point in a single step, gives exactly the same result — a maximum difference of 0.0 between the two computation paths.
camera→world matrix by the computed world→camera matrix gives the identity matrix exactly: [[1,0,0],[0,1,0],[0,0,1]] (to the displayed precision) — confirming the change-of-basis matrix genuinely undoes the camera's own transform, not just approximately.
Where This Connects
| This chapter's finding | What it sets up |
|---|---|
| Rotation + translation as one homogeneous matrix | Directly generalizes to 3D with 4×4 matrices, using the exact same Rx/Ry/Rz building blocks from Chapter 6 |
The orthogonal-matrix inverse shortcut, R⁻¹=Rᵀ | A direct callback to Chapter 4's own dot-product orthogonality checks, now used as a genuine computational shortcut rather than just a verification tool |
| A consistent, verified coordinate pipeline | Chapter 9's intersection tests all assume every object being tested has already been placed into one shared, consistent coordinate space — exactly what this chapter builds |
Hands-On Exercises
Using this chapter's own homogeneous transformation matrix, build the local-to-world matrix for an object at world position (3, 4) rotated 90°, and use it to find the world-space position of the local point (2, 0).
Using this chapter's own orthogonal-matrix inverse shortcut, explain why R⁻¹=Rᵀ is specifically true for a rotation matrix but would not be true for a general matrix that also scales an object (for example, one that stretches an object twice as wide as it is tall).
A game engine transforms 10,000 object vertices from local space into camera space every frame. Using this chapter's own verified finding that computing a combined transform once and applying it directly gives exactly the same result as applying each step separately, explain why precomputing the single combined local-to-camera matrix once per object (rather than transforming each vertex through local→world→camera as three separate matrix multiplications) is a meaningful performance improvement.
📄 View solutionChapter 8 Quick Reference
- Homogeneous coordinates: a 3rd coordinate (
=1) lets rotation and translation combine into one matrix, applied via ordinary matrix-vector multiplication - Pipeline spaces: local (object) → world (shared scene) → camera (relative to the viewer) → screen (final pixels, beyond this course's scope)
- Change of basis: going from world space into camera space needs the camera's own transform inverted — and because rotation matrices are orthogonal,
R⁻¹=Rᵀavoids a full matrix inversion - Verified: a full local→world→camera pipeline computed step by step matches a single precomputed combined matrix exactly (
0.0difference), and the computed inverse correctly undoes the camera's transform (product = exact identity) - Next chapter: Geometric primitives and intersection tests — line-line, ray-sphere, ray-plane, and point-in-polygon, all assuming objects already share one consistent coordinate space