Status: Implementation started, it includes other data types (hair, points) to be hidden from UI.

Team

Commissioner: ?
Project leader: @Brecht Van Lommel (brecht)
Project members: @Sebastián Barschkis (sebbas) @Jacques Lucke (JacquesLucke)

Description

Big picture: Volumes need their own native datablock type, so Blender can support other use cases like rendering OpenVDB files or procedurally generating volumes.

Use cases:

• Existing use cases (smoke modifier on mesh).
• OpenVDB file rendering.
• Procedurally generating volumes (part of everything nodes).

Design:

• New Volume datablock (similar to Mesh) with an OpenVDB volume data structure with an arbitrary number of attributes.
• Rendered by Cycles and Eevee, first as dense volume as we have now, and later with native sparse volume rendering.
• Volume objects would have modifiers (add resolution detail, fluid domain modifier, ...)

Engineer plan: ?

Work plan

Milestone 1
Time estimate: 10 workdays to complete implementation, 5 for review/docs/bugs.

• New volume object data type, based on OpenVDB grids
  • Support reading OpenVDB files from disk
  • Add New material adds principled volume material
  • Solve problem with not enough FILTER_ID bits
• Rendering of dense grids
  • Cycles
    • Basic integration
    • Use principle volume as default material if no material exists
    • Support different transform per grid
  • Eevee
    • Basic integration
    • Use principle volume as default material if no material exists
    • Support rotation/shear in transform
    • Shader code generation for arbitrary number of grids
    • Support different transform per grid
  • Workbench
    • Basic integration
    • Control over which grids to display (active grid only by default?)
    • Use workbench object color settings
    • Density scale setting
  • Check why example VDB grid files have such low density
• Viewport drawing and selection of volume bounds
  • Wireframe bounds display of tree nodes (at intermediate or leaf levels)
  • Selection support (based on wireframe bounds?)
• User interface
  • Open file browser immediately from Add menu
  • VDB / volume file type in the file browser
  • Drag & drop VDB files into 3D viewport
  • Finalize properties editor UI layout
• Python API
  • Grids
  • Transforms
• File loading
  • Error reporting
  • On-demand loading
  • Global cache
• Dependency graph copy-on-write integration
  • Refactor mesh runtime storage to be reusable by other objects types
  • Automatic instancing for objects without modifiers, like meshes
  • Fix runtime backup memory leak
• Volume frame sequences
  • Settings to use single volume or sequence, start, length, offset
  • Dependency graph integration
  • Auto detection of sequences when loading file
• Mantaflow: output OpenVDB files with multiple grids and standard grid names
• Optimizations
  • Share GPU textures in global volume cache
  • Preserve GPU batch cache through display setting changes
  • Cycles: optimize mesh bounds creation by using OpenVDB tree
  • Cycles: optimize voxel loading by using OpenVDB tree
  • Cycles: share 3D images like global volume cache

Milestone 2
Time estimate: ?

• Volume modifier stack
• Fluid domain modifier, deprecate modifier for meshes
• Cycles sparse grid rendering
• File packing
• VDB tree/voxels API using pyopenvdb?
• Workbench: additional viewport display options
• Grid metadata: show in properties editor

Later

• Volume modifier nodes
• Eevee sparse grid rendering
• Volume edit mode and file saving
• OpenVDB level sets, clusters, perspective transform

Branch: new-object-types

Relevant links:

• OpenVDB Official Site
• New Object Types design document
• Code Documentation

Details

• The initial implementation will only read OpenVDB grids from disk, the fluid simulator or procedurally generate volumes. As a result, there is no need for file saving of volumes (assuming we don't allow operations like apply modifier). When the need for it arises, it seems most practical to treat it similar to images. That is, .vdb files are typically separate files on disk to keep the .blend file size manageable, but packing can be supported.

• For meshes, hair and pointclouds we can the same custom data layer system for attributes. However since volume are stored in OpenVDB data structures, it's not possible. We could add custom data layer data structures that mirror OpenVDB grids, but keeping these in sync seems error prone. So, the plan is to provide RNA APIs and user interface that is consistent, but with different underlying implementation based on OpenVDB grids.

• Volume files are typically very heavy, and need to be loaded on demand similar to images, with proper thread safety and garbage collection. We should also load just the part of the OpenVDB file that is needed for specific purposes.
  • Read list of attributes (for display in the UI)
  • Read tree structure (for fast preview in the viewport)
  • Read voxels (for full drawing and rendering)

• For the copy-on-write dependency graph, we need to clearly design how data is referenced between copies when on-demand loading happens. We can't afford to have the same volume grids loaded multiple times. For images this is handled by not having image datablocks part of copy-on-write at all, but for volume modifiers we need it.