I don’t mean beginners of Blender, I mean beginner of GN who is already used to the right click shade smooth .
Not hidden, but simple tasks like shade smooth just should not be this troublesome
1 Like
I agree on this.
My opinion is that , using the example of how to set shade smooth that @Eary did, both nodes should exist:
the first for more experienced users and for custom named attributes
the second for (GN) beginners and for quicker workflow without unnecessary typing.
1 Like
I think the plan is indeed to have both
https://developer.blender.org/D12687
https://developer.blender.org/D12685
Although probably not for this reason
Then how do we determine when a specific “unnecessary” node is needed ?
Do we need one node dedicated to set a vertex group, another for vcolor?
One node to set uv seam?
Another for sharp edges ?
Another dedicated to set the normals?
Ect…
This might seem like a little detail but in the long run it will fill the add menu with unnecessary nodes when there’s an already existing concept that can apply to all called “attribute set” that we are waiting for
1 Like
This is a good point, I was concerned about this as well, but I think that having as much matching between operators and nodes can be beneficial to help beginners learning GN.
After all, there is a specific operator to destructively set each of those attributes that you mentioned via 3d viewport…
Long explanation of why I think that START:
My opinion in blender in general is that every single operation that you can do distructively, should have its dual procedural operation ( before GN i used to refer to modifiers)
I think that blender destructive modeling is insanely fast when you don’t want to be procedural, and modifiers was really handy when you want to be procedural.
Unfortunately this dualism is not complete in both directions. For example I always needed procedural welding for ages, and it was added only recently.
Conversely, I often need a destructive quick shrinkwrap operator and it doesn’t exist, so I constantly have to create the modifier and apply it, not ideal.
The “dualism” was not by design but just grew in the time (but it’s ok, It’s open source software and It was contributed by volunteer mostly)
Long explanation of why I think that END
I think the add menu needs to be very well organized since as you say, the add menu will get quickly crowded.
2 Likes
@Eary Thanks for pointing out all of these:
How do you manage keep up with these? I’m having hard times to follow developer.blender.org
Do You just browse it and follow everything ?
Most of our questions wouldn’t even be asked of We were aware of those “threads”.
2 Likes
I just clicked the Watch Project in the GN project page, it will send notification of new “threads” with GN tags. Be aware if you stop checking the notification for a few weeks the number is gonna go up, lol.
2 Likes
Yes, I loved the prototype as well! It felt like the best of both worlds. According to the discussion on blender.chat from a couple of days ago between Hans and some other users, there will be no set persistent attribute node or attribute get nodes coming back. They are trying to avoid name collisions for prebuilt node groups. It is a real shame, but things could change with any luck…
1 Like
You are not the only one!
How to inherit attributes to the instances?
Another thing I tried and failed, was to build a counter loop for step effects. I haven’t found a way to store values.
1 Like
This is strange, it contradicts what I know. The Store Named Attribute node actually has a patch, And on the patch it says they are planning to get a button on the modifier for finding the place of the node in the node tree. The Get Named Attribute node It’s written on the field conversion document under the object info line. So I have been pretty sure about the two nodes being planned. But this seems to be contradicting what you said?
I can’t say for sure, just going on the discussion I had read on the blender.chat geometry nodes channel. You can read it for yourself from a few days ago. I hope I am wrong!
This patch actually has a change planned:
So it seems it is still being worked on.
And here is the get node mentioned:
I think they expect the node to be way less important than before since users most of the time can just use the field by direct connection without storing anything. But it is still planned I believe.
I agree completely with this. I’m also trying to NOT make too many assumptions at this early stage. We’ll have to wait and see.
Just as a matter of concept:
I just really hope that Geometry Nodes will not become another set of tools that has the typical problem of: “can I do this effect in Blender? […] Ah, I can’t because that node doesn’t exist yet” and having to always wait for something super specific that may not be made, because of ever-shifting prorities.
The Attributes workflow allowed you to build anything you want, many of which were not even intended to “be used that way”.
I’m expressing this concern because I’m 100% focused on live-action VFX, where flexibility is the key factor. I know that GN is developed for Blender Studio (i.e. animation), but it would be nice to tackle two problems at the same time.
3 Likes
I think this is what @jamez was referring to when i talked about the chat discussion:
it’s from October 1 (2 days ago)
OT: It took me ages to figure out what day it was, I had to scroll up the chat until i saw the Day Label, is there a quicker way to figure out the sending date of a message in the chat?
2 Likes
Well… I definitely did not saw this reply… 
1 Like
I was worried about this as well ( I mean, both not including get/set nodes, and the uselessness of feedback given in discussion)
About the Set/Get not being implemented:
Talking to @jacqueslucke here:
he actually made me realize that whenever you use a “local” named attribute in the node tree, and with local i mean that it will be never used outside the node tree/ group, it make sense to use an anonymous attribute connections.
So, basically, as long as all the nodes on which it makes sense support output anonymous sockets, we should be OK. The trade-off is that there will be a lot more noodles around. I think I suggested somewhere to create a “jump” or “wireless” node to reduce that.
For the the feedback not being considered, I guess the problem is that these thread get huge and scattered, and I fear that I’ts impossible to keep track of them for devs… We probably need a more standard and structured form of providing specific feedback on topics…
2 Likes
So, we can’t build custom particle systems with own data.
I am right?
Just to clarify, it’s already possible to get attributes from outside the nodetree and to output nodetree attributes to use in other places (like shaders for example) via the group input and output nodes.
1 Like
And that is not practical, and not intuitive.
Prototype build was better.
Please give us back the ability to get/write names attributes!
11 Likes