There was this proposal some time ago Hardcoded Attribute Names Removal [Proposal]
4 Likes
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.
4 Likes
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 :
2 Likes
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:
“Do you still want access to named attributes from an nodetree in the new field system?”
- Yes, i like having the possibility to interact with named attributes
- No, i only want anonymous attributes
0 voters
4 Likes
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.
3 Likes
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.
2 Likes
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.
18 Likes
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.
3 Likes
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?
10 Likes
I forgot about this, that’s a really good point.
3 Likes
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.
1 Like
I came to say that I totally agree.
It’s ok to have specific set/get nodes for some things, but a generic Get and Set node should be created, we cannot depend on developers giving access to every specific parameter or attribute an object could have in the future, we will end up with thousands of nodes, IMHO it’s a non-sense.
A sub-set of them could be created, on behalf of high level users, but the generic nodes must be present, they are key.
P.S.: BTW those high level nodes could be present as simple groups pre-generated with the generic set / get nodes, it should be that way if the original spirit of GN is still present:
High Level for users
Mid Level for Tech Artists
Low Level for TDs
23 Likes
Yes… I feel the same.
The Set could have some warning if you use a built-in name attribute (but let you use).
Also, having a lot of nodes built-in, in fields approach, is good because discoverability and building less vulnerable systems.
6 Likes
Correct me if I’m missing something, but how are we supposed to talk to shaders without being able to explicitly set data?
Removing names seems like an anti-pattern, especially if the plan is to implement tree shaking anyway. The idea seems to be letting the computer manage what is saved and for how long, but there is no reason to get rid of names to do that, and sometimes I do want to insist that something is kept for later use (and I’ll need a name for later). Following data flow is easier with nice lines, but names are the primary documentation, especially for ‘distant’ references. The ideal for me would be being able to give any output field a name, and being able to type that in a box where I want to use it, and then the computer draws the line (as well as just dragging). The underlying implementation could completely ignore the name, but names are extremely important to making understandable code.
Some things should be named, many intermediate values should not. Deciding what should be named and what should be inline is one of the few places where the python ethos of ‘only one answer’ fails miserably, and even python doesn’t try to enforce it. A graph without names is effectively a giant line of code without comments or any named intermediate values. That is regarded as horrible practice in any language, and should not be the default never mind the only option.
Sorry this is so negative, you guys are doing a great job with it and fields are a massive improvement. I just strongly believe naming things should be expected, and that we need breakouts (which attributes are). Removing them is a major design error that needs to be dealt with early.
6 Likes
Forgive me if I miss the point of your post, but you can still create attributes that can be used in Cycles shading (this is in the rendered view for Cycles).
By all means, this is actually less cryptic and more straightforward than figuring out what the ‘attribute convert’ node is and how to use it (as conversions here are automatic). The way to get and use the new attribute in Cycles meanwhile is identical to 2.93.
Perfectly fine. But now imagine that same node tree with hundreds of nodes, where the color conversion writing the “Color” attribute is all the way to the left of the tree. Hundreds of node in between. You have to drag a cable all the way across to the output of the tree to get this attribute to be present on the geometry and accessible in shading.
Now imagine that not only “Color” but several attributes are written.
I know I can duplicate the “Group Output” node as many times as I want BUT it always contains and shows ALL of the outputs. If there are dozens of outputs this will look awful and clutter the whole tree with huge nodes. A simple “Set Attribute” will do the same job, take no space, would be clearly named and the attribute will of course show up in the modifier interface so no one ever forgets about it and everything is fine.
2 Likes
There was some discussion about the whole attribute get/set talk that is going on right now in this thread.
This is just a portion, for full context please visit the blender chat “geometry-nodes”. That being said the developers have clearly seen feedback from here. This does not necessarily mean changes will be made towards this, merely that the comments here have been noticed and understood.
7 Likes