Core Idea
Rasterization walks the geometry and asks, per triangle, which pixels do I cover? Ray tracing inverts the loop: per pixel, what do I see? — shoot a ray from the camera through the pixel, intersect it against the actual scene geometry, and shade whatever it hits first.
The image above is exactly that, with nothing hidden: a real ray tracer running in JavaScript on your CPU, painting scanline by scanline because that is how long it takes. The ray–sphere intersection is one quadratic — P(t) = O + tD into the sphere equation, solved analytically. No coverage tests, no depth buffer: the nearest positive t is the visibility answer.
One Pixel’s Ray Tree
The hit is where tracing stops being a rasterizer-in-reverse and becomes a light simulator — because every hit spawns more rays:
- a shadow ray aims straight at the light: blocked means in shadow — geometry, not a texture trick;
- a reflection ray bounces off the normal and recurses — mirrors show whatever is actually there, including things behind the camera;
- a refraction ray (for glass) bends through, by the same recursion.
Drag the tree above: one pixel is already four rays deep. Note the direction of travel — real light runs from sources to eyes, but tracing runs backward, eye-first, so only rays that matter to the image are ever paid for. At the end of every ray, the color still comes from the same shading recipe — tracing changes what gets asked, not what a material is.
What the Recursion Buys
| Effect | Rasterization fakes it with | Tracing computes it |
|---|---|---|
| reflections | cube maps, screen-space hacks | exactly, off-screen objects included |
| shadows | shadow-map textures | shadow rays — crisp or area-soft |
| global illumination | baked or screen-space approximations | bounced rays; color bleed falls out naturally |
Push the bounce logic to hundreds of randomized rays per pixel and it becomes path tracing — the film-render standard the hero’s single bounce is a first step toward.
The Price
The demo makes it visible: even three spheres at 208×132 take real time when every pixel interrogates the scene. Naive tracing costs pixels × objects × bounces — which is why real tracers lean on BVHs (bounding volume hierarchies): the scene wrapped in nested boxes so a ray discards most geometry in a few cheap tests, turning per-object cost into roughly log-of-scene. Dedicated hardware now runs that traversal in silicon on native platforms, where the production norm is hybrid rendering — rasterize the visibility, trace only where honesty is irreplaceable (reflections, GI, soft shadows).
The Web Reality
Browsers expose no hardware ray-tracing API, so on the web tracing lives three ways: offline — baked lightmaps and prerendered stills, traced ahead of time; in shaders — the whole algorithm written inside a fragment or compute program against math-defined scenes; and as its sibling — ray marching, which keeps the per-pixel ray but swaps analytic intersection for stepping through a distance field. Either way the cost model is the GPU-bound one: per-pixel work, priced by resolution.
Connections
Ray tracing is the pipeline’s question turned inside out — rasterization streams geometry to pixels, tracing pulls pixels through geometry. Its hits are shaded by the standard recipe using surface normals for every bounce decision, and its web-native cousin is ray marching — same ray, different way of finding the surface.