You have probably seen it without knowing what it was called. A puddle mirrors the neon sign across the street, and then the reflection slides out of existence as you turn the camera. A character walks past a window and the character never appears in the glass. A shadow edge crawls and flickers as you walk. None of these are bugs in the usual sense. They are the fingerprint of the one trick that makes game graphics run at 60 frames per second — a trick that works so well that almost every game still uses it, and that also makes certain kinds of realism structurally impossible.
This article explains that trick, why it is fast, and exactly which kinds of fakery it forces on developers. By the end you should be able to look at a visual glitch and tell whether it means “this game needs a stronger GPU” or “this game is using an approximation that no GPU power can fix.”
The pipeline draws geometry; it never asks what is visible
Games are built from triangles. Thousands to billions of them, all with vertices in 3D space. When you press nothing and the camera sits still, here is roughly what your GPU does each frame:
Each vertex is transformed from world space into the coordinates of the camera, then projected onto the flat screen. Each triangle becomes a 2D shape on screen. The GPU then walks the pixels near that shape and asks, for each pixel center, “am I inside this triangle?” — a cheap test performed with something called an edge function (a signed measure of which side of each of the three edges the point lies on). If the pixel is inside, the GPU interpolates a depth value and texture coordinates across the triangle, compares that depth against the value already stored for that pixel in the depth buffer, and if the new surface is closer, it overwrites both the color and the depth 12.
That depth buffer is the quiet hero. It holds one number per sample — the distance of the closest surface drawn so far — so hidden-surface removal costs constant space and roughly constant time per sample, with no sorting of the scene at all. The pipeline just draws everything and lets the buffer resolve what wins 1.
Notice the direction of the logic: geometry goes in, pixels come out. The GPU never asks the reverse question, “for this pixel, what is the closest object in the whole scene?” It only ever handles the triangle currently in front of it.
Why that is so fast
The cost of a frame breaks into two roughly separable parts: processing the triangles you submitted, and shading the pixels that end up visible. The second part is the expensive one, and here is the crucial property — its size is fixed by your resolution, not by the scene.
At 1920×1080 there are about 2.1 million pixels. At 4K there are about 8.3 million. That number is known before the frame starts. A scene with ten triangles and a scene with ten million triangles cost roughly the same amount per pixel once the visible surfaces are decided, because shading runs once per covered pixel, not once per object. Even overdraw — surfaces drawn and then covered by closer ones — is partly forgiven, since modern GPUs test depth before running the shader (early-Z) and skip shading for pixels that already lost.
This gives developers a clean budget: pick a per-pixel shading cost such that pixels × cost fits inside 16.7 milliseconds for 60 fps. Everything is uniform, predictable, and memory-access-friendly, which is exactly what GPU hardware is built to chew through in parallel. That is the trick. Rasterization does not compute the correct answer to “what does this pixel see?” — it produces the right pixels by brute forward traversal, and the depth buffer sorts out the truth.
The tax: a pixel knows almost nothing about the scene
Now the problem. The physically correct question at a surface point is not “what color is this material under these lights?” It is “how much light arrives here from every direction, after bouncing off and passing through everything else in the world?” A pixel shader knows the position of the surface, its normal, its texture, and a short list of light sources. It knows nothing about the other geometry in the scene. There is simply no moment in the pipeline where that global question gets asked.
So engines fake those effects in separate passes and paste the results back in. Each pass is an approximation with its own built-in failure mode.
Shadows: render the scene a second time, from the light
The standard trick is a shadow map. Before drawing the frame from your camera, the engine draws the scene from the light's point of view and stores only depth — how far away the nearest surface is along each direction from the light. When shading, it takes the point you are looking at, projects it into that light-view image, and compares distances. Farther than the stored value means something is in the way, so the point is in shadow 3.
Everything about this is a depth-image resampling problem, and it shows. If the two depths are nearly equal, floating-point error makes a surface shadow itself — the moiré pattern called shadow acne. Nudging the depth comparison by a small bias fixes it, but too large a bias pushes the shadow away from the object casting it, so characters and crates seem to hover: an artifact known after the boy who lost his shadow, “peter panning” 4. And the sharpness of a shadow is set by the shadow map's resolution, not your screen's, so a 4K display combined with a small shadow map gives mushy or stair-stepped edges. Because the light's projection window is recalculated as your camera moves, shadow edges can also shimmer frame to frame; a common fix is to round that projection to whole texels so it stays stable 3.
Every one of those fixes is a tug on a rope tied to something else. Sharpness wants resolution; resolution costs memory and time; stability wants a fixed projection window; accuracy wants a tight one.
Reflections: only what the camera can already see
Reflections are worse, because a reflection is literally a ray that leaves a surface and asks what it hits. Rasterization has no such ray.
Two approximations dominate. The first is the cube map: a pre-rendered snapshot of the surroundings, sampled in the reflected direction. It is nearly free, and it is wrong in a specific way — the snapshot was taken from one point in space at one time, so reflections have no correct position or parallax. Open a door in a room and the mirrored cabinet keeps reflecting the room as it was before.
The second is screen-space reflections (SSR). The engine marches a ray through the image it has already rendered, using the depth buffer to detect hits, and grabs the color it finds. It is cheap, it works for dynamic objects, and its limitations are all the same limitation: it can only reflect what is already visible on your screen. Objects outside the frame or behind other objects are not in the buffer, so the reflection fades out at screen edges, characters fail to appear in mirrors, and object thickness has to be guessed, which produces false hits and fake dark smudges 56. Worse, the available information changes every frame as the camera moves, so these errors do not sit still: reflections ghost, pop in and out, and sparkle with noise, especially since the effect is usually computed at half resolution 5.
Both tricks are guessing at the answer to the question rasterization was never able to ask.
The signature symptom: information errors, not resolution errors
Here is the distinction worth carrying away. Some visual flaws come from not having enough samples: jagged edges, low-resolution textures, noisy shadows. Those are resolution errors, and a better GPU with more samples mostly fixes them.
The artifacts above are information errors. Turning the resolution up does not help, because the missing data was never in the picture to begin with. A screen-space reflection can be computed at 8K and still cannot reflect the building behind you. A baked-in lighting solution can look gorgeous and still not change when you shoot out a window. When you notice a flaw that survives every quality slider, you are almost certainly looking at an approximation, not a shortage of horsepower.
Where ray tracing plugs in, and what it costs
Ray tracing asks the question directly: from this pixel, fire a ray into the scene, find the first surface it hits — and then, from that hit, fire more rays to lights, in reflected directions, and in scattered directions, to find out where the light actually comes from. It is the reverse-direction algorithm, and it does not care about screen edges or pre-baked snapshots.
The cost profile is inverted relative to rasterization. Rasterization is roughly linear in the number of pixels and triangles. Ray tracing's cost depends on how many rays you fire and how hard each one is to trace, which is why ray tracers organize the scene into a bounding volume hierarchy (BVH) — a tree of nested boxes that lets a ray skip most of the geometry instead of testing every triangle 7.
That structure has three consequences that explain everything about ray tracing in games today 8:
- Rays are cheap individually, but there are a lot of them, and they multiply. In one published measurement of a 19-million-triangle animated scene, rasterizing the geometry buffer for the whole frame took about 2.7 ms. Tracing one primary ray per pixel — the minimal case, just finding what each pixel sees, exactly what rasterization already gives you — took about 2.9 ms. That single ray already costs about as much as the entire raster pass; every additional bounce is another multiplier, and each reflection, shadow, or light-bounce ray costs roughly as much again.
- The scene has to be maintained, not just drawn. Animated characters and foliage require the BVH to be rebuilt or updated each frame. In the same measurement, animation plus BVH updates cost about 5.7 ms on top of the tracing itself, and dynamic acceleration structures can consume 60–80 bytes per triangle of memory — roughly a third of a gigabyte for a few hundred animated characters.
- Rays after the first bounce go everywhere. Rasterization's memory access is orderly because neighboring pixels touch neighboring data. A bounce or a diffuse ray scatters, so adjacent threads no longer read adjacent data and the hardware's parallelism degrades. That is the deep reason a single primary ray is already competitive but the tenth bounce is not.
That is why almost no game renders everything with ray tracing. The raster pipeline still draws the frame, and ray tracing is switched on for individual effects where the approximation visibly fails — sharp dynamic shadows, true reflections that reach off-screen, and bounced light in interiors. And because even that is too expensive at full quality, engines trace relatively few rays per pixel and lean on temporal accumulation and denoising: reuse information from previous frames and neighboring pixels to clean up the noise. That is the origin of the grainy, slightly smeared look ray-traced effects take on while the camera is moving — the cleaner image is borrowed from frames that no longer quite match, and the artifacts FPS drops and ghosting that accompany the switch.
How to read the trade-off yourself
The practical question is never “is ray tracing better?” It is “which approximation am I buying my way out of, and what does it cost me in frame time?”
When a game offers the option, think about what the effect needs. Reflections physically require rays that reach the parts of the world your camera cannot see, so that is where ray tracing changes the image most. Shadows and ambient light in a static, pre-baked scene may already look right, and paying milliseconds for them buys little. Indoors, where the whole mood depends on light bouncing between walls, ray-traced global illumination is the upgrade you will actually feel.
And if you want to see the fingerprint for yourself, look in motion rather than at a screenshot. Reflections that disappear at the screen edge or refuse to include your character are screen-space. Shadows whose softness does not match their size are shadow maps. Lighting that ignores destruction and moving doors was baked in. None of those will improve much when you buy a faster graphics card — only when the engine stops guessing and starts tracing.