Frustum Culling vs Occlusion Culling in Game Rendering

A real-time renderer can contain far more scene objects than the camera can use in one frame. Visibility culling is the broad family of tests that rejects some of that work before the full rendering path is spent on it. The important question is not simply whether an object exists in the level, but whether it can contribute to the current view.

Frustum culling and occlusion culling answer different visibility questions. Frustum culling asks whether an object is inside the camera’s view volume at all. Occlusion culling goes further and asks whether an object that is inside that view is hidden by nearer geometry. Modern engines can combine these tests with distance culling, precomputed visibility, level-of-detail systems and engine-specific GPU-driven techniques.

The camera frustum represents the region that can project into the camera view, bounded by the camera field of view and clipping planes. Unreal Engine documents view-frustum culling as removing objects outside this region before more expensive dynamic occlusion work. Unity likewise distinguishes its default frustum culling from occlusion culling: an object outside the camera frustum does not need an occlusion test to establish that it cannot be seen by that camera.

Engines normally test a simpler bound rather than every triangle of every mesh. Unreal, for example, documents Actor bounds made from a box and sphere for visibility work. This is a conservative shortcut: a bound can intersect the frustum even when little or none of the detailed mesh would ultimately be visible. A false “possibly visible” result costs later work, but an aggressive false rejection could make geometry disappear incorrectly.

Passing the frustum test does not mean an object will contribute visible pixels. A building can be inside the camera view while sitting completely behind another building. Occlusion culling attempts to identify cases like this so the renderer can avoid some downstream work for the hidden object.

There is no single universal occlusion algorithm used by every PC game. Unreal Engine documents dynamic hardware occlusion queries that use scene depth information and return visibility state after GPU testing, as well as precomputed visibility and other platform-dependent methods. Unity’s built-in system instead documents baked scene visibility data queried at runtime. Direct3D 12 also exposes occlusion and binary-occlusion query types, giving engines a lower-level mechanism from which a visibility system can be built.

A depth buffer records which rendered surfaces are nearest at covered screen locations. That makes depth useful for determining whether the bounds of a candidate object would contribute any samples in front of geometry already known to be closer. Microsoft’s Direct3D 12 binary occlusion query, for example, returns zero when no samples pass depth and stencil testing and one when at least one sample passes.

Engines do not have to expose that exact API or query model to a player, and newer renderers may batch, delay, approximate or restructure visibility work. The general principle is more durable than one implementation: occlusion needs evidence about what blocks the candidate from the current viewpoint, whereas frustum culling needs only the camera volume and candidate bounds.

Every visibility system consumes resources of its own. Unreal’s documentation notes that hardware occlusion-query cost scales with the number of queries and that visibility methods can be layered in a cost-conscious order. Unity similarly warns that its built-in occlusion system performs runtime CPU calculations and consumes memory for baked data, so the saved rendering work can be offset by the culling work itself.

That trade-off is why there is no honest universal FPS gain for “enabling occlusion culling.” A scene with large opaque walls and many hidden objects presents a different opportunity from an open landscape where most in-frustum objects are genuinely visible. Object granularity matters too: very coarse bounds can keep large groups alive when only a small part might be visible, while extremely fine partitioning can increase bookkeeping and query overhead.

Visibility systems generally need to prefer rendering something that might be visible over incorrectly deleting something the player should see. Unity explicitly describes its occlusion data as conservative: unless an object is established as invisible, it is treated as visible. Higher-resolution visibility data can improve culling precision, but Unity documents a corresponding increase in data size and reduced culling speed.

Latency can matter as well. Unreal documents that its hardware occlusion-query result is read back one frame later and notes that rapid camera movement can expose visible popping in some cases. Engines use heuristics and different techniques to manage these trade-offs, so a diagram of an idealized culling pipeline should not be mistaken for the exact frame pipeline of every game.

Culling an object from one rasterized camera view does not mean the object is irrelevant to every rendering effect. Shadows, reflections, secondary views and ray tracing can have different visibility requirements. Unreal’s ray-tracing guidance is a concrete example: geometry outside the main camera view may still be needed for reflections, so the engine exposes separate ray-tracing culling controls.

For players, frustum and occlusion culling are therefore best understood as renderer optimization strategies rather than graphics-quality settings with predictable performance multipliers. For developers, the useful metric is whether a visibility test removes enough otherwise expensive work to justify its CPU, GPU, memory and latency costs in the actual scene and target hardware.