Named Attribute Nodes in Blender 3.0

[HooglyBoogly]

The discussion of named attribute nodes in 3.0 has been going on in the update thread below. While I agree that it’s a very important topic, it’s best to respect the original goal of the thread, which was a more general status update.

Geometry Nodes in Blender 3.0 - Status Update

We are getting close to the end of Blender 3.0 bcon2 and I would like to share the current status of the geometry nodes and what is still expected for this release. Fields If you are not yet familiar with the concept of field (and the function flow) please first read this blog post. Fields Visualization In order to clearly communicate the difference between the existing flows (data and function), sockets and noodles are drawn differently. Data flow is represented by a thick continuous line…

To that end, I hope this thread can be a place to clarify the reasoning for keeping the named attribute input and output nodes in 3.0.

The Case For Named Attributes

In my opinion, there are plenty of reasons to include these nodes in 3.0. Many of them have been discussed quite a lot, so I won’t bother making a list here. I’ll recommend the list that @BD3D has created:

Named Attribute Nodes in Blender 3.0

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…

One of the most striking reason is related to a design decision we made regarding the “Stable ID” output of the distribution node last week. The feedback we got was that it’s confusing, and takes too much time to manually connect the stable ID output to every place that needs it. Of course, the way around that problem is to allow an “invisible” means of passing around the data. In that case, we decided to make the “random_id” a builtin attribute. In other words, it has a name, and the usability for the vast majority of users will be much better.

If we disallow named attribute nodes, it means creators using geometry nodes to create shareable assets will not be able to make similar decisions. One of the goals of everything nodes is to expose the flexibility that would allow technical users to make the same type of decisions that developers can make, just like you can now rebuild the shrink-wrap modifier with geometry nodes.

Store Named Attribute

This node is already planned, and is being developed in D12685, where most of the work is already finished. The remaining question is whether to solve the share-ability design goal with an name override map in the modifier, or with an operator that automatically creates the node links to expose the name to the modifier interface.

Attribute Input Node

This node has not been officially agreed upon by the geometry nodes team. However, there is a working version in the patch linked above as well, meant for testing.

The same decision applies here-- whether to use the name mapping or the “expose name” operator.

A Solution to Object Info and Collection Info Attributes

One of the last major parts of the design to finalize for 3.0 is how named attributes are retrieved from geometry external from the node tree-- geometry that comes from the object info and collection info nodes. We have considered a few solutions. The solution that would be used without the named attribute input node is adding attribute output sockets directly to the two info nodes. However, that approach has quite a few problems:

• Both of those nodes can output instances. It does not make sense to output attributes directly from the node when the output is instances, which do not have named attributes.
• It requires different solutions for when the object is chosen in the object info node vs. when it is exposed to the modifier or otherwise chosen elsewhere.
  • This complicates understanding of the system for the user, since it would inevitably require specialized behavior.
• The mechanics of choosing types for a dynamic number of output attributes would be cumbersome.
• The system would be much more complicated to develop.
• Even with this complexity, you still have to choose attribute names, so it is not more shareable than having a dedicated node.
• As more outputs are added to those nodes, they become very large.

An alternative is simply relying on the named attribute input node to access attributes in these cases. This solution that would already exist, so it’s simpler to understand, and simpler to use. Plus, the mapping of names would already be visible in the modifier, so it is a share-ability improvement.

Conclusion

Anyway, thanks for the consistent testing and the feedback over the last few months. My hope is that the solution proposed in D12685: Geometry Nodes: Named attribute nodes with visible mapping can satisfy everyone.

[kurk]

There is one issue with the idea of sharing of the nodes. As of now the new user of a node group has to create and add all the necessary attributes to be able to use it properly. I propose that the geonodes modifier can have a button to add all the needed attributes so that the user has less friction upon enabling the modifier.

We already have something similar in the data transfer modifier, it can add the missing data layers to be able to transfer the values from another object by matching the intended attributes.

[dfelinto]

Another option is to supporting dragging an attribute directly in the node group, and have the connections automatically created for it.

Another idea is to allow users to see the current value (and perhaps set them) from inside the nodetree. Even if the values are actually stored in the modifier.

There are a few ways to improve the usability of the system. 3.0 may be too close for those, but at least for 3.1 I hope we can get quality of life improvements like this.

[BD3D]

Thanks for the explanations Dalai

@dfelinto

That said, I know some people want to talk about the Get/Set nodes, and this is not the point of this post. The focus here is on getting everyone aligned for the 3.0 release, so everyone can help with testing, new files, documentation, …

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.

[Orestiskon]

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.

[Ace_Dragon]

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.

[zorro-weaver]

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.

[dimitar]

@zorro-weaver

• 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.

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

[cata_cg]

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.

[JuanGea]

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 )

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

[LeonardSiebeneicher]

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.

[JuanGea]

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.

[Leul_XYN]

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

[bproduction]

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.

[Alberto]

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.

[GageChristopherRenn]

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!

[Laulau]

@dfelinto

about possible 3.1 only targets.

@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?

[ogierm]

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

[jamez]

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.

[JuanGea]

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.