Page MenuHome

Incorrect volume rendering when enabling NanoVDB.
Confirmed, NormalPublic

Description

System Information
Operating system: Linux-5.9.14-arch1-1-x86_64-with-arch 64 Bits
Graphics card: AMD Radeon RX 5700 (NAVI10, DRM 3.39.0, 5.9.14-arch1-1, LLVM 11.0.0) AMD 4.6 (Core Profile) Mesa 20.3.1

Blender Version
Broken: version: 2.92.0 Beta

Short description of error
Cycles renders voxels differently when enabling NanoVDB. Note that I'm only rendering on the CPU.

Without NanoVDB:

With NanoVDB:

The behavior is also slightly inconsistent with Eevee, but that is a separate issue (which is solved by D10295). This report only focusses on the difference within Cycles with and without NanoVDB.

Exact steps for others to reproduce the error

  1. Delete everything from the default scene.
  2. Load .vdb file below (it contains a single voxel at the origin).
  3. Change render engine to cycles and switch to rendered mode.
  4. Compare behavior with and without WITH_NANOVDB.

Further Notes
The voxel size itself is not larger than without NanoVDB. Only the behavior at borders between dense and empty voxels is different.

Event Timeline

This is happening because lookup into the NanoVDB data structure is not clamped, whereas dense texture lookups are (see EXTENSION_CLIP, which is the default for images, including volumes). And since either linear or cubic interpolation is always enabled (you can't enable closest interpolation in Cycles ... which is rather odd and should probably be addressed at some point too), you get an interpolated result in the neighboring voxels. So I actually think the current behavior with NanoVDB is more correct?.

The matter of part of one of the edges missing is happening because the volume mesh generated around the volume seems to have a cutout there for some reason, so no hits are reported for rays shot in that region and therefore no volume lookup happens at all.

Philipp Oeser (lichtwerk) changed the task status from Needs Triage to Confirmed.Thu, Feb 18, 2:36 PM