Advanced Volume Support in Geometry Nodes

Make volumes in geometry nodes more useful and flexible.

• Incorporate feedback from Jacques, Hans, Dalai
• Separate out examples and steps that require work beyond the MVP: Fluid and hair sim need a few specialized nodes.
• Better illustration for "individual grids in volumes" vs. Volume geometry component. left->right train of thought, "there are multiple grids in the volume, but only one volume output"
• Change node design for mesh/point conversion to include volume input+output (discussed in chat)
• Describe meaning of position node in volume context
• Picture comparing different mesh/point conversion resolution modes (Size, Amount, Copy)
• Design a new grid resolution option to facilitate shared transforms between grids.

Motivation: Use Cases for Volumes

(Generated using mermaid.live)

Volumes have properties that make it a unique tool in the box:

• Spatial lookups are fast, great for processing lots of data.
• Finding neighboring cells is very cheap, allows fast filtering and convolution.
• Store sparse volumes efficiently.
• Improved accuracy for positions using cell coordinates.

In short: Volumes can do many things faster than other geometry, and some things that are (almost) impossible otherwise.

Some improvements to expect:

• Faster simulations without loss of visual detail.
• Describe semi-transparent media efficiently.
• Costly SDF functions can be computed in real time.
• Smoothing/blurring/diffusion is faster and resolution-independent.

Examples

• Construct mesh surface from a SDF volume

  • Create SDF grid from point cloud
  • Convert to mesh surface
  • Output

• Remove density from a fog volume

  • Geometry input containing fog grid
  • Named Attribute node for "density" grid
  • Vector math distance node using a utility object location and grid cell position
  • Map distance to some 0..1 range
  • Math node multiplying density with the distance factor
  • Store Named Attribute using modified density and store as "new_density"
    

• Combining and rendering SDF operations
  Make holes in cheese:

  • Cheese wheel mesh
  • Mesh to SDF Volume
  • Erode SDF, then distribute points in volume (so bubbles don't poke through the surface)
  • Points to SDF Volume
  • Difference of mesh SDF and points SDF
  • Volume to Mesh makes a cheese with holes

  Links:

  • SDF surface rendering in a shader. Shows boolean combination functions. https://www.shadertoy.com/view/lt3BW2
  • Detailed tutorial with a 2D case. https://www.ronja-tutorials.com/post/034-2d-sdf-basics/#rectangle
  • Mesh-Mesh booleans using SDF. http://www.gradientspace.com/tutorials/2017/11/21/signed-distance-fields-tutorial

• Basic FLIP fluids (with point cloud sampling)

  • Particle dynamics: add gravity to velocity attribute
  • Velocity grid from particles (new node?)
  • Divergence grid from velocity (new node)
  • Pressure solve outputs scalar pressure grid
  • New velocity from pressure gradient
  • Apply velocity by sampling at particle locations

  Links:

  • 10 Minute Physics: How to write a FLIP Water Simulator https://youtu.be/XmzBREkK8kY

• Hair self-collision using volumes
  Links:

  • Anisotropic Elastoplasticity for Cloth, Knit and Hair Frictional Contact https://dl.acm.org/doi/pdf/10.1145/3072959.3073623
  • Volumetric Methods for Simulation and Rendering of Hair https://graphics.pixar.com/library/Hair/paper.pdf

Volumes in Blender 4.0

Geometry Nodes currently has only very basic volume support for conversions to and from other geometry. With the experimental "New Volume Nodes" enabled there are a few more nodes for sampling and SDF manipulation.

Volumes are treated largely as "black boxes":

• Converting meshes or point clouds to volumes
• Generating a mesh surface from a density grid
• Scattering points in a density grid
• Sampling a grid at arbitrary points
• Basic SDF operations (offset, filter)
• Volume "primitives": sphere, cube with variable density

Volumes can already store multiple distinct grids, e.g. when loading from .vdb files. These are not accessible individually, nodes have to use the "active" grid index and special names to find which grids to operate on.

Combining grids is not supported currently. This would be a frequent occurrence e.g. in SDF modeling. Without access to individual grids it's not obvious which grids should be combined.

Some interaction with grids is possible using sampling and conversion to other geometry, but it's not very efficient. Many useful features of grids can't be utilized this way, e.g. spatial lookups of neighboring points.

Improved Grid Data Access

Attribute Support

Volume geometry gets attribute support. Each attribute represents a named or anonymous grid in the volume.

The Voxel domain represents grid cells, which are the main elements of grids.

MVP

Goal is to provide necessary features to unlock volume geometry access. Later tools and simulations can build on top of this initial stage.

Conversion Node Outputs

Conversion from mesh and point geometry will output a density grid (fog volume) or distance grid (SDF volume) in addition to the Volume geometry. This is an anonymous attribute of the volume, rather than a named attribute as is currently the case.

Grid Info Node

A new Grid Info node provides additional information about a grid:

• Scale: Size of each voxel in object space.
• Origin: Translation of the grid voxels relative to object origin.
• Staggered: For vector grids only: The grid values are split by component and located on face centers (typically used for velocity grids).

Domain Size

The Domain Size node in Voxel domain mode returns the number of active voxels of the grid.

Transform Geometry for Grids

The Transform node for grids simply changes the voxel scale and origin. The actual grid data is local to grid cells, there is no position attribute that needs to be calculated.

Resample Grid

Change the voxel scale or origin and generate a new grid by interpolating the old grid values. This generally comes with a loss of precision and potential aliasing artifacts, same as when resampling images. Higher-order sampling methods can be used to reduce some of these artifacts.

Sample Volume

Sample Volume already has a "Grid" input, but this is a hack: it expects an arbitrary named field and then uses the same name to find a volume grid internally. This will no longer be necessary, the input itself becomes a grid field that can be sampled directly.

Sample Grid

This is a variation of the Sample Index node. The usual element index of points, faces, edges, etc. does not work well with grids, since voxel indices depend very much on grid topology. Instead a grid is typically indexed using coordinates (i,j,k). Unlike the Sample Volume node

The Sample Volume node is one way of reading grid data, but its position input includes the grid transform. A new "Evaluate at Coordinate" node provides direct access based on integer coordinates, ignoring the grid scale.

Field Evaluation

Field evaluation with grid inputs produces grid outputs, which can be stored or captured. Multifunctions, like math or color mixing, work on voxel values. Each output voxel value is computed by evaluating inputs at the voxel location.

Implementation Note: When input grids in a field graph have different transforms the evaluator needs to resample the grids, which causes artificial smoothing and reduces performance. Using the same grid transform is preferable because node graphs can be evaluated per leaf buffer as simple multifunctions.

Voxel Size and Grid Transforms

Each volume grid has a transform which determines the size of voxels. For example a grid with a scale of 0.25 has a voxel size of 0.25 units. A volume component has a default transform, which is the transform of the active grid.

Nodes that construct a grid from a mesh, point cloud, cube or sphere all have one or both of the following options:

• Size: Voxels have fixed size, amount of voxels computed to cover the extent of the geometry.
• Amount: Fixed amount of voxels on the longest axis (or all 3 axes for the cube), voxel size is based on geometry bounds.

A Volume Info node will provide the transform of an existing volume so it can be copied by other nodes. Using consistent transforms between grids improves performance and avoid loss of precision due to interpolation. It should be the preferred option when creating new grids to reuse an existing transform.

Grid Topology Behavior

For conventional fields in geometry nodes the size of buffers is directly defined by the domain, with the possible use of selection as a filter.

For grids the situation is more complicated: Each grid has, by design, its own extent and topology (which voxels are active). When combining multiple grids in a function, say an "Add" math node, the result will usually be a union of the active grid cells. The input grids have a background value that is used when a voxel is inactive.

Some special cases need to be considered:

Empty Input Case: Some field inputs are not grids themselves but abstract functions, like the "Voxel Center" input. These fields do not have a concrete set of voxels. When all input fields are abstract the resulting grid would be empty. A fallback for this case could be to use the "active grid" topology, or provide a user-defined default grid.

---

Future Steps

Not part of the MVP

Spreadsheet Integration

The spreadsheet shows grid attributes for debugging purposes. Each colume contains values in a grid. Each row contains attributes for the same voxel, identified by its grid coordinates (i,j,k).

Unlike existing geometry components the Volume attributes are grids, which can have different topology and voxel count. A voxel may be active in some grids but not others, so a spreadsheet row can have gaps when the voxel it represents is not active in the column for a grid.

Implementation Note: The index of a voxel depends on the overall voxel count, it should not be stored or used for sampling.

Volume Viewer Nodes

Viewport display for volumes is not very useful for viewer nodes at this point. The viewport can only display float value grids as a density-style fog volume.

Viewport rendering of volume should take more grid types into account, as well as other settings such as the staggered grid class for vector grids.

Additional techniques for visualizing useful grid information:

• Wireframe cell display: useful for gauging voxel size and how it relates to other scene elements.
• Slices: Clear picture of interior grid values. There is a feature on volume objects, but its very limited. Where to put a slice exactly requires user control.

Point Grids

OpenVDB has a specialized grid type for storing large point clouds efficiently and with better accuracy than the current Point Cloud geometry (OpenVDB overview). This PointDataGrid forms the basis of fluid simulations.

• PointCloud gets an internal grid representation.
• Can switch between both point cloud representations automatically, e.g. a simulation can convert an input point cloud to grid mode.
• Point cloud attributes can read/write directly to the PointDataGrid.
• New set of nodes to enable fluid simulations:
  • Divergence and Gradient operators
  • Pressure solver for incompressible fluids (Poisson solver)
  • Point advection with a velocity vector grid
  • Obstacle grids generated from meshes or other sources (including manual authoring)