BD3D
October 8, 2021, 2:05pm
1575
Explanation of the removal via a simple use case:
Example: Displacing a subdivided plane with a procedural noise texture, exposing some parameters of the noise, using an UVMap attribute as input to define our texture projection, a Vertex-Group is used to drive the strength of displacement. The color of the noise and a new ‘Sunshine’ attribute is written as persistent custom attribute.
BD3D:
What the community think
This proposal has created a lot of discussion in the community lately, since we were wondering when these prototype nodes come back in alpha. There were messages over this subject on 3x devtalk topics, the blenderchat, Blender Artist, and Twitter. The opinions were almost unanimously against it.
Below is a recap of all arguments I have read so far. - Some arguments might represent subjective feelings/opinions from users or designers. - If you do not fully understand something, 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.
Arguments In favor of removing the nodes:
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 the nodes:
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 shading nodes:
Cycles do not avoid the implementation of new nodes to respect this paradigm.
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 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 nodes are industry standard. They are to be expected.
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 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, the design has too many flaws.
This argument suggests that users/industry’s patience should be tried once more.
“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.
In Conclusion
Personally, I do believe that the future of blender proceduralism will be negatively impacted by the removal of the get/set attr nodes, right now it might seem that this is only but a change in the UX, 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. I did spend a lot of time collecting and reformulating all community’s arguments, I hope that Dalai will consider each of them seriously.
any comments?
19 Likes
