Picture of Paritosh Kulkarni

Paritosh Kulkarni

Picture of Sho Ikeda

Sho Ikeda

Introduction

The Level of Details (LOD) technique is nothing new, at least to the world of rasterization. Many games have been using it and enjoying its benefits. But, when it comes to ray tracing the benefits of the level of details technique are not trivial. For example:

  • Secondary rays at higher depth might not need very detailed geometry. For such cases, it might be enough to use a coarse LOD representation of geometry for ray intersection/BVH traversal. Having BVH with a coarse LOD will decrease the number of nodes traversed and intersection tests performed by the secondary ray giving us a big win on performance.
  • Shadow rays and AO rays might not need very detailed geometry to trace against. Many approximations like cone tracing have been tried to address this issue. LOD does come in handy for this.

So, LODs can benefit us by reducing the ray-triangle intersection count and the number of nodes traversed in the BVH, as the coarse LOD representation of geometry will naturally have fewer triangles and hence fewer BVH nodes. Still, this is not a very straightforward solution as implementing traditional LOD methods does introduce more problems. For instance:

  1. Generally, we will have multiple LODs instances of the same geometry. All of these instances might not fit in GPU memory. Hence, a particular LOD instance that is not present in memory will be loaded on demand. This is not good for performance and can cause issues like load stutter. Instead of this, if we chose to keep all LOD instances in memory that will definitely increase the memory budget.
  2. Once we load the desired LOD instance we will need to update/rebuild the BVH which is definitely a performance-heavy operation.
  3. Based on some parameters like distance from origin/camera the LOD instance for a primary ray will be selected. The secondary ray should see exactly the same LOD level. If we chose a different level for secondary ray then we might see a hole artifact.

 

Previous attempts to adopt LOD techniques for ray tracing

Many attempts have been made to adopt the LOD techniques for the use case of ray tracing. Let’s explore some of them here.

RLOD approach

This method tries to simplify the existing set of triangles/mesh using principal component analysis. Based on some LOD error metrics we can stop at the internal node of BVH, and all primitives represented under that node are approximated using PCA to plane. Then use that plane for the intersection to get shading information.

Reference: RLOD: Fast LOD based ray tracing for massive models

Limitations:

  1. May not provide high-quality simplification for surfaces that have highly varying BRDF.
  2. LOD metric does not give guarantees on the errors in the path traced by the secondary rays and the illumination computed at each pixel.
  3. Projection-based LOD error metric can currently handle planar reflections and shadow rays, but not refraction nor non-planar reflection. Hence, not useful for general purpose path tracing.

Traversal Shader Approach

Current ray tracing pipelines make traversal and intersections a fixed-function operation. For custom primitives, intersection might be programmable but the traversal of BVH is a completely fixed function operation. This method tries to introduce a programmable BVH node that will act as a leaf node in TLAS. On ray intersection, with the programmable node, a traversal shader will be invoked. This traversal shader will have logic to transform the ray, calculate LOD, and select a proper instance of BLAS for further traversal.

Reference: Flexible Ray Traversal with an Extended Programming Model

Limitations:

  1. Need to update the ray tracing pipeline which is not easy.
  2. Assumes all LOD instances are present in BLAS.

Stochastic LOD

This is a multi-pass technique. In the first pass, we calculate the instance LOD and in the second pass, we use that LOD for tracing. The LOD calculation is done as pre-processing step.

Reference: Implementing Stochastic LOD with Microsoft DXR

Limitations:

  1. Secondary rays should see the same LOD level as primary rays else hole artifacts will be visible.

 

Basic requirements for a new LOD technique

As you can see above, the existing interesting methods to solve this issue have some limitations, though using LOD does have certain benefits when it comes to ray tracing.

So therefore while developing a new LOD technique we had some basic requirements:

  1. Ability to choose different LOD levels per ray.
  2. The low budget on GPU memory.
  3. No need to update the existing hardware pipeline – might add an extension to existing APIs which is easier.
  4. Make it work for general purpose path tracing. Hence, it should work with complex material networks and geometries.
  5. Get the performance uplift. No extra overhead is introduced by the technique itself.

With all of the above goals in mind what we came up with was our “Multi-Resolution Geometric Representation using Bounding Volume Hierarchy for Ray Tracing” technique.

We tried to use the existing BVH and simulate the LOD. We define a new LOD threshold heuristic to stop the BVH traversal before leaf nodes. To get shading information with approximated geometry we define stochastic material sampling.

As you can see from the images below, the number of nodes traversed drops substantially with approximation. Though our technique does introduce a small darkening bias it is very well balanced by all the other benefits that we get from it.

Exact
Bistro A, rendering images and visualizations of a number of nodes traversed in the AO ray cast using our method. Exact.
Approximation: T = 10 degrees
Approximation: T = 10 degrees
Approximation: T = 20 degrees
Approximation: T = 20 degrees

The heat map represents the number of nodes each AO ray traverses to find intersections. Blue (min) is 0 and red (max) is 400. The average number of nodes each AO ray traverses in pixels with approximation drops to 317, 240, and 218 respectively.       

I hope you have enjoyed the “Why” behind this technique. For details on performance and the technique, I highly encourage you to give the paper a read.                                                                                               

Looking for more?

We have lots of technical documentation here on GPUOpen, including dozens of published papers on our “Publications” page. Make sure you take a look before you leave!

AMD GPUOpen publications

Discover our published publications.

AMD GPUOpen documentation

Explore our huge collection of detailed tutorials, sample code, presentations, and documentation to find answers to your graphics development questions.

GPUOpen Manuals

Don’t miss our manual documentation! And if slide decks are what you’re after, you’ll find 100+ of our finest presentations here.

Picture of Paritosh Kulkarni

Paritosh Kulkarni

Paritosh Kulkarni is a researcher and developer working on a GPU global illumination renderer called Radeon ProRender at AMD.

Picture of Sho Ikeda

Sho Ikeda

Sho Ikeda is a researcher and developer working on a GPU global illumination renderer called Radeon ProRender at AMD.