Ray Tracing BVHs Explained: BLAS, TLAS, Traversal, and Why Games Need Them

A ray can potentially intersect many triangles and other primitives in a 3D scene. Testing every ray against every primitive would waste enormous amounts of work, especially when most geometry is nowhere near the ray. Ray-tracing APIs therefore expose acceleration structures that organize scene geometry so traversal can reject large regions before performing detailed intersection tests.

A bounding volume hierarchy, or BVH, is a common acceleration technique. Bounding boxes enclose progressively smaller groups of geometry in a tree. During traversal, a ray that misses a higher-level box can skip the geometry below it. NVIDIA describes BVH traversal as an alternative to testing every primitive, while DirectX Raytracing exposes a two-level acceleration-structure model that applications build before tracing rays.

Microsoft defines bottom-level acceleration structures as sets of geometry and a top-level acceleration structure as a set of instances of bottom-level structures. A BLAS can contain triangle meshes or procedural primitives initially represented by axis-aligned bounding boxes. The TLAS then references BLAS objects through instances, carrying scene-level information such as transforms.

That split is useful for games because geometry and placement do not always change together. A mesh can remain the same while an instance moves, rotates, or appears many times. NVIDIA’s DXR tutorial demonstrates this directly: a TLAS can instantiate the same BLAS multiple times with different transformation matrices. The API model therefore avoids duplicating object geometry merely because the scene contains repeated instances.

Conceptually, traversal starts with coarse bounding volumes and follows only branches whose bounds intersect the ray. Each successful bounding-volume test narrows the candidate region until traversal reaches geometry that may require a triangle or procedural-primitive intersection test. The exact tree layout, branching strategy, builder heuristics, and hardware implementation are not fixed by the simple BLAS/TLAS vocabulary and can differ across implementations.

The practical goal is not to make intersection tests disappear. It is to avoid performing detailed tests against geometry that spatial reasoning can rule out early. Scene organization, ray coherence, geometry distribution, and the quality of the built acceleration structure can therefore affect how much traversal work a ray requires.

Acceleration structures are not free metadata. DXR requires applications to query prebuild information, allocate result storage and temporary scratch space, and issue an acceleration-structure build. NVIDIA’s DXR tutorial likewise describes BLAS generation on the GPU and separate scratch and result buffers. This is one reason ray tracing can add GPU-memory pressure beyond textures, render targets, and ordinary geometry buffers.

Build quality and build speed can also pull in different directions. Static geometry may justify work that improves the structure used for many later rays, while rapidly changing content may need cheaper updates or rebuilds. Applications choose API build flags and update strategies according to their content; there is no universal rebuild schedule that is optimal for every game.

Rigid motion is a natural fit for the two-level hierarchy. If the underlying mesh does not change, a game can keep its BLAS geometry and change the instance transform represented at the TLAS level. Microsoft’s current DXR sample shows a BLAS built for cube geometry while the TLAS is rebuilt with updated transformation matrices for animated instances.

Deforming geometry is a different problem because the spatial relationship among the primitives inside the BLAS changes. Skinned characters, destructible meshes, procedural geometry, and other dynamic content can therefore create different acceleration-structure maintenance costs from a rigid object that merely changes its world-space transform. How a specific engine handles those cases is an implementation decision, not something the words BLAS and TLAS alone determine.

A faster hierarchy search does not make the rest of a ray-tracing workload free. Games still generate rays, execute intersection and hit or miss logic, access materials and textures, schedule shading work, manage denoising or reconstruction, and often combine ray-traced effects with conventional rasterization. The number and type of rays, bounce count, scene complexity, alpha-tested geometry, divergence, resolution, and effect design can all change the workload.

This is also why a hardware label such as “RT core” should not be treated as a complete ray-tracing benchmark. Hardware vendors can accelerate parts of traversal and intersection, but APIs expose a broader pipeline and games differ substantially in how they use it. Compare measured performance in the actual game and settings you care about rather than deriving frame rate from one acceleration-structure property.

Ray-tracing APIs continue to evolve around expensive geometry cases. DirectX Raytracing 1.2 adds opacity micromaps, for example, so alpha-state information can be represented in dedicated data and used during traversal instead of always requiring the same shader work for alpha-tested geometry. Microsoft’s implementation material still builds BLAS and TLAS around that data rather than replacing the two-level scene hierarchy.

That distinction matters when reading optimization claims. A new feature can reduce one category of traversal or shader work without changing the basic need to spatially organize geometry. Treat BVHs, specialized micromap data, shader execution, denoising, and upscaling as related but separate parts of the renderer.

BLAS and TLAS are useful mental models for understanding how a game separates object geometry from scene instances and how rays avoid brute-force intersection searches. They also explain why ray tracing consumes memory and why dynamic scenes can require acceleration-structure maintenance before or during rendering.

They do not reveal a GPU’s proprietary BVH layout, traversal-unit design, exact memory footprint, branching factor, or performance in a particular game. Those details require implementation-specific documentation or measurements. For PC performance analysis, acceleration structures are one important layer between scene geometry and ray hits—not a standalone score for either a GPU or a game engine.