Named Attribute Nodes in Blender 3.0

Archive Geometry Nodes
4

Thanks for the explanations Dalai

Yet, the get/set nodes are in direct correlation with the limitation imposed for this abstract concept of “share-ability”. Prioritizing share-ability, here, means the complete removal of accessing named attributes within node trees.

This is not a ‘light’ change yet it is presented as one, in a status update?

Right now it might seem to the untrained eye that this is only but a UX change, but if you look closely this change has profound implications on a core concept that have been established since the birth of the project and confirmed by the industry’s top procedural DCC’s, which is the interaction with named attributes within a nodetree.

The Get/Set nodes are not just facultative nodes that could be removed, they represent a concept by themselves. You will read below a recaputulation of every arguments made so far by the community when speaking of the removal of these nodes, these arguments are not just a rant about how users miss them, these arguments represents how share-ability creating restriction on flexibility is a mistake.

You cannot ignore these concerns, they are surface manifestations of a core concept change.

Arguments In favor of removing access to named attribute within nodetrees :

  • Guaranteeing share-ability of nodegroups, should be the key focus.
  • Named attributes can be totally replaced with fields.
  • The major consensus in the community was that writing attributes is bad, using fields is better.
  • From a programming paradigm point of view, accessing globals variables (encoded attributes) is a bad practice. Access to globals from the scope of a function should be forbidden to users.
  • In order to test this design properly we need to enforce it, we could implement the nodes later if the users need them.

Arguments against removing access to named attribute within nodetrees :

  • Prioritizing share-ability over flexibility is a mistake :
    • In a procedural software, flexibility should be the main attention.
    • User is now more restricted in his workflow choice and organization.
    • Making nodegroups shareable is the responsibility of the user, not the developer.
    • Enforcing the share-ability paradigm upon every single use case is a false assumption, nodegraphs set-ups designed for one-time usage in specific contexts are common.
    • Comparing with cycles :
      • Cycles do not avoid the implementation of new nodes to respect this paradigm, yet nodegroups are still an important part of cycles.
      • Cycles already have the “get attribute” node, what about the double standard?
    • The imposed share-ability concept is not consistent: Object or collection pointers completely break the nodegroups share-ability paradigm, both in cycles and geometry nodes.
    • The solution to possible share-ability issues is proper guidelines/teaching. Advanced users shouldn’t have their flexibility restrained to protect beginners who didn’t read the manual.
  • Nothing is preventing adding these nodes back except an abstract concept. Users who do not understand the concept end up confused.
  • This removal is ignoring users personal preferences :
    • Some users liked having the universal way of accessing custom or built-in attributes by typing their names within the nodes.
    • Some users liked/needed the ability of reading&writing custom attributes without being forced to expose them as parameters.
  • This decision creates significant change:
    • compared to 2.93, old habits are now completely broken.
    • the transition from 2.93 to 3.0 would be less drastic if the node were kept, it would limit the obsolescence of online content and reduce user frustration.
  • This workflow is a far cry from what was anonymously approved by the community when they chose the field prototype design.
  • Named attributes are a significant part of blender proceduralism:
    • There should be more than one way to interact with named attribute. Not interacting with them from the nodetree feels wrong “Named attributes are just a fundamental part of geometry to me, not being able to work with them in geometry nodes feels very limiting.” -Jacques Lucke.
    • Not accessing named attributes within nodetrees can hurt the development of genode in the long run, for example, when a scripting language will be introduced access by name will be a requirement.
  • Creating/reading custom attributes from nodes is an industry-standard feature. It’s to be expected by users coming from other procedural softwares.
  • Universal methods of working with attributes are important:
    • Both built-in or custom attributes could be read/written indifferently as they are both data in spreadsheets. It was the case in the prototype by typing an attribute name when using the get/set node. It is no longer the case now.
    • The new logic for built-in attribute access is to create input/get nodes for each possible built-in attribute. This will scale very badly with time when will be a lot more built-in attributes. Generic attribute name nodes are a simpler alternative.
  • The new way of working with custom attributes can be seen as cumbersome or slow:
    • “Personally I’m not convinced that the complexity of this over the method we used to expose attribute names to the modifier in 2.93 is worth it” -Hans Goudey
    • Going in the modifiers interface/ N Panel is not intuitive compared to searching for a node.
    • It adds considerable mouse travel distance and extra clicks (even more if users want their input near an area of his node graph, or if the modifier editor is not open).
    • Some situations might be tricky to handle:
      • When a lot of custom attributes inputs/outputs are needed.
      • When nodegroups are nested, custom attributes are forced to be passed from nodegroups to nodegroups until reaching the destination.
    • Using modifiers interface is required and is at the center of attention, wasn’t the goal of geometry-node to replace modifiers?
    • It’s a very welcome addition to the interface! but is a poor replacement of the node design.
  • Following this proposal logic, the “attribute remove” ability should also be removed from nodetrees. It is now impossible to remove an attribute procedurally.
  • There’s a good compromise: informing users about globals being read/written from the modifier interface. see D12685 ‘Store named attribute node with visible mapping’.
  • Counter-arguments:
    • “In order to test this design properly we need to enforce it, we could implement the nodes later if the users need them.”
      • No, it can be tested and decided before bcon3, port from prototype to master is still allowed in bcon2, time is not a problem, the nodes are ready to be pushed to master.
      • Testing won’t help if the restriction brings too many flaws.
      • This argument suggests that users/industry’s patience should be tried.
    • “globals from the scope of a function should be forbidden to users.”
      • No, globals should be discouraged, not banned. Globals are powerful and featured in many programming languages (and also in a very famous procedural DCC) for good reasons.
      • An access to globals is essential when writing unique scripts with no re-usability in mind. Nodetrees can be built in this context, it is very often the case.
    • “The major consensus in the community was that writing attributes is bad, using fields is better.”
      • False, The major consensus is that the field prototype was better.

I did spend a lot of time collecting and reformulating all community’s arguments, I hope that the design team will consider each of them seriously.

Ps:
- Some arguments might represent subjective feelings/opinions from users or designers.
- If you do not fully understand an opinion, please ask below.
- I am not objective in this debate, yet i try to be, if you feel like there’s an unfair representation of your opinion, please signal it below.
-This recap contains opinions on this subject spreaded over 3x devtalk topics, the blenderchat, Blender Artist, and Twitter.

38 Likes