I found another flaw about this object info node fragility: it can be abused.
If the object info node object is the same object that hold the modifier, then we have ourselves an improvised input attribute node, just like that. :- D
8 Likes
There’s broadly 2 camps in OSS: Liberal - think MIT or 3-clause BSD licensed projects. And the authoritarian - GPL, LGPL etc. Which do you think this is?
2 Likes
Uh oh
Just wanted to do an innocent joke, not starting to a wild fire.
I’ll edit this
1 Like
Gosh, I love Ton, but this is reminding of the the single column UI shift for the modifiers and the subtabs. I use modifiers all the time in every file, and I am still nowhere near as fast as I was when with there were two columns and no subtabs when more of the properties were exposed and just a click away than multiple clicks away. I kept arguing how counterproductive it is for those that use modifiers all the time…
I would just like to understand better what @zorro-weaver mentioned a few days ago. With their current proposal, is the only way to input external attributes via the modifier stack? Again, from a UI point of view, this will be slower going back and forth between the node editor and the property editor. The attributes should have a way to be accessed edited within the node editor itself. If not in a super obvious node, then in the sidebar maybe…
8 Likes
If removing named attribute is even considered for some reason then whats gonna happend to custom attributes?
3 Likes
Carreful on your phrasing
you forgot the important precision “within nodetrees”
concept of encoded custom attributes is still here, they just became second grade citizen removed from where all the action is
1 Like
Hey @Zuorion
Currently, we can’t read/write attributes within nodetrees anymore. The goal of this topic is to talk about the nodes that lets us access any attributes.
Currently, it’s done externally in the modifier interface, please see more information about the new way here.
I also did a before-after comparison, perhaps it can help you understand what we are talking about 
7 Likes
Yes i understand that.
**within
Oh, Ok. I missed that Group Input works like Attribute Get, and Group Output works like Attribute Set.
I got mislead by that with no name entered manualy it does not store it to default name so applying modifier does nothing.
I’m watching Blender Daily while writing this:
I know this thread was created because of the sudden disappearance of Named Attributes (which is still tough to accept), but I have to give a round of applause to the devs for the amount of nodes they added in GN in the past week.
4 Likes
What makes it even more confusing is that the Group Output can have a different name than the attribute itself. I still don’t get all of this 
6 Likes
One_name there is the socket name, Another_Name is the actual output attribute name. I think it makes sense that blender doesn’t force those two names to be the same. Personally my socket names will most of the time be more generic than attribute names
4 Likes
I totally agree, but even now that I used the current GN only for limited testing purposes this confused me so many times already. Maybe it would help (at least me) if by default the socket and the attribute shared the same name if you connect the output and only if you want / need you could give them different names.
I know It’s meant to clean up and simplify everything, but somehow it forces you to look at several places in the interface to give you an idea where your attributes are coming from and going to.
I still mourn the simplicity of named attributes while I’m trying to find the beauty of the new system.
4 Likes
I agree, that is confusing.
I’m also not sure I have the full picture on why it has to be like this. But what’s intuitive to me is to define the name in the nodes directly. If we want to write on an existent map, then we should probably be using that in the nodes directly as well.
2 Likes
Maybe this:
could help to clarify this
?
Or, “Socket Name” instead of “Label”
11 Likes
The current GN node tree works independent of custom attributes an object defines. (Except basic built-in types like “position” or “index”.)
It also means, that you could feed the same GN modifier inputs with different custom attributes.
E.g. … Blender let us define a lot of UV channels. A UV channel could have any name, like “UVMap” or “UVMap_Seams_Surrounding”.
A GN modifier which uses a UV input does not know details about which UV slot is plugged into the modifier.
3 Likes
Same with:
-get object
-get collection
-get material
-get image
-get texture-data
-future get audio data
-future import object nodes
-future ability to create new data from a nodetree.
-ect…
This is not specific to attributes, this is happening whenever your read and write any sort of data within a nodetree…
1 Like
Okay stepping in (no context) about the script node in fields that left me with some doubts.
This is a dessign thought for not that much, and from a person who does not know the exact way nodes work internally. Please forgive any error that I may have made, and don’t hesitate to tell me about it 
Assuming Python/Cython, the script node could generate a script of a class, instance of an abstract Script_node class
The class would be abstract for the programmer to fill 2 dicts: inputs[str, type*] and outputs[str, callable]
Also, for simplicity sake, an attribute of that abstract class could be another types[str, type*] so that the programmer does not need to look up any possible types.
*type being an object representing a GN type
Once any output is connected to a valid path in the nodetree, all functions in the dict are checked (if they are connected) and they get called in order.
It would make use of the feature in Python that all dicts are ordered, and so it would be a predictable way for programmers to know the order that the functions will be called, allowing them to reuse generated data in a more “intuitive” way.
All attributes would be set as attributes of the class, using (again) the order and the explicit type marked by the programmer.
As so, the inputs and outputs will be always known, and typed by the node owner. Also, for the output type I don’t have a strong opinion, but type hinting
def foo() → types.float:
could be an answer because it can be checked and asserted in runtime.
var my_new_variant
function_name(input_variable_name):
internal_variable_name = input_variable_name
return internal_variable_name
another_function_name():
internal_variable_name = function_name(my_new_variant)
return null
1 Like
What’s going to happen to attribute unification? Vertex groups, vertex colors, uvmaps, and shapes should all be one generic attribute type. If separate nodes to set and input these things are implemented, imagine how complex it would be? Or are we still going to have to set these with hardcoded names in the modifier interface?
A solution that would be satisfactory for both parties might be possible. It would be share-able, usable in the nodetree, and not string based.
Use get and set nodes. But rather than pointing to an attribute by string, point directly to the data with a new socket type. Only existing attributes can be modified, and built in attributes are greyed out in the list to show you cannot delete them. These would be dynamic and share-able, if the attribute name is changed, the name is changed on the node. If said attribute is missing, the socket turns red until it finds one, just like shader nodes.
But what about primitives, you ask? Primitives can have their own collapsible attribute tab in the node.
Put it all together and:
- Share-able
- Doesn’t force you to use modifier
- Works in nested nodetrees
- Not hardcoded names, dynamic
- Flexible, users are not restricted to a workflow
- Simple and intuitive
2 Likes
Named attributes will be back for 3.1, normally 
In the meanwhile we will all need to do waste our time creating new group inputs/outputs, duplicating and CTRL+H inputs, and going in and out of the modifier tab & N panel just to access a bunch of named attributes. It’s also not very handy if we need to create default attributes, we’ll need to systematically encode the same name upon each modifier initialization…
3 Likes