Two ways to answer "what colour is this pixel?"

Rasterisation vs ray tracing

The same scene, rendered twice. A rasteriser loops over objects and asks which pixels each one covers; a ray tracer loops over pixels and asks what each one can see. That difference in direction is why one of them can follow light around the scene and the other cannot.

Rasterised —

Ray traced —

Difference —
Rasteriser loops over
objects → pixels
Ray tracer loops over
pixels → objects
Pixels that differ
—
Rays cast per frame
—
Effects switch them on
4

With workarounds on, the rasteriser gets a projected shadow and a static environment reflection — the tricks real engines used for twenty years. Look closely: the reflection shows a sky that is not in this scene, and the spheres do not appear in each other.

The two inner loops why the difference follows 

      
The rasteriser's inner loop has a triangle and a pixel in hand and nothing else. To know whether a light reaches this point it would have to consult the rest of the scene, which is not available. The ray tracer's inner loop can query the whole scene at any moment, so asking "is anything between here and the light?" costs one more function call.

    

  


  

    

      This is not a fair fight, and that is the point. Rasterisation wins on speed by an enormous margin — it touches each object once and never searches the scene, which is why it has driven real-time graphics for thirty years and why the GPU is built around it. Everything it cannot do it has learned to fake: shadow maps, environment maps, screen-space reflections, light probes. Each of those is a separate approximation with its own artefacts and its own tuning. Ray tracing needs none of them, because following the light is the same operation every time — and pays for that generality in compute. Modern engines run both: rasterise the visible surfaces, then trace rays only for the effects rasterisation cannot reach.