# Selection * Embrace the attribute system. * I do believe in the power and flexibility of the attribute system. I do not believe that much in making Selection a special concept. Making it a special concept therefore comes at a high risk for me, while the benefits seem small. * I think the advantages that making selection a special concept can also be achieved without making it a special concept (by using a naming convention and good defaults). * In this context, KISS (keep it simple, stupid) means to me that to the question what attributes a node uses/generates, I can always answer "look at the node inputs". * Adding non-overwritable special cases makes this explanation more complex. Examples where more explanation is needed currently: * The `Attribute Randomize` node uses the `id` attribute. * The `Point Instance` node uses the `position`, `rotation` and `scale` attribute. * The `Point Rotate` attribute uses the `rotation` attribute. * All these special cases just add limitations and force users to use more nodes. * Just prefilling attribute name fields with these names would provide the same level of convenience without removing flexibility (+ also supporting expressions in the future). * I do not think that anyone of us has a lot of practical experience when it comes to procedural modelling. * I'd be very careful with introducing more core concepts based on our limited perspective. * I think when designing more features, we should try to use and extend the power of the attribute system, instead of limiting it. * We have to acknowledge that having more than one selection is common in procedural modelling. * If you only had one selection, the main thing you could build are tubes of some sort. * Skimming over a few modelling tutorials, it looks like starting a new selection from scratch is very common (not really a surprise). In procedural modelling, you don't have the luxury of just doing a loop select or something similar later on. Instead, one has to remember the loop from when it was created. * Therefore, in the context of procedural modelling, having more than one selection should not require a different way of thinking compared to having a single selection. * Another not too uncommon thing is to combine selections using boolean operators like `and`, `or`. This can be done with nodes but also with expressions. Doing this requires more than one selection at a time. ## Proposal * Every selection attribute used by a node, and every selection attribute generated by a node has a name field. * We might have to come to a conclusion with the [compact nodes](https://developer.blender.org/T87009) design to make this feasable. * If no input selection name is given, assume that either everything or nothing is selected depending on the node. * Some nodes might not make sense when everything is selected (e.g. a Poly Bridge node that connects two selections). * If no output selection name is given, don't generate a selection. * For convenience, `selection` becomes a naming convention for a selection attribute. * `selection` is *not* a builtin attribute. * It's not bound to any specific domain. * It's not bound to any specific data type. * It's just a convention. * We make it easy to use the `selection` attribute in various nodes. There are multiple possibilities for that: * Always show `selection` in attribute search (if it is actively used, it will be there anyway). * Prefill the input and output selection names in some nodes with `selection`. * Create a one click solution for inserting `selection` into a text box.