Selection / Tagging in Geometry Nodes #86907

New Issue

Hans Goudey · 2021-03-24T22:30:29+01:00

Hans Goudey commented

2021-03-24 22:30:29 +01:00

Background
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.

Naming
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

Explicit Selection

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):

Triangulate
Edge Split
Transform
etc.

{F9909454 width=600}
{F9908331 size=full}

Pros

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

Cons

Requires adding another string input field to a lot of nodes
Requires typing / copying selection attribute names more

Implicit Selection

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.

{F9909450 width=600}

Pros

Requires less interaction when you always want to use the selection
More like edit mode selection which is automatically set by tools

Cons

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.

{F9909456 width=600}

Pros

Works well for point geometry, since there are fewer complexities to splitting and merging
Makes node graphs less linear

Cons

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

**Background** 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. **Naming** 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 # Explicit Selection 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): * Triangulate * Edge Split * Transform * etc. {[F9909454](https://archive.blender.org/developer/F9909454/image.png) width=600} {[F9908331](https://archive.blender.org/developer/F9908331/image.png) size=full} **Pros** * 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 **Cons** * Requires adding another string input field to a lot of nodes * Requires typing / copying selection attribute names more # Implicit Selection 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. {[F9909450](https://archive.blender.org/developer/F9909450/image.png) width=600} **Pros** * Requires less interaction when you always want to use the selection * More like edit mode selection which is automatically set by tools **Cons** * 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. {[F9909456](https://archive.blender.org/developer/F9909456/image.png) width=600} **Pros** * Works well for point geometry, since there are fewer complexities to splitting and merging * Makes node graphs less linear **Cons** * 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

Hans Goudey commented

2021-03-24 22:30:29 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Hans Goudey commented

2021-03-24 22:30:29 +01:00

Added subscriber: @HooglyBoogly

blender-admin commented

2021-03-24 22:30:29 +01:00

#85369 was marked as duplicate of this issue

Miro Horváth commented

2021-03-24 23:07:18 +01:00

Added subscriber: @MiroHorvath

Kenzie commented

2021-03-24 23:33:27 +01:00

Added subscriber: @KenzieMac130

Stephen Swaney commented

2021-03-25 18:09:00 +01:00

Added subscriber: @StephenSwaney

Some User commented

2021-03-25 21:02:48 +01:00

Added subscriber: @someuser

Some User commented

2021-03-25 21:02:48 +01:00

i should say, we need some way to select points/edges/faces/and_so_on by index and index range for example to be able to make selection from this string: '1,2,10-20,35'

Hans Goudey commented

2021-03-26 21:00:19 +01:00

For the records, I feel strongly that the best solution is clear: support explicit selection and real splitting, using the join and boolean nodes for combining. I think this gets you the best of both worlds:

Splitting is possible when it helps, and it is easy to understand because there is no implicit link between the two geometries
You have all of the power, flexibility, and ease of use of the explicit selection, and you can even use both methods together

Really this is just a continuation of what we are already doing anyway-- we already have the point separate node for splitting, and we already use boolean attributes as masks, etc.

For the records, I feel strongly that the best solution is clear: support explicit selection and **real** splitting, using the join and boolean nodes for combining. I think this gets you the best of both worlds: * Splitting is possible when it helps, and it is easy to understand because there is no implicit link between the two geometries * You have all of the power, flexibility, and ease of use of the explicit selection, and you can even use both methods together Really this is just a continuation of what we are already doing anyway-- we already have the point separate node for splitting, and we already use boolean attributes as masks, etc.

Erindale commented

2021-03-28 19:40:43 +02:00

Added subscriber: @Erindale

Erindale commented

2021-03-28 19:40:43 +02:00

How does a selection differ from any other Boolean attribute?

I agree with the index suggestion by @someuser, it’s always good to be able to be really specific in selections.
Modifiers like solidify or Boolean and operations like inset, bevel, bridge loops etc should all generate masks, either as an attribute or, if you have a way to read a string of indices, they could just have a string socket output that sends out the face selection indices. For an operation like extrude/inset you’d want to be able to choose between the existing faces that were extruded, the new generated faces around the outside, or both together.

Another selection method that would be extremely useful would be by region. Similar to the box select tool we already have in 3D. I think it’s been nodded at with the Select Inside Volume in the first image. If you were able to output a boolean attribute for elements within the second object's volume, this could be used for making selections or doing Boolean operations on points. It also creates the possibility for your selection region object to exist and be controlled in 3D space. Having a select by region, as opposed to select by index, means that tools like subdiv or decimate will still work before without altering later extrusion regions. A kind of psudo-procedural workflow can really speed up a bunch of stuff. I'm all for nodes but sometimes you just want to grab something in 3D.

How does a selection differ from any other Boolean attribute? I agree with the index suggestion by @someuser, it’s always good to be able to be really specific in selections. Modifiers like solidify or Boolean and operations like inset, bevel, bridge loops etc should all generate masks, either as an attribute or, if you have a way to read a string of indices, they could just have a string socket output that sends out the face selection indices. For an operation like extrude/inset you’d want to be able to choose between the existing faces that were extruded, the new generated faces around the outside, or both together. Another selection method that would be extremely useful would be by region. Similar to the box select tool we already have in 3D. I think it’s been nodded at with the `Select Inside Volume` in the first image. If you were able to output a boolean attribute for elements within the second object's volume, this could be used for making selections or doing Boolean operations on points. It also creates the possibility for your selection region object to exist and be controlled in 3D space. Having a `select by region`, as opposed to `select by index`, means that tools like subdiv or decimate will still work before without altering later extrusion regions. A kind of psudo-procedural workflow can really speed up a bunch of stuff. I'm all for nodes but sometimes you just want to grab something in 3D.

Hans Goudey commented

2021-03-28 20:21:35 +02:00

In #86907#1137454, @Erindale wrote:
How does a selection differ from any other Boolean attribute?

A selection is just a name for a boolean attribute. It could potentially be stored differently, but it's used like a boolean attribute anyway, and that's what matters.

> In #86907#1137454, @Erindale wrote: > How does a selection differ from any other Boolean attribute? A selection is just a name for a boolean attribute. It could potentially be stored differently, but it's *used* like a boolean attribute anyway, and that's what matters.

Kenzie commented

2021-03-29 15:24:59 +02:00

In #86907#1137459, @HooglyBoogly wrote:

In #86907#1137454, @Erindale wrote:
How does a selection differ from any other Boolean attribute?

A selection is just a name for a boolean attribute. It could potentially be stored differently, but it's used like a boolean attribute anyway, and that's what matters.

I would say it might be a good idea for selections to have or be automatically added to it's own namespace for creating selections. Maybe selection:MY_SELECTION_NAME or something? This way if the user was able to define selection sets while modeling they don't risk breaking anything that relies on other attributes while going about their own business.

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 point separate's mask makes sense to rename to selection, while the point distribute density and point volume radius can be used to mask out points they are not really the same as a selection. The user could easily want to use a sample from a texture somewhere on the node-graph which is shared with many other operations but only select a few polygons to affect, if selection isn't available there would be some more attribute bookkeeping for the user. Even if it at first seems redundant based on the current workflow it would be nice to see selection everywhere it could apply just as a shared standard.

> In #86907#1137459, @HooglyBoogly wrote: >> In #86907#1137454, @Erindale wrote: >> How does a selection differ from any other Boolean attribute? > > A selection is just a name for a boolean attribute. It could potentially be stored differently, but it's *used* like a boolean attribute anyway, and that's what matters. I would say it might be a good idea for selections to have or be automatically added to it's own namespace for creating selections. Maybe `selection:MY_SELECTION_NAME` or something? This way if the user was able to define selection sets while modeling they don't risk breaking anything that relies on other attributes while going about their own business. > 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 point separate's `mask` makes sense to rename to `selection`, while the point distribute `density` and point volume `radius` *can* be used to mask out points they are not really the same as a selection. The user could easily want to use a sample from a texture somewhere on the node-graph which is shared with many other operations but only select a few polygons to affect, if selection isn't available there would be some more attribute bookkeeping for the user. Even if it at first seems redundant based on the current workflow it would be nice to see `selection` everywhere it could apply just as a shared standard.

Dalai Felinto commented

2021-04-12 16:38:16 +02:00

Added subscriber: @dfelinto

Sergey commented

2021-04-13 17:24:20 +02:00

Added subscriber: @randum

Sergey commented

2021-04-13 17:24:20 +02:00

Was other alternatives considered to boolean selection? It seems to me that the approach does not cover all use cases. For example what if I want to find bounding boxes of all separate from each other mesh elements (islands). Now the node can only find bounding box of entire mesh. With boolean mask it will be able to find bounding box for only part of selected mesh. How should the solution look?

This is my understanding

On the picture the second node should create extra selection attribute where each element has unique value per separate mesh (island). For example all points of the triangle mesh can have 0 values, the points of the circle mesh have 1 values and the points of the quad mesh 2 values. It can be not only integers but any other hashable values like for example strings ('triangle', 'circle', 'quad'). Also it's similar to Blender face maps. Then the attribute can be used by the bounding box node.

Was other alternatives considered to boolean selection? It seems to me that the approach does not cover all use cases. For example what if I want to find bounding boxes of all separate from each other mesh elements (islands). Now the node can only find bounding box of entire mesh. With boolean mask it will be able to find bounding box for only part of selected mesh. How should the solution look? This is my understanding ![2021-04-13_18-56-00.png](https://archive.blender.org/developer/F9931916/2021-04-13_18-56-00.png) On the picture the second node should create extra selection attribute where each element has unique value per separate mesh (island). For example all points of the triangle mesh can have 0 values, the points of the circle mesh have 1 values and the points of the quad mesh 2 values. It can be not only integers but any other hashable values like for example strings ('triangle', 'circle', 'quad'). Also it's similar to Blender face maps. Then the attribute can be used by the bounding box node.

Kenzie commented

2021-04-29 21:24:51 +02:00

In #86907#1145886, @randum wrote:
Was other alternatives considered to boolean selection? It seems to me that the approach does not cover all use cases. For example what if I want to find bounding boxes of all separate from each other mesh elements (islands). Now the node can only find bounding box of entire mesh. With boolean mask it will be able to find bounding box for only part of selected mesh. How should the solution look?

This can be handled by a loop solution where each separate element by connectivity is looped over and processed. This way a solution designed to work on only a single mesh can be expanded to work on many without needing to refactor the node graph. Ex: a stone from blockout generator group being able to work in a loop over all bricks on a cobblestone wall.

This is my understanding

On the picture the second node should create extra selection attribute where each element has unique value per separate mesh (island). For example all points of the triangle mesh can have 0 values, the points of the circle mesh have 1 values and the points of the quad mesh 2 values. It can be not only integers but any other hashable values like for example strings ('triangle', 'circle', 'quad'). Also it's similar to Blender face maps. Then the attribute can be used by the bounding box node.

The unique integer per-part seems like the best immediate solution. I don't think that should be part of the selection system but could be generated by a new node that creates it for connected geometry and overlaps/patterns in selections/face maps/attributes.

I agree assigning names to parts of a mesh might be needed in the future for more advanced loops, rigging and sims but I don't think that would be needed for a while or any reason not to have binary selection.

> In #86907#1145886, @randum wrote: > Was other alternatives considered to boolean selection? It seems to me that the approach does not cover all use cases. For example what if I want to find bounding boxes of all separate from each other mesh elements (islands). Now the node can only find bounding box of entire mesh. With boolean mask it will be able to find bounding box for only part of selected mesh. How should the solution look? This can be handled by a loop solution where each separate element by connectivity is looped over and processed. This way a solution designed to work on only a single mesh can be expanded to work on many without needing to refactor the node graph. Ex: a stone from blockout generator group being able to work in a loop over all bricks on a cobblestone wall. > > This is my understanding > > ![2021-04-13_18-56-00.png](https://archive.blender.org/developer/F9931916/2021-04-13_18-56-00.png) > > On the picture the second node should create extra selection attribute where each element has unique value per separate mesh (island). For example all points of the triangle mesh can have 0 values, the points of the circle mesh have 1 values and the points of the quad mesh 2 values. It can be not only integers but any other hashable values like for example strings ('triangle', 'circle', 'quad'). Also it's similar to Blender face maps. Then the attribute can be used by the bounding box node. The unique integer per-part seems like the best immediate solution. I don't think that should be part of the selection system but could be generated by a new node that creates it for connected geometry and overlaps/patterns in selections/face maps/attributes. I agree assigning names to parts of a mesh might be needed in the future for more advanced loops, rigging and sims but I don't think that would be needed for a while or any reason not to have binary selection.

Riccardo Bancone commented

2021-07-27 14:43:44 +02:00

Added subscriber: @RiccardoBancone