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
Thatās like saying āI find getting radiation poisoning very useful if I have cancer.ā Sure thereās a saying that every cloud has a silver lining, but no software should ever default to bad behavior in hopes it will become useful.
Honestly, what you are saying just makes no sense. The problem here is that this is just straight up faulty prediction of user intention. If the software doesnāt know what user intends to do in a given situation, it should not decide for them. So in this case, it would make sense if the reconnect was separate operator that was triggered by some keyboard shortcut. But it should not be like it is currently, that when it actually does something you want itās the 1 in 100 luck.
I agree. I simply meant that I didnāt want the feature to be removed completely, because it can be very useful.
You seemed to imply in your earlier posts that you wanted it completely gone.
Yes, as a default behavior
hi i want to give give little feedback what is super annoying still.
-
the connecting line in geometry nodes gets invisible if you watching on middle . soi need to zoom out to able to connect the node.
-
when draging node the window still doesn pan view auto like if you drag the connection of nodeā¦ why not still ? this is super annoying? and why cant have whole dragoong that you can scroill mouse wheel and so it zooms without need to stop , zoom out, then try to connect againā¦
-
if adding new node then need constantly scroll up and down. : ( would be good if no need to scroll up , i mean there anouth space to see all the nodesā¦
could be connected so know from what section you choosing like in nodesā¦
1 Like
Can I get some community support on this matter: ā T94617 It is not possible to add Geometry Nodes to a mesh without creating unintended datablock
Anyone else frustrated by always having to make a garbage geometry node datablock everytime you just want to use existing GN network on another object?
There is currently simply no way to just use GN node network on another object without creating unintended new datablock, and itās beyond infuriating that just after a mere minutes of using blender, your datablock selector UI looks like this:
The response on the bug tracker is along the lines āBut you can just close the file and reopen it and they will be gone.ā, which is hardly a solution 
The argument for it was originally that it makes easier for new users to get get started using GN, but if any user doesnāt have mental capacity to recognize they have to click a GIANT +NEW BUTTON which is right in their face:
ā¦then they certainly wonāt have a mental capacity to do anything meaningful with the geometry nodes.
Right now, this poor design is yet another example of unrealiable user intention prediction. It always predicts user wants to create a new GN network, while in substantial amount of cases, users want to add GN modifier to use existing GN network, because adding the modifier first is the only possible way.
17 Likes
The behavior you are suggesting also aligns with that of materials, where you add a material slot then reuse a material or click new
6 Likes