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?