# Volumes

- https://hackmd.io/@lukas-tonne/H1HjaGalp
- https://hackmd.io/@II9-Bkl4TJifCqGL2jgbUw/SJ3puQ2x6
- https://hackmd.io/DHI9TXW6Rxu-AGWy7qXv_g

* **The key difference**: Grids can be grouped together with meaning even when they have no topological similarity
* **Key point** Geometry shouldn't be the only way to have data-flow in Blender
* This design transcends geometry nodes in that way
* Similar data types
* Grids
* Images
* Lists
* Capturing a field into a grid using an existing topology of a volume is a nice way to use existing concepts
* For performance, it's important that grids have the same transform
* Moving the UX to align more directly to the internal data makes more sense for volumes since it's so performance sensitive
* Separating references from storage is more confusing when the data is actually completely independent
* A grid with transforms/resolution is similar to a canvas in the compositor
* Each image has its own location and rotation
* Without grids, the analagous concept is geometry instead of grids
* Geometry is data with meaning attached
* Comparison to lists and point clouds: "List is to point cloud as grid is to volue"
* Grease Pencil = Curves + more attributes
* Point Cloud = List + Material
* Volume = Grid + "How to render the grid"
* Though, grids are closer to "geometry" than lists since they already have more meaning attached
* Having a "data socket" would be a first step to integrating the node systems
* Geometries are used to affect more than one grid at a time
* A list of grids is also similar to a volume. Nodes could process "for each item in list" implicitly like some other node systems
* If a volume guaranteed that its grids had the same transform, that would give them more shared meaning and possibly a more compelling reason to be able to separate them
* Sparsity is just a performance consideration, not a key design point

Questions/To-Do
* Could the Grid socket also process volumes, similar to how the curve nodes process GP data?
* If "Blur Attribute" can be a field, why can't volume operations be a field as well?
* Can there be implicit conversions from grids to volumes?
* Need a list of pros and cons
* Using the new data-flow concept just for volumes might not be compelling enough
* Does the fields concept still work for volumes? If no, why not?
* How often do we use multiple grids at the same time?
* Is there a way to make dealing with multiple grids more convenient?
* Would it make sense to somehow introduce both methods at the same time so people have the choice?