# 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?