Rasterization: how triangles become pixels

Rasterization inverts the ray tracer's question. Instead of asking "what does this pixel see?", it asks "which pixels does this triangle cover?" That sounds like the same work, but it has one enormous advantage: the work is naturally parallel over triangles, and each triangle only touches a small screen region.

The pipeline, in order, with the one thing each stage is for:

Vertex shader — transform each vertex from model space to clip space. This is where the famous MVP matrix lives: Model → View → Projection.

Clipping — clip primitives against the view frustum.

Perspective divide + viewport — divide clip coordinates by `w`, then map to render-target coordinates.

Triangle setup / rasterize — determine coverage and generate fragments for covered samples.

Fragment shader — shade generated fragments; with multisampling, one pixel can contain multiple covered samples.

Depth/stencil tests and blending — tests decide which fragments pass; if blending is enabled, passing shader output is combined with the existing render-target value before writing.

// The MVP chain, written out (column-major, so it reads right-to-left)
clip = Projection * View * Model * vec4(pos_model, 1.0)

// After the vertex shader you have clip-space positions.
// The GPU then does, per vertex:
ndc = clip.xyz / clip.w     // <- perspective divide, this is what makes far things small

// And per pixel, the rasterizer interpolates attributes like uv/normal
// with PERSPECTIVE-CORRECT weights (dividing by w again). This is why
// a texture does not swim when a floor recedes into the distance.

For a first teaching implementation, brute-force ray tracing is conceptually compact but expensive as scene complexity grows. Rasterization has more pipeline rules, while hardware can process many projected triangles efficiently. Production systems make both approaches substantially more sophisticated.