Matrices in Computer Graphics

Homogeneous coordinates are simply ordinary coordinates with an extra 1 tacked on the end, so the point $(x, y)$ becomes $(x, y, 1)$. The name comes from projective geometry, where scaling all the coordinates together, like $(2x, 2y, 2)$, still describes the same point. It's good for one very practical reason: it lets a single matrix slide things around, which ordinary $2\times2$ matrices can't do. The translation formula looks like a big block of numbers, but it's mostly the identity: the $1$s and $0$s leave $x$ and $y$ alone, and $h$ and $k$ (the shifts) sit in the last column, where that extra $1$ picks them up and adds them on. That's the whole trick.

The problem. Rotation and scaling are linear, so they're matrices. Moving an object isn't: a linear transformation always sends $\vec 0$ to $\vec 0$, and a translation moves the origin. Graphics needs all three constantly.

The fix. Represent $(x, y)$ as $(x, y, 1)$. Now a $3\times3$ matrix can rotate, scale and translate. In 3D, points become $(x, y, z, 1)$ and matrices are $4\times4$.

Composition. This is matrix multiplication from the start of the unit, put to work. To scale, then rotate, then move, multiply $T\,R\,S$ (rightmost first) into one matrix and apply it to every vertex. A game might do that for millions of vertices every frame, so combining first saves a lot of work.

A common mistake. It's tempting to think the order of the moves doesn't matter, since you end up doing all of them anyway. It does: rotating then translating differs from translating then rotating, because rotation always spins around the origin, and translating first changes where the object sits relative to it.

Perspective. The last row can also do perspective division, and that's how a 3D scene gets projected onto your screen.

Every 3D game and CAD program multiplies 4×4 homogeneous matrices for every vertex, every frame; the camera projection lab uses exactly this pipeline.