SIGGRAPH 2026 Talk- A Hybrid BVH Structure for Interactive GPU Ray Tracing
At SIGGRAPH 2026, my teammate Andrew Bauer and I have a talk about the hybrid BVH structure we use in Disney Animation’s in-house real-time GPU ray tracing previsualization renderer1. Our hybrid BVH structure is specifically designed around optimizing for 24 fps or better animation playback in large, complex production scenes. I think the cool thing about this talk is that it’s not really about some kind of revolutionary magic new technique, but instead is about closely analyzing a specific problem domain and exploiting properties of the problem domain to accomplish otherwise difficult things.
Andrew is presenting the talk at SIGGRAPH 2026 in Los Angeles as part of the “Rendering and Volumes” session on Thursday, July 23rd.
Here is the paper abstract:
Choosing a bounding volume hierarchy (BVH) structure for accelerating ray tracing applications typically involves trading off between BVH build/update speed and BVH traversal speed. Two-level BVHs offer faster build/update speeds but lower traversal performance and can still have degraded build speed in pathological cases common to production scenes, while monolithic single-level BVHs provide ideal traversal performance but suffer from slower worst-case build speeds. We introduce a hybrid approach that combines the strengths of both while minimizing their downsides. Our system places instanced objects into a two-level BVH, while non-instanced objects are partitioned into three separate monolithic sub-BVHs based on specific change categories. This allows us to optimally determine when to use reuse, refit, or rebuild operations for maximum update efficiency. Our approach supports high-performance, interactive GPU ray tracing of complex production scenes, maintaining fluid updates even during real-time animation playback or active geometry editing by an artist.
The paper and related materials can be found at:
As always, this blog post is a loose collection of some personal thoughts on this project. All of the actually useful technical information is in the paper and presentation. One thing that is worth noting is that the results and demo video provided with the talk were generated using an older NVIDIA RTX 6000 Ada GPU, and not using the latest Blackwell card. This was intentional; the results and demo show that our system already works great on Ada, but as you might imagine, it works even better on Blackwell.
In my post about our GPU Ptex talk last year, I wrote about the importance of building a first system to throw away in order to learn the lessons necessary to build a second, better version. Well, this project is the result of something more like building three or four previous versions to throw away before finally building the real version that actually works. That is to say, the approach presented in this talk wasn’t so much a singular brilliant idea that we had one day as it was something we arrived at through years of experimentation, trying a bunch of different ideas, and eventually converging on something that worked for our use case.
Mark Lee and I both developed multiple previous versions of the BVH construction system used in our interactive GPU ray tracer before Andrew came up with the version presented in this talk; each successive version was pretty radically different from its immediate predecessor in an attempt to address the shortcomings we found in the previous version. Going through all of that history is a topic better left for another day, but the system in this paper is probably the most radical shift from a predecessor in the entire development history, and that’s saying something given how much the system changed from version to version. That being said though, just because this version is very different from its predecessors doesn’t mean it doesn’t incorporate any lessons or ideas from its predecessors; in fact, it’s the way it is precisely because of what we learned from previous versions. Sometimes the path to a good solution is through a single great idea, and sometimes it is simply through brute force trial and error and iterative progress.
A valid question about this talk is: why publish yet another talk about BVHs when there are already a zillion BVH related talks and papers out there? After all, researchers and engineers have been publishing about BVH construction and BVH traversal and such for decades now; there used to be an entire Interactive Ray Tracing conference on the topic in the mid-2000s, which eventually merged with another Graphics Hardware conference to create the modern High Performance Graphics conference. By the mid-2000s an enormous volume of research had been conducted on building BVHs suitable for interactive ray tracing [Wald et al. 2007], and the problem even to this day remains an active topic of research [Meister et al. 2021]. At the same time though, with the advent of hardware accelerated ray tracing on the GPU and just generally much faster computers, fast interactive ray tracing is already widely used in games [Netzel and Costa 2022, Knapik et al. 2024] and interactive authoring contexts [Llamas 2021, Vulchev 2025]. So how can fast, interactive-speed BVH structure and traversal simultaneously be a still-open research topic and something that is already actively used in production? I think the answer is simply that there is no such thing as a single, one-size-fits-all solution to BVH structure and traversal; the best approach for any given use case is going to vary based on the specific details of that use case.
Essentially when thinking about BVH structure and traversal, there’s a fundamental tradeoff at play: BVH construction speed versus BVH quality (which by extension means BVH traversal speed). Building a BVH quickly is an obvious requirement for fast interactive updates, but fast BVH construction approaches always require sacrificing BVH topology quality in some way, which in turn makes traversal speed slower. Conversely, the highest quality imaginable BVHs typically require expensive, slow construction methods. There’s a large number of degrees of freedom from which one can choose when designing a BVH layout, which means that the continuum between optimizing for fast builds and optimizing for fast traversal is an absolutely vast design space. This is why fast BVHs are still such an active research space but also something that is actively in use in the real world: just because someone has come up with a workable solution for their specific use case does not mean that solution generalizes to any other use cases. I think some of the most interesting recent publications I’ve seen about fast ray tracing are all about understanding a specific use case really well and finding a way to take advantage of known assumptions in that use case to optimize within the BVH design space [Koshlo 2024]. This is also why libraries such as OptiX [Parker et al. 2010] are not really designed as a singular one-size-fits-all system and instead are designed more as BVH toolkits that afford programs an enormous amount of control in deciding how to structure BVH topology and consequently how BVHs are built.
The answer to why publish this talk is therefore simply: we optimized our approach heavily around assumptions within our specific use case, and thought that the set of choices we were able to make given what we know about our use case represented an interesting point in the overall possible design space. Our interactive ray tracing previz renderer is currently used primarily for what we call “foundation lighting”, which is a sort of rough blocking lighting pass that is carried out at the same time as layout and early animation, and well ahead of detailed set dressing, simulation, and effects work. Because of where our tool is used in our production pipeline, we knew that supporting 24 fps playback of animated characters would be crucial, but things like an entire detailed forest with wind blowing around every single tree [van Antwerpen et al. 2026] wouldn’t be as common of a case. Knowing that most of our scene will be static allows for a more streamlined approach than something like Gruen et al. [2026], which instead is optimized for the worst-case scenario of absolutely everything being animated.
Anyhow, just as our approach has evolved a lot already as we came to understand our use case more clearly, I’m sure that our approach will continue to evolve as the project evolves. Maybe if things change again to something else interesting, we’ll publish that too at some point!
References
Dirk Gerrit van Antwerpen, Pascal Gautron, Edd Biddulph, Christoph Kubisch, Jan Schmid, and Martin Stich. 2026. Real-time Path Tracing of Massive Dynamic Foliage. Proc. of the ACM on Computer Graphics and Interactive Techniques (Proc. of High Performance Graphics) 9, 4 (Jul. 2026), Article 51.
Holger Gruen, Carsten Benthin, Michael Kern, and David McAllister. 2026. Ray Tracing Massive Amounts of Animated Geometry. Proc. of the ACM on Computer Graphics and Interactive Techniques (Proc. of High Performance Graphics) 9, 4 (Jul. 2026), Article 49.
Jakub Knapik, Michael Murphy, and Pawel Kozlowski. 2024. Ray-Tracing: Overdrive in ‘Cyberpunk 2077’ Ultimate Edition: Pushing Path Tracing One Step Further. In GDC 2024: Game Developers Conference 2024.
Oleksandr Koshlo. 2024. Ray Tracing in Snowdrop: Scene Representation and Custom BVH. In GDC 2024: Game Developers Conference 2024.
Ignacio Llamas. 2021. The Omniverse RTX Renderer. In GTC 2021: GPU Technology Conference 2021.
Daniel Meister, Shinji Ogaki, Carsten Benthin, Michael J. Doyle, Michael Guthe, and Jiri Bittner. 2021. A Survey on Bounding Volume Hierarchies for Ray Tracing. Computer Graphics Forum (Proc. of Eurographics) 40, 2 (May 2021), 683–712.
Aleksander Netzel and Tiago Costa. 2022. Ray Tracing Open Worlds in Unreal Engine 5. In ACM SIGGRAPH 2022 Course Notes: Advances in Real-Time Rendering in Games: Part 1.
Steven G. Parker, James Bigler, Andreas Dietrich, Heiko Friedrich, Jared Hoberock, David Luebke, David McAllister, Morgan McGuire, Keith Morley, Austin Robison, and Martin Stich. 2010. OptiX: A General Purpose Ray Tracing Engine. ACM Transactions on Graphics (Proc. of SIGGRAPH) 29, 4 (Jul. 2010), Article 66.
Vladislav Vulchev. 2025. The Path to Real Time Path Tracing. In GPC 2025: Graphics Programming Conference 2025.
Ingo Wald, William R. Mark, Johannes Günther, Solomon Boulos, Thiago Ize, Warren Hunt, Steven G. Parker, and Peter Shirley. 2007. State of the Art in Ray Tracing Animated Scenes. In Proc. of Eurographics 2007: State of the Art Reports. 89-116.
Footnotes
1Our previz renderer does have an actual name other than the long and awkward “Disney Animation’s in-house real-time GPU ray tracing previsualization renderer”. which hopefully we will be able to share sometime soon. But until then, “Disney Animation’s in-house real-time GPU ray tracing previsualization renderer” is what shall be publicly. keyboard_return