Named Attribute Nodes in Blender 3.0

Archive Geometry Nodes
41

In fact, quite the opposite!
in this argument

The community believes that the change proposed is not faithful to how it was presented during the design testing phase of Fields. Field design left the possibility of both old/new method, it was clearly stated by Jacques.

I think it’s important to keep in mind that:
-everyone love field principle.
-everyone agrees with the fact that shareability can be a problem.
Where there’s disagreement is in the way this problem is resolved. :grinning_face_with_smiling_eyes:

At least that’s what I saw when i recapped hundreds of messages.

8 Likes
42

I just hope Geometry Nodes does not turn into the Visual Basic of nodes…

I always wanted with the original nodes to have the ability to take data from Geometry, manipulate it (thus avoiding the linearity) and return it to the Geometry without having to type in an attribute name twenty times. What it seems we are getting instead is anonymous attributes, which resolves that problem, but introduces a new one where I no longer can store data. Geometry Nodes have only recently added enough nodes to see if this will be a problem. If I want to move data between modifiers in the modifiers stack that seems to be no longer possible?

Named attributes allowed me to create vertex masks, I could isolate the lower values of a curve for example so that I can manipulate only the upper half. This seems to be no longer possible?

1 Like
43

Well, Technical artists are just a subset of artists. I understand a tool must be done for the public it is intended to, but my main point was not about if it would be a good tool for technical artists. It is that it may be a tool easy enough for not-so-technical artists.
Yet, it would start a debate of hard-dedicated tools vs easy-general ones.

Wouldn’t you rather for your tool to be as reachable as possible? At least the basics, the first look at your system. Expert users may use more specific, harder-to-use tools, but in a perfect world, a newbie should be able to understand a hard, cluttered node tree, with enough time and dedication.

Well, I can see what you are saying there, those are things commonly used in programming.
Even with agreeing with you GN being some kind of programming language, you cannot remove from it the abstraction layer that there must exist for it to be a node “visual” language, and the width of that layer determines the “features” that are in and outside the possibilities, for simplicity sake.
As for the API argument, even if it may not hit the bull’s eye, you have a given toolset, and with fields it is really “safe” and simple. And probably keeping variables moves even more the balance towards the “programming language” point of view.

However, if we step back and see the GN as functions you can call, there is no need to look at a node tree to understand its outputs, as any variable not passed as an output simply does not exist. That aligns with the API i was talking about.

Yet again, you will also need to make the algorithms. What is the problem with fields? Do we all agree that with fields we all will be able to do exactly the same as with variables?
I can see it being slower to make, at least in the beggining, but not impossible.
And in programming, usually the first principle is readability.

That is not an issue. This is OpenSource, and as so we never rely on the core developers for any feature if good enough to be added.
If there is enough people wanting that feature, someone in the community will fullfill it.
And that I think is not my opinion, but the way it is.

2 Likes
44

Reachability is already a problem and would be adressed with a subset of pre-made nodegroups created officially by blender (or by third parties such as Erindale Toolkit).

A developer just explained this here :

It was also confirmed on the blenderchat recently, discussed by @JuanGea

1 Like
45

Yes of course, node groups are needed for the most basic reachability.

However, my point was about a new user who wants to dive in and read a node group.
Fields is easy, implicit. Attributes have that tint of programming that is not that intuitive.

I don’t want to impose my point of view, and if it were to end with variables, I’m the first that will know how to use it. I’m just trying to expose why I think it would be better not to have variables.
You wouldn’t need to read any nodetree to know what can you do, and there would be no problems with bad named variables or people who name them badly because they don’t know english, for example.
And fields does not restrict any possibility.

What would you think about a self-contained variables?
Like, variables are local to a nodegroup (or that node they were talking long ago that would be like a math nodegroup), any data to be passed must be as a field

1 Like
46

I mean, if you go down this line of logic, then I can also “make my own Blender from scratch given enough time since it’s Open Souce”.
To me, it seems that you are reasoning around, to justify what you already have decided to believe.
I can accept that.

47

Well, were you to tell me about rigging nodes, or everything nodes i would agree.
Were you to talk about complex retopology algorithm, I might agree.

However it has been said people could work with variables, so I’m guessing (I don’t know all use cases) the missing functionality is either a port to the new system or a rather small feature.

And I’m not closed to opinions, and I don’t want to be seen that way, @BD3D has a good point when talking about technical artists using the features, a point that can not be taken from him, and maybe he’s right.
It’s just that I don’t share your argument regarding the priorities, because I trust in what the comunity is capable of.
You have to think that:
1- If everything related to GN were to stop tomorrow, whenever it resumes, this we are talking today could be used.
2- The base is done. The hard part* is done, or at least almost done.
3- If someone really needs it, they will move heaven and earth.

** The hard part being the integration in Blender

48

As far as I know, the problem of shareability could be the result of a limitation of current node groups.
In programming languages, we do have scopes. Within scopes, local variables can exist.
Node groups do not offer scopes. With named attributes, different named attributes would be able to operate on the same ‘global’ variables. Same with modifiers.

The user of GN modifiers does not nescesarly know if different GN modifiers do try to access global named attributes from within the modifier. One modifier could happily tweak and overwrite what another modifier uses. This might cause unpredictable situations.

Current solution avoids this kind of inconsistency, which might cause unpredictable problems, and maybe even costs. Imo, making shareability a priority is the right decision.

It would be better, if people focus on the underlying obstacles, which prevent shareability, instead of this curious polemics, cherry-picking what supports narrative, and selective ignoring evidences which dont support narrative. Im tired of this.

3 Likes
49

Why does named attributes improve on shareability?

As far as I know, the capabilities of a finished version of fields and named attributes is the same.
Please, correct me if I’m wrong :sweat:

1 Like
50

We can make some node groups without any variable, while allowing variables exist in other node groups. I think a new user of Blender also has difficulty understanding how most of the demo files work. But there are also a lot of other simpler demo files on the internet for learning. So it’s no big deal.

I don’t think removing variables totally is a good idea. The concept of variables is so useful in attribute workflows. In other similar node systems in DCCs, one of the most powerful tools is something like script node, which is heavily dependent on the concept of variables.

51

As far as I understand, different modifiers would be able to tweak same geometry attribute, without knowledge of the user. Different groups the same modifier uses could mess around on the same named attribute without the node designer knowing.

It is the lack of scoping, or name-spacing.

Think of a programming language with only global variables. You need to be extra careful with your naming. If you use a name like “strength”, another one who works on anoter code on the same app could have same idea and use “strength”. You both write functions which overwrite ‘strength’, because it is the same variable. An unpredictable situation.

Named attributes are kind of stray variables, which could be abused anywhere in any group or any modifier. Thats the way named attributes are a problem for shareability.

Imo, it would be better, if something like group scoping is worked on, before named attribute are introduced.

2 Likes
52

Okay so doing some devil’s advocate (since I would not dislike that solution), having both systems can be a little hard to gasp in the begining.

It is true I had not thought about a script node :thinking: were it to be added, nodes would be hard without named attributes.
I think everyone that wants named attributes should use that argument.

I agree with that point of view. If named attributes is really necessary, I would like named attributes to be used with “local scope”. Yet again is my own opinion and it is not worth a lot :grinning_face_with_smiling_eyes:
Or no named attributes at all, if possible.

1 Like
53

Heh …
we are equal :slight_smile:

Thank you for sharing your opinion.

54

Something I would actually rely on and never had a problem with. Can GN just require you to make global any attributes you want passed to the modifiers below? For example vertex color is a global attribute and there never been a problem…

55

The problem is the same, that this decision could need 5-6 years to change, or more.

56

Isn’t this the case with vertex groups, they are global variables?

I don’t see the global variable as an issue unless I am missing something. It is very predictable, you create global variables in the GN modifier, and these variables get passed only to the modifiers below. There is nothing stopping developers to remove variables generated in the GN modifier, or require the user to explicitly to expose them. We are not writing software here…

57

Thinking out loud here…

I don’t know if I fully grasp the situation, but I can still imagine a script group that takes inputs from fields, and there is where you name your attributes/variables to be used in the script nodes. Every named attribute that is created in the script could be local to the script and then could be written to output fields sockets.

So I can still imagine a node graph without named attributes, except for the inner context of a script node, but this is basically allowing named attributes with a local scope (the single script node scope),
a this point, we are back to the principle… just allow named Attributes with scopes and allow nodes that operate on them when necessary (for power users), along with fields and anonymous sockets (for regular less technical artists) and then in the future add an advanced feature for ultra-power user SCRIPT NODE… basically what H does with SPs (geo-nodes) VPs (fields like but allowing named attributes) and V*X nodes (Script nodes) …

Where blender could really shine is anonymous attributes, that can avoid typing where not needed , Most of the times one just need to build procedural systems, like modifiers but with branching and non linear workflows.

2 Likes
58

Hey, your opinion is equal to everyone else here.
At some point we just need to agree to disagree. :grinning_face_with_smiling_eyes:

If we ignore the important issues it can bring, there’s a strong philosophical theme emanating from the discussion, which is “Liberty vs Security”. There’s no right/wrong answer, it’s a matter of preferences.

No, i don’t think so.
It got to be re-introduced in 3.1

7 Likes
59

You meant, a script which defines a function, which does act like a field, and writes a field output?

Or, kind of script node which acts like a field node, which could be embed inside a field node flow?

In the future, a scripting language could be an interesting opportunity to quickly type math formulas.

Imo, having groups with proper scoping would also be interesting. It could enable shareability of (local) named attributes.

60

Yeah, basically doing the same things that you could do with nodes and fields too, but compacted in a node containing a script that (as you guessed) can contain math formulas, access vector components directly ecc.

This is not supposed to do more than fields+named attributes, but just to offer a different tool to create nodegroups, instead of nodes, they contain written code.

This can be used for example when a user is more experienced with programming and She/He’s just more proficient by writing, sometimes coding is just quicker to do than Nodes (For those how can code), or just more compact.

For users that are not inclined to write code, they can just use nodes instead.

But this is a whole different story for the future development. Sorry for the off-topic.

Back to the main topic, I think that there is not much more to say. We just have to wait and see I guess… a lot of (useful) noise has been done, for good. I hope that get/set node get implemented eventually (at least in 3.1) and if not so, I hope at least that it’s for good and we will find out that’s not that big deal…

5 Likes