# Named Attribute Reasoning

- Necessary for creating named attributes on part of the geometry inside the node tree.
- Currently impossible to create a named attribute on only some geometry that is used for instancing
- This requires splitting node trees just to access the features that are tied to the modifier output.
- Named attribute from object info geometry
- The process for retrieving named attributes from geometry that comes from outside the node tree is very unintuitive.
- Even from experienced users, we get questions like "is it possible to use a vertex group from object info geometry?" frequently.
- While it's theoretically possible to teach this, the need to do that points at a design error.
- Utility to output a named attribute for a project
- The use of named attributes inside the node tree can often make node trees "more share-able", since the names themselves are what needs to be shared
- Dynamic manipulation of attribute names
- For specific projects, it can be helpful to create attribute names with nodes. Not allowing that behavior is closing off a good amount of flexibility.
- This need might be less important for assets, but more important for visualization, motion graphics, etc.
- Scene building vs. asset creation
- Named attributes are good for scene building (where you don't care about reuse and just want to quickly sketch out an idea). That is opposed to asset building. The workflow is more explicit when named attributes are created with nodes.
- High level node group sets
- Building high level task specific node groups. For example, someone might want to build a set of nodes designed for generating landscapes. Then this set of nodes could work with named attributes for dealing with task specific attributes (e.g. for vegetation, rivers, ...). Those nodes would be specifically designed to work well together to be very easy to use. In this case the user shouldn't have to connect all the anonymous attributes between different groups.
- Generally flexibility and a node-based paradigm
- This idea is less concrete than the others, but also important.
- Part of the idea with "everything nodes" is to generalize actions in Blender to give users more flexible fine-grained control.
- Node-based workflows with asset and tool-based abstractions should end up covering a large amount of what Blender is capable of.
- Manipulation of named attributes is an _essential_ tool for creation of art and 3D design, so controlling them with nodes will allow us to push this paradigm (which has been very successful) farther.
- Put a different way, _not_ adding named attribute nodes actively hinders our general goals for Blender's high level design.