This task is for figuring out whether to map the idea of attribute grids to the attribute concept, and if so, how to do it.
Here's some background I wrote about in chat:
>One of the level set nodes we could implement is a fracture node that splits up one level set into many pieces based on some other surface. The output is an arbitrary number of grids.
>For meshes this is easy-- just have multiple "islands" in the mesh! But here we cannot just combine the grids. Theoretically each grid could be stored in a separate instance on the geometry, but they are not really instances, so that's a hack.
>I think you shouldn't have to choose grid output names in this case, and if you pass it to another node it would just operate on whatever grids were part of the volume. Very quick, and not complicated!
>On the other hand, a major use case for multiple grids is when they basically share the same topology but encode different information, like heat, pressure, velocity, etc.
>In that case you really want to be able to choose a grid when generating points, or easily split the density grid from the volume. Both are fine I think, splitting is a more general solution.
>**In the first case, grids don't correspond to attributes at all, they're just a bunch of different shapes, e.g. cloud puffs or surfaces, etc.**
>**In the second, they align well to attributes, except that there is no "main" attribute like position, unless that is the density grid**
In D12100 I implemented volume to mesh transfer for all grids in a volume, and "Distribute Points in Volume" will have the same decision.
Below are a few different methods that I've been thinking about:
=== All Grids ===
{F11707663 size=full}
- Volume nodes use all grids implicitly
- There may be many grids that refer to the idea of "density", whether or not they all have the same name
- In order to be used in operations, grids do not have to be merged. This is huge improvement for performance
- The join geometry node does not merge grids, the volume boolean node does that in union mode
- Volume nodes can function without a grid selection or input
- A "Split Volume" node is the main method of working on a subset of grids
==== Pros ====
- Nodes that operate on grids tend to become much simpler, because the grids don't have to be manually selected.
- Better performance, since grids don't have to be merged
==== Cons ====
- Less visual interaction with grids and grid types
- Not clear how math operations will be done on grid values (maybe an attribute-processor-like approach?)
=== Named Grids ===
//Currently I don't think this option is very compelling, I just included it for the sake of completion.//
- Volume nodes only work on a single grid at a time
- The grid choice is specified by a name
- This is what we had before.
- There is a conceptual distinction between fields and volume grids
- Working with volumes is significantly slower do to the need to type names in nodes
==== Pros ====
- Compared to the anonymous grid system, no need for every node to have the options necessary for creating new grids
==== Cons ====
- The downsides of the anonymous grid system without any of its benefits, except explicitly accessing a single grid
=== Anonymous Grids ===
{F11707672 size=full}
- Volume nodes only work on a single grid (though possibly merging could be done lazily as an optimization?)
- Grid inputs are specified by a field input
- Volume nodes output grids with the same method as anonymous attributes
- Math nodes can be used on the sockets used to pass fields around (otherwise it's misleading to use fields)
- Many nodes need more options to make this possible, because any node can make a new grid, including data type and resolution options
- Every volume node must support the ability to create a new grid with a field input, complicating code greatly
==== Pros ====
- The path forward for math operations on grids is much clearer
==== Cons ====
- Lots of noodles to connect, even for simple operations
- UX is much more different than what is happening internally
- Very easy to do surprisingly expensive operations like use geometry proximity to build a grid, when the other methods force more performant solutions.
- Much more complicated to develop, since it encompasses generic math operations on grids