Screen-Space vs Ray-Traced Reflections in Games

Screen-space reflections (SSR) reuse information already available from the current rendered view. That makes them a practical real-time technique, but it also gives them a hard visibility boundary: geometry that is outside the camera view, hidden behind another object, or otherwise absent from the screen-space data cannot reliably appear in the reflection. Epic describes SSR as view-dependent and limited to information present within the current screen view.

Ray-traced reflections can instead trace against a representation of scene geometry. In a hardware ray-tracing path that can mean triangle geometry held in acceleration structures; other systems can trace against alternative scene representations. This gives a renderer a way to find reflection information beyond the visible framebuffer, but it does not mean every ray-traced implementation contains every object, traces indefinitely, or produces the same result.

Imagine a shiny floor reflecting a character who is standing near the edge of the camera. While the character contributes useful pixels and depth information to the current view, SSR can use that information. As the character leaves the screen, the renderer no longer has the same screen-space evidence to trace against, so the reflection can fade, break, or fall back to another source.

Occlusion creates a similar problem. A reflected object may physically exist in the game world but be hidden from the main camera by nearer geometry. If the reflection method only searches current screen data, world-space existence alone is not enough. This is why SSR artifacts are fundamentally tied to visibility rather than simply to a generic “reflection quality” slider.

Hardware ray tracing can intersect rays with scene triangles through acceleration structures, allowing reflection queries to reach geometry that is not represented by the current screen pixels. Epic documents Lumen hardware ray tracing as tracing against triangles and supporting a larger range of geometry than its software ray-tracing path. That is a meaningful capability difference from standalone SSR.

The practical result still depends on what the engine puts into its ray-tracing scene and how far or how often it traces. Geometry can be represented differently, culled, simplified, or omitted; dynamic geometry can add acceleration-structure update cost; lighting at a ray hit may come from a cached representation instead of being fully evaluated there. “Ray traced” therefore describes a rendering path, not a guarantee of unlimited scene visibility or perfect reflections.

SSR versus ray tracing is useful for understanding the techniques, but it is not always a binary choice inside a modern renderer. Unreal Engine 5 Lumen is a clear example. Epic says Lumen performs screen traces first and then falls back to a more reliable tracing method when a screen trace misses or passes behind a surface. Lumen can use software ray tracing through distance fields or hardware ray tracing against triangles.

Epic also describes Lumen Reflections as supporting screen, software, and hardware ray tracing together. A game using Lumen can therefore show behavior from multiple techniques in the same reflection pipeline. Seeing a screen-space artifact does not by itself prove that hardware ray tracing is globally disabled, and seeing ray-traced geometry does not prove that every reflection sample skipped screen tracing.

Real-time ray tracing operates under a frame-time budget. Engines can vary ray count, resolution, roughness thresholds, tracing distance, lighting evaluation and denoising. Epic’s Lumen hardware path, for example, can use its Surface Cache for faster reflection lighting or Hit Lighting to evaluate lighting at the ray hit for higher quality at greater GPU cost. Those are implementation choices inside one engine, not universal PC-game settings.

Low sample counts also make reconstruction and denoising important. A ray-traced reflection can contain more complete scene information than SSR while still showing temporal noise, instability, blur, ghosting, or denoising artifacts. Conversely, a well-placed SSR result can look convincing when the needed geometry is already visible. The technique label alone is not a complete image-quality measurement.

A fixed claim such as “ray-traced reflections cost 20 percent” cannot be transferred across games. The cost changes with rendering resolution, number and length of rays, scene complexity, dynamic geometry, material evaluation, reflection coverage, denoising, GPU architecture, other ray-traced effects, and whether the renderer is hybrid. Epic specifically notes scene-update costs for hardware ray tracing and higher GPU cost when Lumen evaluates lighting at reflection hit points.

SSR is commonly the lower-cost option because it works from screen-space data, but its cost also varies with resolution and quality settings. A fair game-specific comparison needs measurements from the same scene, settings, resolution and hardware. An engine documentation page can explain the rendering tradeoff; it cannot supply a universal benchmark delta for every PC game.

When a game exposes separate SSR and ray-traced-reflection options, treat them as controls for that game’s implementation rather than standardized quality tiers. Look for developer documentation or controlled testing that identifies which surfaces use each method, whether there is a fallback, which geometry participates, and whether ray tracing changes lighting or only visibility.

For hybrid renderers, the useful question is broader than “SSR or RT?” Ask which data source handles the first trace, what happens when it misses, what scene representation receives fallback rays, how hits are lit, and how the result is reconstructed. Those details explain why two games can both advertise ray-traced reflections yet differ substantially in image quality, artifacts, hardware requirements and performance.