Sort or Search: Why Both Pipelines Survive

Both pipelines answer the same question: along a given ray, which surface is nearest? The difference is what they build to answer it.

A rasteriser builds a depth buffer. It is a per-pixel record of the nearest thing found so far, filled by streaming geometry past it in any order. That is a distributed sort by depth, done incrementally, with one comparison per fragment and no global bookkeeping.

A ray tracer builds a spatial hierarchy. It is a record of where geometry is in space, and it is queried rather than filled. That is a search structure.

Sort versus search is the whole distinction. Everything downstream follows from it: which effects are cheap, how each degrades, what each needs to know before it can start, and what happens when the scene changes.

A depth buffer is indexed by pixel, so it holds the answer for rays sharing one origin. Change the origin and it is worthless: nothing in it says what is visible from a light, or from a point on a mirror.

A hierarchy is indexed by position in space, so it answers for any origin and direction at the same cost.

That single asymmetry explains the effect list. Camera visibility needs one origin, so rasterisation handles it. A shadow needs visibility from the light, a reflection from a surface point in a direction that varies per pixel, ambient occlusion from every shading point in many directions, and global illumination from every point in every direction.

Each step down that list adds origins, and each is correspondingly harder to fake in a rasteriser and more natural in a tracer.

Read this as a diagnosis rather than a menu. Every rasteriser technique with a reputation for artefacts sits on this diagram at the point where it ran out of origins.

Shadow mapping works because a light is one fixed extra origin, so a second depth buffer covers it. Its familiar problems, acne, peter-panning and resolution aliasing, are all sampling artefacts of that one buffer.

Screen-space reflections fail on anything not currently visible on screen, and that is not an implementation weakness: the only depth information available is for the camera's origin, so reflections of off-screen geometry were never in the data.

The artefacts are not bugs. They are the shape of the missing information.

Before reaching for rays, rasterisers extract more from the sort they already do. The previous lesson noted that overdraw wastes shading on fragments later covered. Deferred shading removes the waste by splitting the pass in two.

The first pass rasterises geometry but computes no lighting. It writes surface parameters, position or depth, normal, albedo, roughness, into a set of buffers, letting the depth test resolve visibility. The second pass runs once per pixel over those buffers and computes lighting for the one surface that survived.

Shading cost becomes independent of scene depth complexity, and lighting cost becomes proportional to pixels times lights rather than fragments times lights.

The price is a fixed vocabulary of surface parameters, since anything the buffers cannot express cannot be shaded later, plus bandwidth, plus the standing transparency problem: a translucent surface has no single set of parameters per pixel.

Production real-time renderers now run both. The division of labour follows directly from the two cost models.

Primary visibility goes to the rasteriser. Those rays share one origin, are perfectly coherent, and the depth buffer resolves them with one comparison per fragment. Tracing them instead means paying tree traversal for a query the sort already answers.

Secondary visibility goes to the tracer. Shadows, reflections and indirect light all need origins the depth buffer cannot supply, and those are exactly the rays worth paying traversal for.

The join is the buffer written by the first pass. A deferred pass leaves position and normal per pixel, which is precisely the origin and surface frame a secondary ray needs. That is why deferred shading and hybrid ray tracing fit together so neatly: the buffer built to defer lighting is also a buffer of ray origins.

Reduced to the questions that actually decide it:

How many ray origins does the image need?
  one, the camera            -> rasterise
  one plus a few fixed       -> rasterise, one depth map per extra origin
  one per pixel, varying     -> trace secondary rays, keep primary rasterised
  many per pixel             -> trace, and budget for noise and denoising

Does the geometry deform every frame?
  yes, heavily               -> rasterisation is cheaper; BVH refit costs
  no, mostly rigid instances -> a two-level BVH handles motion well

Is the frame budget fixed?
  yes, real time             -> rasterise what you can, trace what you must
  no, offline                -> trace everything; the sort buys nothing

The first question does most of the work, and it is a question about the image rather than about the hardware. Notice the last line: offline renderers do not use a depth buffer, because when there is no frame budget the rasteriser's speed advantage on primary rays is not worth maintaining a second architecture.

Once rays are traced for lighting rather than visibility, a new cost appears that has no analogue in rasterisation.

Indirect light at a point is an integral over all incoming directions, which the lesson Rendering as an Integral develops properly. Tracing rays estimates that integral by sampling it, and an estimate from a handful of samples is noisy. Halving the noise requires roughly four times the samples, because the error of a Monte Carlo estimate falls with the square root of the sample count.

At a few rays per pixel, which is the real-time budget, the raw result is unusable. What makes it shippable is denoising: reusing samples from neighbouring pixels and from previous frames, guided by the position and normal buffers to avoid mixing across surfaces.

So a real-time tracer is not a small offline tracer. It is a very sparse estimate plus a reconstruction step, and the reconstruction is doing much of the work.

The rows are not a scorecard. They are two coherent sets of trade-offs that happen to be complementary, which is why the field settled on using both rather than one replacing the other.

The sharpest way to hold it: rasterisation is cheap because it answers one question; ray tracing is expensive because it answers all of them.

The arc was one question narrowing. Projection moved geometry into a space where visibility could be asked. Then visibility was answered twice, by sorting and by searching, and every property of the two pipelines followed from that choice rather than from implementation quality.

The transferable habit is to read a rendering feature by asking what visibility query it requires and from how many origins. That predicts, without knowing anything about the engine, whether the feature will be cheap, whether it will be approximated, and what its artefacts will look like when the approximation runs out.

It also cuts through the framing that treats one architecture as the successor to the other. They compute different things. A depth buffer is not a worse hierarchy, and a hierarchy is not a better depth buffer.