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
5

My 2 cents:

Please do not treat the attributes as two different citizens; shareability would work as long as the intended graph has such named attributes, it should be a matter left to the user.
What would happen if we connect a group intended for curves on a mesh? What will it do when it doesn’t find the “Radius” attribute?
There can be nice debug tools to signify if an attribute is missing, without distinctions.

Having used limited, rigid systems in the past, it was a breath of fresh air to be able to create and manipulate attributes.
In the old system all attributes were the same. This is an important principle, signifying the intentions of the system to be open and flexible.

That was still the case in the prototype so feedback came accordingly. As soon as attributes were removed, the feedback came en-masse and was largely homogenous.

I could be proven wrong, but I do think it would be a mistake to establish that there are special kinds of attributes. Even if they come in 3.1, this leads to rigidity in design and will affect features to come.

10 Likes
6

Dfelinto; I find fields a great advancement as far as being able to think creatively is concerned (it makes things a lot more like Cycles), but it needs to be emphasized that having an ‘advanced’ category that includes a fully generic get/set node for custom attributes would be a good thing to have for users who understand how to properly handle such information. In addition, perhaps that ‘advanced’ category could even have nodes that allow the typing of things like equations and conditional statements.

I get the idea of making things more straightforward (for artists and for the purpose of making features easier to get into), and the concept of fields delivers that in spades. It should not however lead to the devs. shying away from offering a more advanced and low-level way of working with certain features for those who understand how said features work (ie. stuff that is definitely not recommended for new users or even for people who are not well versed in thinking analytically). Then there’s the utility it has in the creation of custom modifiers, giving the option to not have attribute fields at all in the UI and instead providing only the options that are clearly relevant to what the tree is intended to produce.

To conclude, there is absolutely nothing in this proposal of mine that would bring back the requirement of using typed attributes for just about any case (if you want to use the workflow being set up now for everything, then go ahead). This is more in the line of adding something that doesn’t make any fundamental changes to the current system.

13 Likes
7

Some points I would like to give special emphasis to:

  • The new way of working with custom attributes results in confusing trees.
    • To define custom attributes, we are forced to use the modifier panel. This is counterintuitive to the philosophy of everything nodes.
    • All custom attributes must be defined at the top. This makes nodegroups less usable as a unit and forces the use of the more linear modifiers.
    • Since modifier properties are linked to the object data, the modifier must be set up again every time it’s used. It is not possible to set an attribute as default value.
16 Likes
8

If this is how custom attributes will come in, I do agree it is quite counter intuitive to focus between geometry nodes window and the modifiers window. Really, there should be a simple way to set attributes anywhere in the node tree

11 Likes
9

Honestly, I feel that the more arguments are given here regarding Get/Set nodes (Named Attributes), the worse it would become.

Dalai asked specifically to not start a thesis-long debate over here, on this topic. We are giving him plenty of reasons to completely ignore what we say (and rightfully so? idk…)

Maybe we can invite him in another thread where he could give us a few minutes to talk better about this topic?

Maybe here? Please?

EDIT: This was posted in a different thread, but now moved to this thread. Context is lost here so please ignore this and continue the conversation.

7 Likes
10

Why is such a big problem to have a Get node for attributes?

The attributes could be exposed in the node, why not?

An option to hide them could be welcome too in some situations, specially if you want to have a named attribute for reusability, but you will feed the attribute internally, with no reference to the outside, and that’s something the users must learn to use, not something dangerous, and the artists (no TD, no direct GN users) don’t need to have that attribute exposed in the Modifier UI.

And inside the node you can have a set and a get node, I don’t see the incompatibility with what is being done now with fields, and I don’t see either a problem of share-ability at all, it’s just more functionality, better user experience and it’s not conflicting with anything in the fields concept.

I understand you want the attributes to be created directly in the node tree, and I can understand that, but we should have a UI specifically for this, and not depend on the Input node always because it will become MASSIVE in some situations.

@dfelinto right now we have the set node, and the get node is exactly the same as duplicating the input node, connecting the attribute output and hiding all the other sockets… but with a better user experience and with more control for the TD to decide what must be exposed in the modifier and what must be hidden, that should be controlled by the user(TD, not artist), not everything has to be exposed at all times.

Do you know what a mess can an artist do if you don’t hide some things from their ability to use the modifier? (rhetorical question, you already know it :slight_smile: )

P.S.: a WEIRD workflow is to have to go outside of the node tree to define something that you connected to the input node as an attribute with the button, that’s weird, that control should be inside the node tree too

15 Likes
11

Probably, yes. It seems some might need to be processed to be initialized with something meaningful.

Mh …
Jumping around between node editor and the properties editor is rather curious workflow. Too much distraction.

Perhaps, an operator “create new input attribute” could be interesting? Something which could create a new custom attribute for the active object, which uses the GN node tree. And offering the group input node, after it is created.

2 Likes
12

I thought this discussion was to talk about all this.

In what thread should we put this discussion then?

EDIT: The discussion was moved by @HooglyBoogly to a proper, corresponding thread.

1 Like
13

Has the compromise of having a Warning on the Node Group when a Named Attribute is included been considered… i think its enough of a discouragement… and i don’t think anything more is needed… Banning Named Attributes from the Node tree feels like an Overreaction to a rare problem

8 Likes
14

Hello

Since when the main focus of geometry node is shareability?
I don’t understand why there’s so much insistance on an abstract logic with no proven use case nor demonstrated effectiveness, creating restriction for a conceptual idea that few can understand is not reasonable.

Coming from Houdini, I do bot understand where this idea is coming from. What you want is giving as much freedom and flexibility to users as possible!! Removing access to attributes from nodes will cause blender a lot of problems in the future if they want a good procedural nodal solution. For example: how can they possibly develop an attribute scripting node by restraining access to globals? This do not make any sense. Dalaï should think deeper of the possible deep implications of his decision.

This is an unexpected turn on the project. Jacque and Hans field design should be respected and ported as they design it.

21 Likes
15

I think the change in the geometry nodes philosophy should be reconsidered considering that historically the worst decisions in blender development always happen when developers limit users for fear that they won’t know how to use the program. So this red flag is starting to be a good clue, along with hundreds of user complaints, that a bad decision is being made.

Apart from this, it is a pity that the everything nodes concept has remained a kind of modifier designed to be a shared asset. Instead of what I think many people expected as a first step in giving the user a powerful node enviroment where they could create objects that were simply a nodetree from their own conception.

17 Likes
16

Wholeheartedly agree with everyone above.

I love Blender more than any DCC. It’s an absolutely wonderful program and I’ve been lucky enough to use it every day for the last few years. The developers are incredibly helpful and responsive, and I honestly think this is just a misunderstanding.

I will say that it’s really disconcerting that “Get/Set Nodes” were removed after them being an integral part of the 2.93 rollout that introduced us all to geometry nodes. The 2.93 rollout of geometry nodes was a prototype build so that we could all get acquainted, test the system, and see the response of the users. Now, with the next version up, the arguably most integral part of the system has been dismantled and erased under the guise of shareability. It’s a bait and switch, but I would say that this probably still comes down to a misunderstanding.

When users created posts, polls, comments, etc… to ask Blender artists the users overwhelmingly asked to keep these nodes. What is worrisome is that all feedback was ignored, or at least deferred by developers in the form of a status update…

It’s very concerning that Blender isn’t taking into account the opinion of the vast majority of artists who are actually working with these systems daily. Instead a feature that was working great has been deleted and has been swept under the rug with a statement saying “We hear you. We’re sorry, here’s a deferral to wait until 3.1 to rehash this entire argument again.” This is only concerning because it’s been clear from the beginning how the artists feel about it…

Blender artists would like both, the get/set nodes, and the other sandboxed version that protects artists from making their geo-nodes setup not shareable.

It makes the most sense to leave a “Warning: This geometry node system might have issues with shareability due to a custom attribute”. Then people will know there are shareability issues with their geometry nodes setups, and people who want to be safe will know they are being safe by not using custom attributes.

Cutting out things that make Blender more flexible is not the direction to go under the guise of shareability. We all want shareability, but not at the expense of losing the nodes that were given to us during the prototype build of geometry nodes.

Saying that we’ll come back to talk about this at 3.1 is saddening, but I had a feeling this was going to be a fleshed out battle, and I’m confident Blender will not choose to ignore the vocal majority on here.

Everyone has been clear about this from the beginning. If the get/set nodes were in 2.93 it makes very little sense they wouldn’t be able to be put in 3.0, but if it takes until 3.1 then it is what it is!

I appreciate all the amazing work you wonderful developers do!

You all work very hard and I am forever thankful for your service!

19 Likes
17

@dfelinto
The inventors of the the field design expressed concerns over this decision.
The whole community expressed concerns over this decision.
Yet you don’t even consider merging these back in time for 3.0?

:persevere:

12 Likes
18

One issue that hasn’t been adressed yet is more logistical: every get&set node is its own patch that may end up in months long review limbo if it isn’t being done by core team members. For example more niche attributes like the ones used for the skin modifier or curve tilt may be super awkward to control for months until they get their own nodes.
The same kinda applies to shareability too: as of right now, I don’t think there is even a proposal, on how node trees will fit into the asset manager (which has been in development for years), so while we lose lots of functionality now, we will get the convenience of sharing being maybe less painful in like a year or two the earliest.

imo the whole shareability thing is very hypothetical anyways

3 Likes
19

With share-ability being the primary reason for not wanting custom set/get attribute nodes, isn’t it just easier to make some official guidelines for publicly shared node groups?

The guidelines could state that no shared node groups could contain any custom attributes, or if they did contain them, then the attributes would have to be pruned/deleted via an attribute remove node at the end of the group node network.

Then it would be just like creating a local variable within a function in traditional coding. A custom attribute would only be seen and used within that local group node tree.

Maybe I am missing something, but isn’t a policy like this easy enough to implement, especially if the concern is about including higher level node groups to be bundled with Blender in the future? Each node group is then a black box unto itself and won’t pass on any custom data to its’ outputs.

Sure, there could possibly be custom named attributes created earlier in the network having a naming conflict with a custom named one inside the shared node group, but this is a very corner case and should be up to the user to resolve. After all, there is an error system built into the nodes that would warn you about the conflict. Beginner users who are using geonodes wont run into this problem if they are using shared node groups, as they are very unlikely to create custom attributes themselves in the first place.

5 Likes
20

After thinking quite a lot about this, what I said before still stands, but I think there is a fundamental flaw in this.

Share-Ability si not something that should be defined by the software, it must be defined by the tech artist / TD that is using the node tree, and that artist must learn to properly do this.
GN has never been planned for new/only artist, but for tech artist, and this has been explained to me and to us all many times, and this move seems to be to protect the artist.

Trying to protect the final user from a bad TD limiting what the tool can do is not a good plan at all.

It’s like putting the band-aid to the child before the wound is there, allow the child to make a small wound so he can learn to avoid bigger wounds in the future, and then show him where can he take a band-aid and how can he use it, don’t be over protective, that’s BAD

In the end after many thinking on this is:

Share-Ability must not be defined by the software, it must be defined by the Tech User / TD, it’s a responsibility.

22 Likes
21

Here’s an interesting one:

We already have a long list of pros and cons regarding Get/Set (Named Attributes) which is overwhelming in favor of it being added (added back?).

I don’t think it’s even an issue of “if”, but “when”, since even Dalai mentioned in his post, that they are considering this, it’s just a matter of time & deadlines (Last 2 sentences are important):

What I’m aiming to say here: at this point, we should try to give strong reasons why it should be added in 3.0 instead of 3.1 (“when”), because the other battle is long over, (the “if”). Or at least I hope…

This is (kind of) hinted here:

Also, I think I understand why the huge focus on “share-ability”. For most of us (single user) it’s a smaller concern, compared to a team (multiple users). And remember that the development focus is for Blender Studio. They probably rely heavily on this concept.

That being said, I still agree with this statement:

2 Likes
22

This has been the pitfall of most of the recent controversial decisions. Blender Animation studio is a flawed benchmark of production needs. The original Attribute based GN design (which they had to backtrack from) was also supposedly modeled on their needs, and the reason we still have dashed lines is partly because the feedback on them from animation studio was “mixed”.

Overall, the illusion that the Blender development is somehow “community driven” or “community oriented” started to fall apart very rapidly recently.

Blender seems to be going back into the old pre-2.6 pattern of design:

  1. Find a small issue
  2. Artificially turn it into a big problem
  3. Invent monstrous solution which does more harm than good to address it
  4. Implement such solution

It’s been that way from the day one, where relatively minor issue of selection/action separation was addressed with monstrous solution of using right mouse button to select things. A solution which did way more harm than good to Blender in coming years, and became one of the major obstacles for the widespread adoption.

Same happened with datablock management, where a trivial task of deciding which datablocks should be cleaned up resulted in monstrous fake user workflow.

Or of course more recently, a minor issue of distinguishing node connection types, already partially addressed by the node socket shapes received a monstrous solutions of drawing some node connections with dashed lines.

And now, relatively minor issue of shareability and name space conflicts, which can be addressed in numerous ways will most likely be addressed by a monstrous solution which will once again hurt Blender in months, perhaps even years to come.

11 Likes
23

My main concern involves share-ability because I’m in charge of producing our in-house tools to work better and faster, so I understand this concern, but since I’m conscious I have to properly create the tools, but I don’t want the tool to be limited.

For example, because of pipeline reasons I may want to have an attribute that stores some studio-specific information that I don’t want a user to change from the UI at all, that information must not be visible, nor touchable, from the UI, without internal named attributes I cannot do that AFAIK

And yes, I totally agree that this must go to 3.0, this is because 3.0 will be the first release where Geometry Nodes will be presented as a grow up tool as it is right now, and that’s a fundamental part of the workflow that is being removed, people will learn how to use GN now, so this, being a basic part of the optional workflow, should be in 3.0

12 Likes