Whew, fingers crossed 
This will be the biggest step backward.
Useless names again
Incomprehensible links
Nodes for entering expression strings
full-fledged written programming languages
magic python generator for beginners
It seems like there is still no consensus between development and coordinationā¦ I hope this is agreed upon before any actual development happens. Jacquesā comment on the relevant task is completely right : long connections is a general problem, not limited to attribute usage. Named attributes are not a solution to this general problem. āPortal nodesā look like a better fit imho.
If attributes only need naming at the boundaries between systems (it does seem like this is the case) then the output attributes fields in the modifier interface are doing the job just fineā¦
1 Like
Extremism is always bad.
In politics (far right vs far left). In nature (too much of certain mineral or vitamin can kill you, and so can too little), in programming (being too extreme with object oriented or functional programming paradigms), just everywhereā¦
And that applies here as well. In 2.93 we had attribute name extremism, where geometry nodes were all about attribute names, to the extreme point of being unusably painful.
Now we have anti-attribute name extremism, where even idea of minor, reasonable use of named attributes is considered bad.
Every well working system, be it human constructed, or natural works well only when there is balance, not one or the other extreme. So I think most of us just want a balance. Introducing two nodes, one to store named attribute and one to retrieve it will in no way make the whole fields based GN system collapse. In fact, Iād argue that fields will collapse without it, because without named attributes, node networks beyond certain level of complexity will become so hard to manage it will limit the whole GN potential.
Sure, 2.93 design of geometry nodes was a mistake, but that doesnāt means we have to overcompensate for that mistake.
7 Likes
By the way anyone else frustrated by this?
Imagine how much prettier could the node networks using reroutes look if there wasnāt this reroute node vertical tangent nonsense 
10 Likes
Iād just like to give my view on named attributes as a python addon developer. Long story short, having to get attributes through the modifier is an utter nightmare with python. Here are some of the downsides Iāve encountered:
- The modifier inputs/outputs are not full properties, so you have to access them using
modifier.keys(). - This is then a pain because there is no way of knowing which key relates to which input/output of the node groups (the names seem to be arbitrary as far as I can see)
- The keys contain both input and output properties, so they have to be manually filtered every time you want to use them.
- By having to distinguish them by only the name, you are then relying on an arbitrary naming convention, which could be changed at any point in a future version of blender.
- If you actually do want to get the input/output property, the best way Iāve found is to find the index of that output in the node group, and then get the key at that index from the filtered keys. This is prone to bugs, and a terrible idea in general.
- Because they are not full properties, you cannot directly draw the modifier inputs/outputs to a panel, which would be useful if you wanted to be able to use attribute search (which isnāt currently available to python).
- Instead, you have to create an extra string property for every input/output you want to influence, that you can then draw to a panel.
- As well as this, it also means you have to make a lot of extra node links, which adds more complexity to an addon, and makes it more prone to bugs.
Iāve found out about all of these while trying to port my Weight layers addon to fields.
In every other aspect, fields is a massive improvement, but now, what would once have been a few lines of code to draw a node socket, has been changed into a few hundred lines just to account for the fact that attribute in/out nodes have been removed.
It has caused a ton of bugs, instability, and headaches, and I would be very thankful if the devs added back attribute in/out nodes, as it would just make everything so much easier.
TL;DR The current attribute system using modifiers is absolutely terrible to work with using the python API, and a lot of pain could be avoided if named attribute in/out nodes were re-implemented.
8 Likes
And to any studios/individuals conceiving their own pipeline.
a lack of flexibility is a danger to sustainability
3 Likes
So you want, for the sake of external models, to improve the internal organization?
I think you need to upgrade your traductor. Try out Deepl
1 Like
I didnāt realize the functionality was so ācrudelyā exposed to python (excuse the choice of words), but thatās not really an argument against the system itself is it ?
I havenāt personally felt limited by the absence of named attributes so far -even though I expected to when fields first arrived. (Granted I havenāt used the API side of it)
I feel like the main stumbling point so far is actuallyā¦ the long connections ? which I see as a purely UX issue. The need to actually identify attributes is satisfied by named nodes, named reroutes, framesā¦ itās true that retrieving an attribute by name is somewhat more explicit, but not by much.
@LudvikKoutny I like the vertical tangents ! donāt take them away from me !
Do you have any example where they look better than the horizontal ones? I have yet to see a single screenshot where they donāt look worse than the horizontal ones. Vertical tangents donāt make any sense in Blenderās node editors as all the nodes are horizontal. None of the nodes have sockets on the top or the bottom edge. This frustrating exception for reroute results in disruption of the visual flow by ugly sharp corners which appear more or less randomly.
I like to keep my node trees clean and organized, so that the node connections donāt overlap or go under the nodes. Reroutes are exactly for that, but I would like to be able to use them without having to throw up into my mouth a little every time I see these:
Itās infuriating having to make a choice between the node link going over a node:
Or not going over a node, but looking like a dog***t:
I wish I could post screenshot from all other software with node based editor, which has curved node links, and doesnāt have this ridiculous exception completely ruining the visual aesthetic of node networks.
3 Likes
I think you forgot how incredibly slow and un-intuitive this new attribute interface via modifier+n panel is compared to the nodes that were available in the proto.
And yeah I agree, python api is a bad argument, full list of argument is available here : Named Attribute Nodes in Blender 3.0 - #4 by BD3D
Anyhow, afaik a comeback of these essential nodes is planned. Not sure why the conversation is igniting again, for the 100x already 
1 Like
Yes, I completely agree weāre losing some flexibility. Ideally Iād love to have bothā¦ I was under the impression there were technical concerns to mixing both, but maybe Iāve understood that wrong ?
Well, thatās not what I read on the task above. Last I heard Dalai opposed obviously to their inclusion, and heās a developer and Iām not
Iām messing with youā¦ 
I have no preference. As long as the connections shows, it could be in a W shape for all I care
Ye, thatās the thing. People either donāt seem to care or care for vertical tangents not to be there. I have yet to see anyone who makes a good argument for them.
I think you are referring to the discussion that lead the removal of these node, when they ported the prototype to main build back in august
Iām referring to this : ā T90864 Persistent/named attribute nodes
Now I donāt want to speculate, thatās just what I read
1 Like
Yup, thatās very old information,
last info i got in the chat months ago, was that the attribute node would do their comeback.
Edit*
And the 3.1 goals confirm this
( Store Attribute = Set ; Name Attribute = Get )
7 Likes
Alright, good to know
1 Like
Another example of how bad the unreliable user intention prediction is. I was solving an issue where using Curve factor at some point in my graph broke the connections in the curves, as each curve segment has its own factor value. So I decided to replace it with Z bounds gradient. I spent good few minutes debugging why it did not solve the issue just to realize GN was throwing sticks under my feet again by reconnecting Curve Parameter factor to the other slot instead of replacing the connection 
This REALLY needs to go away. Given how complex logic one can find themselves in when working with GN and how many things you need to keep in memory, such unpredictable anti-feature is really a big point of failure.
7 Likes
I does get a bit annoying, but to be honest, for me, I find it very useful when it actually does what I want it to do, so I donāt think it should be removed completelyā¦
Also, itās very useful in the shader editor quite often
1 Like