# Volume Grid Sockets [Proposal v1]

This document presents a possible design for how to integrate volume proccessing in Geometry Nodes.
The main aspect that is explored here is what happens when we introduce a new socket type for volume grids.


A grid socket corresponds to an unnamed `OpenVDB` grid. The means it contains:
* The full topology information (active and inactive voxels/tiles).
* A transformation (also determines voxel size).
* The data that is stored in the active voxels.
* A background value.

A volume in a geometry socket can still contain an arbitrary number of grids which may also have different transforms.

## Converting to and from Other Geometry Types

Various nodes can convert to and from other geometry types like meshes.


When converting to a grid, one generally has to provide a resolution. There are different ways to specify a resolution. These options exist in nodes we have today already.

## Converting SDF and Fog Volumes

SDF and fog volumes are both important to achieve different effects. They are both grids. There are simple conversion nodes.


## Building Grids from Scratch

There are different ways to build grids from scratch. Here are a few examples:
* SDF Sphere: Creates a new sphere sdf grid with the given size and center.
* Cube Grid: Creates a new dense grid inside of a cube. Each voxel in the cube is initialized with a field.
* Grid: Builds a new grid by evaluating a field in all active voxels/tiles. The set of active voxels/tiles is taken from a reference topology grid which must be provided.

In the `Cube Grid` and `Grid` node, a data type selector is necessary. Optionally, those nodes could have the ability to generate multiple grids at once.


## Changing Topology Without Changing values

Those nodes change change which voxels/tiles are used while still representing approximately the same volume data.


## Data Processing

Function nodes like the math node allow the inputs to be grids. If at least one input is a grid, the output is a grid as well.


If multiple inputs are grids, there is an error if their voxels don't align. The active voxels/tiles in the output is the union of the ones in the input.

If there are other inputs that are not grids, they are evaluated as fields inside of the function node. The context of the field evaluation is the output grid topology and transform.


## Grid Field Inputs

There are a few new field inputs that can only be used in the grid context.


The voxel center may be identical `Position` node.

## Accessing Grid Values

Individual values in a grid can either be accessed based on their position in object space using the `Sample Grid` node, other using index values in grid space using the `Sample Grid Coordinate` node. The former may also interpolate between different voxel values. Its position input defaults to the `Position` node.


## Aligning Grids

All grids passed into a function node have to align. If they don't there is an error and the user has to make sure that they are aligned. There are two main ways to do this: with the `Sample Grid` or with the `Resample Grid` node. The main difference is that when the `Sample Grid` node is used, the topology of the changed grid does not affect the topology of the function node output.


## Debugging

Grids contain all information necessary to display them, so they can just be connected to a viewer without the need for a geometry socket.

## Modifying SDFs

Some specialized nodes for SDF processing are added.


## Advection

Depending on the use case, one can either advect a single grid or all grids in a volume.


----