Volumetric data is one of the core geometry types next to meshes, point clouds and curves. While there are already many ways to process the last three, the Geometry Nodes feature set for using volumes was very limited and mainly involved converting between volumes and other types; actually editing volumetric data was not really possible.
Changes coming to volume support in Blender 5.0 open up many new opportunities including fluid simulations, SDF modeling, and visualizing scientific volumetric data.
Volume Grid
At the core of this update is the new volume grid data type, corresponding to volumetric data with a specific data-type, be it floats, vectors, or another primitive type. Nodes that work on grids explicitly use the new grid socket shape. The color of the socket indicates what kind of grid it is. A common use-case is to use a float grid to store density values.
The values stored in grids can also be modified with standard math nodes. When two grids are added together, the output is a new grid where each voxel is the sum of the corresponding input voxels. This requires the grids to have the same transform, more on that below.
Unlike attributes on other geometry types, grids can live entirely separate from geometry sockets. That said, a geometry socket can store an arbitrary number of named grids. Common grid names are density and temperature. Typically, one has to insert the computed grid into a geometry in the end which allows giving it a name and material, but the viewer node allows viewing the grid directly without putting it into a geometry first.
Grid Data Structure
Volumetric data is typically very computationally heavy. That’s because of the large number of individual voxel values that need to be stored for even somewhat detailed grids. For example, a 100x100x100 grid already has 1,000,000 voxels. An efficient way to store and process this data is required.
To store volume data, we use the industry standard OpenVDB library. Its core contribution is a data-structure to efficiently store dense and sparse volume grids as groups of voxels. Each voxel is indexed by a 3D integer coordinate. For example, the coordinate (0, 0, 0) is the center voxel, and (1, 0, 0) is the voxel to its right.
Additionally, each volume grid has a transform (location, rotation and scale) which maps the index-space to object-space. For example, if the grid has a scale of 0.1, each voxel is 0.1 units large in each direction and the voxel (5, 0, 0) corresponds to the object space position (0.5, 0, 0). The grid transform can be set with the Set Grid Transform node and can be retrieved with the Grid Info node.
The grid is essentially space-filling, so it can be sampled at arbitrary positions. However, obviously it’s not practically possible to actually store a value for every voxel individually as that would require far too much memory. OpenVDB uses two tricks to store the data more efficiently, which can’t be entirely hidden from users without major performance costs.
- Tiles: Blocks of e.g. 8x8x8 voxels form a small tile. When all of the values in that tile are the same, it is only stored once for the entire tile instead of for each 512 voxels individually. There are also less common higher-level tiles. For example, 16x16x16 small tiles can form a larger tile. Converting between voxels and tiles is possible with the Prune Grid and Voxelize Grid nodes.
- Active Status: Each voxel and tile has an active status. If it is active, it stores a value itself. If it is inactive, it uses the grid’s background value, which can be set using the Set Grid Background node. Most operations just ignore inactive voxels.
The topology of a grid is a combination of the tiling and active-status. Most operations just preserve the topology of the input grid. If there are multiple input grids, like when adding two grids, their topologies are generally merged. Some nodes have a separate Topology input which determines which voxels and tiles to operate on. Some stats of the topology can be seen in the spreadsheet.
Also see the original OpenVDB paper and the OpenVDB Overview for more details of the internal structure.
Integration with Fields
Critically, a field is not a grid and vice versa. A noise field, for example, is a function that can be evaluated to compute the noise value at arbitrary positions, but a grid can’t be evaluated, as it is just a data container. However, grids can store the result of a field evaluation in each voxel.
Converting Fields to Grids
A good way to do this is to use the Field to Grid node. It evaluates the input field for each voxel and tile and stores the results in a new grid.
Another approach is to just use a math node. When it has at least one grid input, each field input will internally be evaluated based on the topology of the grids.
There are two main field input nodes that can be used when creating a field that is evaluated in the context of a voxel: the standard Position node, and the new Voxel Index node.
Sampling Grids in Fields
A grid can be sampled as part of normal field evaluation using the Sample Grid node. It has a position input and computes the interpolated value at that position in the grid. Alternatively, one can also use the Sample Grid Index node which provides low level access to the actual values stored in the grid.
SDF Grid Modeling
A signed distance field (SDF) grid is a float grid where the active values describe the distance to a surface. Negative values are on the inside and positive on the outside, and the surface is where the values are zero.
While this is generally a fairly inefficent way to store detailed shapes compared to a mesh, it has the great benefit of making it very easy to perform certain operations that are hard on meshes. Most notably, boolean operations with smooth transitions become simple.
There are also various specific filters for SDFs which can be used for operations like smoothing.
OpenVDB Operators
The great benefit of building on top of OpenVDB is that it comes with a large set of ready-made algorithms to work on volumetric data that can be easily exposed in Geometry Nodes.
In 5.0, there are already nodes for advection, boolean operations, vector calculus operations like curl and gradient, and various SDF filters. There are still more that are not exposed yet due to time constraints, but more will come in future releases.
History
This release culminates over 4 years of design iteration on the volume features. With so many other things to implement, it made slow progress over the years.
The first design explorations started in 2021, mostly focused on accessing volume grids in the same way as named attributes, like in Geometry Nodes overall before the addition of fields. In 2022 we started to implement that design, but over time it became clear that constantly accessing grids with names from volume geometry was too cumbersome.
With a design for grid sockets, we decided to start over, removing the nodes we had implemented so far. For the last two years we have been implementing this design as time allows. The addition of the grid socket shape required a larger change to the way we visualize sockets and fields across Geometry Nodes and even the compositor, which is described in a separate blog post. With luck, these iterations and extra time will mean the design holds up better in the end.
Support Blender
Development requires dedicated design and development resources.
Donate monthly or one-time to help make this happen.
