rendering

The two renderer architectures are not competing implementations of the same idea. One sorts fragments for a single viewpoint, the other searches for a hit along an arbitrary ray. Reading them that way explains which effects are cheap in each, why production renderers combine them, and what a hybrid actually buys.

Ray tracing takes the opposite loop: for each pixel, find the geometry it hits. That buys visibility queries from any point in any direction, which is what shadows and reflections need. It also costs a scene-wide data structure, and the quality of that structure decides whether the renderer is usable.

Rasterisation walks the geometry and asks which pixels each triangle covers. Two ideas make that fast enough for real time: a coverage test that is three linear functions, and a depth buffer that resolves visibility without sorting anything. This lesson builds both and shows why the design maps onto parallel hardware.

Every renderer answers one question first: at this pixel, which surface is visible? Getting there means moving geometry through five coordinate spaces. This lesson builds that chain, explains why a fourth coordinate is not a trick, and shows where depth precision quietly goes wrong.

Differentiating a renderer is easy until geometry moves. Why silhouettes break naive automatic differentiation, and the three families of solutions: edge sampling, reparameterization, and warped-area methods.

Before you can differentiate a renderer you have to see it as mathematics: the rendering equation, why it has no closed-form solution, and how Monte Carlo path tracing turns light transport into an estimation problem.

How modern 3D generation paints a mesh after it's built. UV unwrapping, multi-view diffusion for texture, view-consistency, PBR map decomposition, and the workflow Meshy and Tripo expose to users in 2026.