0
0
forked from blender/blender
blender/intern/openvdb
Jacques Lucke a72e7a220d Volumes: refactor volume grid storage
This refactors how volume grids are stored with the following new goals in mind:
* Get a **stand-alone volume grid** data structure that can be used by geometry nodes.
  Previously, the `VolumeGrid` data structure was tightly coupled with the `Volume` data block.
* Support **implicit sharing of grids and trees**. Previously, it was possible to share data
  when multiple `Volume` data blocks loaded grids from the same `.vdb` files but this was
  not flexible enough.
* Get a safe API for **lazy-loading and unloading** of grids without requiring explicit calls
  to some "load" function all the time.
* Get a safe API for **caching grids from files** that is not coupled to the `Volume` data block.
* Get a **tiered API** for different levels of `openvdb` involvement:
  * No `OpenVDB`: Since `WITH_OPENVDB` is optional, it's helpful to have parts of the API that
    still work in this case. This makes it possible to write high level code for volumes that does
    not require `#ifdef WITH_OPENVDB` checks everywhere. This is in `BKE_volume_grid_fwd.hh`.
  * Shallow `OpenVDB`: Code using this API requires `WITH_OPENVDB` checks. However, care
  is taken to not include the expensive parts of `OpenVDB` and to use forward declarations as
  much as possible. This is in `BKE_volume_grid.hh` and uses `openvdb_fwd.hh`.
  * "Full" `OpenVDB`: This API requires more heavy `OpenVDB` includes. Fortunately, it turned
  out to be not necessary for the common API. So this is only used for task specific APIs.

At the core of the new API is the `VolumeGridData` type. It's a wrapper around an
`openvdb::Grid` and adds some features on top like implicit sharing, lazy-loading and unloading.
Then there are `GVolumeGrid` and `VolumeGrid` which are containers for a volume grid.
Semantically, each `VolumeGrid` has its own independent grid, but this is cheap due to implicit
sharing. At highest level we currently have the `Volume` data-block which contains a list of
`VolumeGrid`.

```mermaid
flowchart LR
  Volume --> VolumeGrid --> VolumeGridData --> openvdb::Grid
```

The loading of `.vdb` files is abstracted away behind the volume file cache API. This API makes
it easy to load and reuse entire files and individual grids from disk. It also supports caching
simplify levels for grids on disk.

An important new concept are the "tree access tokens". Whenever some code wants to work
with an openvdb tree, it has to retrieve an access token from the corresponding `VolumeGridData`.
This access token has to be kept alive for as long as the code works with the grid data. The same
token is valid for read and write access. The purpose of these access tokens is to make it possible
to detect when some code is currently working with the openvdb tree. This allows freeing it if it's
possible to reload it later on (e.g. from disk). It's possible to free a tree that is referenced by
multiple owners, but only no one is actively working with. In some sense, this is similar to the
existing `ImageUser` concept.

The most important new files to read are `BKE_volume_grid.hh` and `BKE_volume_grid_file_cache.hh`.
Most other changes are updates to existing code to use the new API.

Pull Request: blender/blender#116315
2023-12-20 15:32:52 +01:00
..
CMakeLists.txt Volumes: refactor volume grid storage 2023-12-20 15:32:52 +01:00
openvdb_capi.cc License Headers: Set copyright to "Blender Authors", add AUTHORS 2023-08-16 00:20:26 +10:00
openvdb_capi.h License Headers: Set copyright to "Blender Authors", add AUTHORS 2023-08-16 00:20:26 +10:00
openvdb_fwd.hh Volumes: refactor volume grid storage 2023-12-20 15:32:52 +01:00