You also read this?
It was not my intention to push people to define all their attributes outside GN nodes. Why present it that way?
Please spare me the polemics. If you think inside-custom-attributes are important, just give useful examples.
Chaining is an independent way to organize geometry processing. I was surprised to see that it already works and could be used.
Hey
Sorry Iâm criticizing the design concept in your quote, not you or anyone directly of course 
I may be mistaken but isnât this the current plan already?
Itâs not that you could do something you canât do otherwise, at least in theory. It might be in practice though as being able to store and recall attributes is important for being organized, working more comfortably and seeing whatâs happening more clearly. Without it, situations that could be clearly read otherwise, will become a bundle of wires. Sometimes connecting an attribute directly is the best and most intuitive. Other times using an attribute is the best.
Reading your answer, to me it appears that it is mostly about how to organize a node tree and keep it readable.
There are different tools, like groups, reroute knots, frames. I guess, having data-flow connections visually different from field connections does have the purpose to improve readability of a node tree.
Custom attributes inside GN node tree could do both. Improve the way a node tree is organized, and the contrary. Handling custom attributes could be organized, but they also could be used messily.
It is up to the user, how he uses the tools.
Just to note, unlike the shader nodes, every component on a mesh can be handled and edited by more than one geometry node program (ie. what multiple geometry node modifiers give you).
I could understand why the devs. would want us to take advantage of this fact rather than the user forcing every possible operation into one monolithic tree, especially in the context of flexibility in things like enabling, disabling, or stacking effects, though it may not be the most desirable for things like complex generators.
Also, let us not forget that while there is indeed an important place for user-defined attributes, keep in mind that adding attributes to a mesh is not free as far as processing power goes. In the 2.93 implementation you actually had to learn to offload the attributes (by a node which removes them) you only needed temporarily before doing more operations, I could in fact see some more low-level attribute writing stuff going in for power users, but please note the official implementation is less than a month old and needs time before an accurate assessment can be made.
Hi, hereâs an idea about this:
All attributes that are not explicitly exported as an Output could be auto-deleted at the end of the graph. These would make them temporary, in-graph attributes.
About the multi-modifier workflow, Iâm all for having that ability and thatâs great, but we also can make a whole scene within a single node tree now, and thatâs also great. I wonât speculate how the developers want users to work, but I think itâs a good path to allow and encourage unified graphs.
There was this proposal some time ago Hardcoded Attribute Names Removal [Proposal]
This is somewhat funny to me. I understand where youâre coming from but the number 1 complaint about GN in 2.93 with the named attributes workflow was that it was unreadable, because the attributes dataflow was not visible as nodes but instead was hidden in the names of the attributes.
I think I disagree with you here. I think that a very long node is still more readable than an attribute name somewhere in the start of the tree which corresponds to an attribute name somewhere on the other side with no connection between them to let you find it.
Donât get me wrong, I still liked the possibility to get/set custom attributes and do direct calculations on them and it would be a shame if that completely disappeared in the new system. I donât really get why all the attribute manipulation nodes need to be removed completely. The attributes are still there after all. ( Though I can understand wanting to remove nodes which are really redundant. Maintaining is not free after all. )
In the previous system I had some nice experiments where I multiplied a vertexweight with the normal and added that to the position. I donât really see (yet) how I could do that with fields. But I hope itâs just because I donât fully understand it yet.
Thatâs not really what I meant : Iâm not advocating the use of the old attribute manipulation nodes (attribute math, attribute color ramp, and so on). Theyâre irrelevant now because all your attribute calculations can be done with regular nodes, taking advantage of the awesome flexibility of fields, BUT I see added benefit in storing them by name for later retrieval. (benefits in readability and communication of intention, mostly, which is important when you pass down your work to somebody else)
Without get/set nodes you need to go through the modifier interface (thatâs what weâve been discussing for the last few posts) : you have to create a group input, and go in the modifier and name it the same as your vertex group. Then it goes like this :
After some search we can see more explanation in this task too, this is more than a month old.
https://developer.blender.org/T90864
we can read the following
âI still donât see why we need to have generic attribute read/write nodes with hardcoded names.â
âA custom-made nodegroup can be used as a modifier for that. Leaving the hardcoded names all outside the nodegroup.â
So it flew under the radar as folks who tried the prototype had still access to them
Quick Poll:
Maybe âDo you still want access to named attributes in the new fields system?â is a better way to phrase it. Thatâs how I voted.
There are already commercial courses and tools that rely heavily on the notion of named attributes. It might be prudent to throw a bone to those creators by allowing them more leeway in adapting their works to 3.0. Not necessarily advisable or optimal, but prudent and respectful.
Note that this task needs to be read in context.
This was posted before the " Hardcoded Attribute Names Removal" proposal, actually I believe that proposal was posted specifically because of this comment in the task. The end was that people did not like it and the proposal was not selected.
Then later Hans posted his ââ Shareable Named Attribute Nodeâ proposal, which in my understanding was to offer a middle ground. People seemed to be clicking a lot of likes and there seemed to be no objection. So they ended up chosing the shareable proposal.
So I donât think they are not going with the removal, no need to rage on that now I think.
In theory, a get and set attribute nodes could replace all of these individual input and set nodes, while respecting the fields concept.
Iâm not suggesting to actually replace them. The individual nodes are more high level, easier to learn, easier to use and make a more readable graph.
But in the end, being able to set/get any attribute is more sustainable and scalable. Does there need to be a node for every single attribute in the software? Every time an attribute is added, a node needs to be created as well? What about working with custom attributes from, e.g. alembic or usd?
Itâs nice to have a consistent, generic solution for any attribute, which is also a nice way to store Variables per element. A great tool for users to have in their workflow.
Because that workflow is supposed to have an attribute processor, we never got it. Instead in order to fill up the attribute processors role we had a whole bunch of attribute nodes. Idealy you have an attribute processor doing most of the lifting, and you just occasionally use an attribute node like the ones we had.
The idea that the fields way of doing math is better is not in question, it is. The flow of what is happening is clear and easily followed. The attribute processor would have allowed for that, as it is a node that drops down to a lower level (like nodegroups) where you can then do math just like fields.
I know attributes can still pop up here and there without connection, thus some confusion can occur, but I think of that as more of a positive, it removed a lot of UI hassle and keeps things clean and elegant.
Thanks. That clears it up somewhat in my brain ;-).
Well, you canât keep everybody happy I guess. Most people really hated the invisible dataflow through attribute names it seemed. Maybe the attribute processor would have solved that, but I had the feeling at the time that adding another level didnât really help readability either. But for sure each system has itâs pros and cons.
How working new geometry proximity node to store info to Col attribute or vertex group?
This is probably a good solution.
We must be able to manage our own attributes in the node tree. Being able to have them outside is a good thing, but for some large node trees, it complicates things.
Fielsâ original proposal was much better.
Another point:
Itâs great that you can set attributes in modifiers, but having them stack-exclusive has some more limitations. For instance, if I want to use this geometry nodes tree within another, do I have to make more sockets and always set it at the top of the chain? This makes even clean trees messy in the end. Rather than having to read and set only the relevant information, we have to go all the way up and look at what is affecting what.
Besides, wasnât the nodes system made to replace the stack system? Why are we forced to use it?
I forgot about this, thatâs a really good point.
A big part of the Everything Nodes project, is to convert the modifier stack to a much more powerful Geometry nodes system. This document serves to explain how this will work more precisely from a user point of view.
Geometry nodes encompass what Modifiers used to be, but where modifiers only allowed you to modify geometry, Geometry nodes also allow you to create geometry.
The first two paragraphs of the original design task.
