For those who don’t know the tool: VDBRender is a volumetric renderer node that runs inside Nuke, turning OpenVDB caches into comp ready passes without leaving the script. It sits next to the existing FieldVolume import node and plays nicely with typical studio volume workflows.
Volumes, without the round trip
Volumetric shots tend to follow a familiar pattern. You simulate smoke, fire, dust, or clouds, you render them in a dedicated renderer, then you haul a stack of passes into comp and try to keep everything lined up while the shot keeps changing. That pipeline works, but it comes with the usual tax: iteration time, extra caching, and a steady stream of tiny alignment mistakes that only show up when you are already late.
VDBRender targets that pain directly by letting you render OpenVDB volumes natively inside Nuke. The workflow is intentionally minimal: load a VDB file, connect a camera, choose a preset, render. The goal is to keep the whole volumetric lookdev loop inside the compositor, so you can make changes where the final image actually lives.
The tool is positioned as a production-oriented answer to a gap in Nuke itself. Nuke includes a FieldVolume node that can load an OpenVDB volume file, but that node is tagged as a LABS node and LABS nodes are experimental and not yet intended for production.
What it renders and what it outputs
VDBRender (by Marty Blumen) is built around ray marching OpenVDB data. It supports grids for density, temperature, flame, velocity, and colour, with auto detection for naming. It also supports handling of sequences for numbered VDB files. The effect is practical: you can drop in a cache, let the node find the relevant grids, and get moving without hand wiring every attribute.
Presets are a major part of the speed story. There are nine scene presets described, covering smoke, fog and mist, clouds, fire, explosions, dust, and steam. The presets get you to a plausible baseline quickly, then you can refine from there.
Lighting is included rather than outsourced. The tool includes a three point lighting rig and also a sun and sky system. It also includes studio lighting presets. In version 3, environment lighting is present via spherical harmonics based environment lighting, and HDRI support is described as projecting to L2 spherical harmonics at load time.
On the output side, the headline features are deep output and AOVs. Deep output is supported, aimed at volumetric compositing workflows that need depth aware merges with other elements. AOVs include Density, Emission, Shadow, and Depth. Version 3 adds per light AOVs that separate RGB contribution for up to four lights, identified as vdb_light0 through vdb_light3. That kind of separation matters when comp wants to relight a volume without re-rendering it, or when the shot needs a last minute change that should not ripple back into a full 3D rerender.
Motion blur is supported via velocity, described as velocity motion blur and motion blur via velocity grid. That keeps the tool aligned with how a lot of volume sims already store motion information.
If you are the kind of compositor who likes a few different diagnostic views before committing to a look, there are multiple render modes listed, including lit, greyscale, heat, cool, blackbody, gradient, and explosion.
Version 3 changes that matter in comp land
Version 3 is not framed as a cosmetic refresh. Several concrete additions and performance oriented changes are described. Per light AOVs have already been mentioned, and they are easy to justify. They let you keep a stable master render while still giving comp a lever for balancing key, fill, rim, and practical contributions. In a shot with interactive firelight or heavy haze, that can be the difference between a clean tweak and a new render request.
Environment lighting performance is also addressed. HDRI environment maps are handled with L2 spherical harmonics, and runtime evaluation is described as dropping to fewer directions. There is also mention of extracting bright peaks from the environment map as virtual directional lights that cast self shadows.
Shadow performance gets explicit attention. HDDA empty space skipping on shadow rays is always active. There is also an optional precomputed transmittance cache described, reducing shadow cost from O steps to O 1 per sample, with an indicated speedup range of five to ten times on directional lights when enabled.
A point cloud rendering path is present through PointDataGrid support, with per particle colour, configurable radius, and light integration, composited over the volume in a single pass.
Dual VDB layers are supported, blending a second density grid on top of the primary, with an example use case of layering dust over fire or combining sim passes.
There are also shading related additions listed in the version 3 notes, including a dual lobe Henyey Greenstein phase function, a powder effect, analytical multiple scattering, approximate Mie phase, chromatic extinction, ray jitter, and procedural fBm detail noise. Those features are described as part of the tool’s shading controls, with the Cumulus Cloud preset enabling gradient normal blending by default.
Compatibility, requirements, and the boring bits you actually need
VDB Render 3.0 is compatible with Nuke 17.0 and later on Windows. It is not tested on Linux or macOS.
The project README lists requirements as Nuke 17.0v1 or later, Windows x64, and OpenVDB via vcpkg for building from source. If you are using compiled binaries, the focus shifts from build requirements to runtime placement and plugin discovery.
Installation is copying the VDBRender_v3 folder into a .nuke plugins folder, renaming it to VDBRender, then adding a pluginAddPath line in the user init.py to point at the nuke17 folder, followed by restarting Nuke so it appears in the VDB menu.
On the data side, OpenVDB version support is called out as OpenVDB 12 currently supported, with OpenVDB 13 support planned in line with the CY2026 VFX Reference Platform, which lists OpenVDB 13.x for CY2026.
Nuke’s FieldVolume import node remains relevant in this story. It loads OpenVDB volume files and allows choosing which grid to sample, with a field type depending on the grid type, described as signed distance for level set grids or density otherwise. But again, it is a LABS node and is explicitly described as experimental and not intended for production use.
Licensing and price, aka the part Legal will ask about
VDBRender is a free download. Source code is available under the MIT license.
Why this is interesting right now
If your studio already renders volumes elsewhere, this can still be useful as an iteration layer. You can block in a volumetric look directly in comp, validate framing and timing, and decide what needs to be promoted back into a heavier render step. If your work is motion graphics or smaller VFX tasks, you may be able to keep more of the job inside one script, especially when the goal is a comp driven final rather than a fully path traced volumetric hero render.
As VFX software stacks converge on shared library baselines, alignment with reference platforms becomes more than trivia. OpenVDB 13.x is listed for CY2026, while the tool currently supports OpenVDB 12 with OpenVDB 13 support planned. That puts version transitions on the near horizon for facilities that track those targets.
https://www.nukepedia.com/tools/plugins/3d/vdb-render-v3/
https://github.com/bratgot/VDBmarcher
