A leaner, yet still powerful version of OpenVDB is coming your way and its name is NanoVDB.
NanoVDB uses a linearised, read-only representation of the VDB tree structure, streamlining the rendering process on GPU, and saving you time and memory when rendering volumes.
To celebrate our collaboration with NVIDIA, we had a chat with the one and only Ken Museth, Senior Director in Simulation Technology and Lead Architect of OpenVDB, and Arnold Development Manager, Frederic Servant, to hear about the incredible collaboration behind NanoVDB in Arnold.
HOW IT BEGAN
Before solving the industries’ great volume problems, Ken started out his career as a researcher professor at Caltech and Linköping University. He soon made the switch to Computer Science and started working with Ph.D. students on compact data structures, level sets, and volumes. This led to him working in the film industry where he used his talent and experience to solve problems using compact data structures. At DreamWorks, Ken contributed the compact data structure of VDB (others contributed to the toolsets), which eventually became known as OpenVDB. OpenVDB, now adopted by the Academy Software Foundation and the Linux Foundation (where Ken is still a chair member), is an Academy Award-winning open-source software library for working with sparse volumetric data.
In early 2020, Ken joined NVIDIA and started to bring NanoVDB to life.
“We've been looking for a solution for volumes on GPU. The dense grid implementation was there to have something running, but of course, it consumed a lot of memory and was slower,” Frederic Servant explains. “We had some discussions with NVIDIA to figure out if we needed to roll out something of our own, or if there was a possibility for a collaboration. As soon as we talked about it, NVIDIA mentioned that there were several projects that addressed this. We were so excited to meet Ken and to collaborate with him because he is the master of volumes.”
“Things went very quickly,” Ken adds. “We were able to iterate and get your prototype implementation tested out. Jamie Portsmouth, Principal Software Engineer on Arnold, had several ideas that ended up in Nano. Many feature requests that weren’t there were added. [The collaboration] was very productive.”
SO, WHAT IS NANOVDB?
“NanoVDB is a core data structure that's been rewritten to work well on a GPU and a toolset that specifically caters to rendering,” Ken explains. “OpenVDB, today, is an industry-standard. It's adopted by many DCCs, but when it comes to rendering, there was nothing we had that supported the GPU workflow, and that's where Nano comes in. You can take an OpenVDB file and convert it to an NanoVDB and it's relatively fast, then you can copy it to the GPU, and you can do your thing.”
Same powerful core data structure, less rendering time. NanoVDB essentially provides a simplified representation that is completely compatible with the core data structure of OpenVDB, with the ability to switch back-and-forth between the NanoVDB and OpenVDB data structures and create and visualize the data.
WHAT DOES THIS MEAN FOR ARNOLD USERS?
With NanoVDB now implemented in Arnold, you can render clouds, smoke, or any complex special effect with the same sparse memory footprint as on CPU.
Compared to our previous dense grid approach, NanoVDB reduces the memory usage for volumes by a factor of more than 6, and renders 40% faster due to empty space skipping, making it well-suited for GPU.
“It’s lightweight, suitable for GPU, and more efficient,” Frederic adds. “Everybody is going to benefit where volumes are being rendered”.
Get ready to render your volumes faster than ever by updating to Arnold 6.2.1. If you haven’t subscribed yet, give Arnold a try with a free 30-day trial.
Read the full release notes for the Arnold 6.2.1 performance update here.
Want the juicy details on NanoVDB? Learn more about Ken Museth and his work at NVIDIA.