As geometry nodes get more complicated, the need to limit operations to certain areas of the geometry is becoming more obvious.
You can't always split things apart into two pieces and work on them separately-- it's just not possible for some topology-changing operations.
Also, in a procedural context you want to be able to have multiple selections alive at the same time.
The most explicit way to refer to them is by name. These can be thought of the same way as selections in edit mode, with a different domain for each select mode.
We already have the idea of boolean attributes, which can exist on any domain. Then you can create a selection and use it just like any other attributes.
And other data types can be implicitly converted to boolean as well, making the whole system quite flexible.
The fact that a boolean attribute, or "selection," can be used like any other attribute is very powerful.
The point distribute node refers to its boolean attribute input as "Mask", but that is probably not the word to go with here. Another idea is "Tag".
I think that's a valid idea, but the word I would like to propose using is "Selection".
- The idea of having multiple types of selection has precedent in Blender
- Using the same word as in other areas simplifies language and makes it consistent
- It enforces the idea that the data passed around by the nodes is just the same as data in other areas, and that makes it easier to think about
Every node to have one or more "selection" filter. We have this already for a few nodes (or a "factor" input that has the same purpose):
- Point distribute density
- Point separate mask
- Point to Volume radius
The Selection attribute input only needs to be exposed by default where it is actually useful (this decision is a bit arbitrary):
- Edge Split
- Storing multiple selection outputs (e.g. boolean node new faces and new edges) is possible where necessary, and easy
- Using multiple selections in the same node is similarly simple
- The default behavior is the same as it is currently, the entire geometry is affected, which is more intuitive
- Selections are used only when necessary, there is no extra attribute when you aren't using them
- The fact that a selection is just another attribute is powerful, since it ties into implicit data type and domain conversions
- Since other data types can already be implicitly converted to boolean to use as a selection, it is consistent
- Selections are named, to give them better context when they are used later on in the node graph
- It allows explitly naming what will be selected with the string socket name, like "New Edges", which adds clarity where it is otherwise vague
- Allows easily passing a selection (boolean) attribute into the attribute processor
- Requires adding another string input field to a lot of nodes
- Requires typing / copying selection attribute names more
A part of the geometry is tagged/selected so that only this part is used by the following nodes until the selection is set again.
- Requires less interaction when you always want to use the selection
- More like edit mode selection which is automatically set by tools
- It's not clear how a node would output two different selections (for example, solidify rim and new faces)
- Requires clearing selections when you want to affect the whole geometry, since it is used implicitly
- This means that it even the simpler interactions with nodes become more complicated
- For example, if you had an extrude node and then a points to volume node, only the newly created vertices would be used, which is probably not desired.
- It is hard to track why a node is not working for the entire mesh, since all of the information isn't available in each node
- Selection attributes are not as visual as edit mode, etc, so the implicit nature is not as obvious
- Moving the selection to and from other attributes is slow and awkward
- Many nodes would reset the selection, so it would be necessary to move it to another attribute to carry it forward
- Selections aren't named, which loses some information that can help readablity
- Nodes cannot use two selections at the same time
Forking / Merging
Have a way to explicitly separate part of the geometry based on tagging and re-join them afterwards
- The split/join should be a bit different than mesh split. _Hans note: I don't know what this means_
- The re-joined geometry would work the same as the original geometry.
- Works well for point geometry, since there are fewer complexities to splitting and merging
- Makes node graphs less linear
- Requires learning the difference between a "real split" (2 different geometries) and a "fork"
- In other words, this breaks the idea of explicit data flow that we've been using so far
- "Sub-geometries" cannot be changed without affecting the main geometry in many cases, but this relationship is hidden and not reflected visually
- Splitting and joining a mesh and other geometry types is not a trivial operation
- This approach would be more expensive
- Attributes with different types and domains on a sub-geometry would have to be merged
- Does not work at all for topology-altering operations, and even deformations raise large questions about how a "Merge" would work
- A possible solution to the above problems is limiting what you can do to a sub-geometry, but that is not intuitive