Fields and Anonymous Attributes [Proposal]

No

there’s still time for 3.0 release for get/set nodes
time is not a problem here
the nodes are ready and we’re already implemented for the prototype, there’s tasks waiting to be pushed

3 Likes

Wait… 3.0 isn’t closed?
New stuff can still be added?
There’s still hope? :open_mouth:

Yes,
porting elements from the prototype idea to 3.0 is still allowed in bcon2
therefore this can be decided in the upcoming week

1 Like

Well… finger crossed :crossed_fingers::crossed_fingers::crossed_fingers:

I would argue for changing the build process so every RNA property becomes a named attribute by default. Of course that would need to be done carefully to avoid name collisions and maybe some properties need to be hidden for technical reasons. But basically if it is accessible as a property via python it should be a named attribute. There have been many times when I’ve hit a bug in other software that I could work around because the attributes causing the problem can be named and changed even if they aren’t exposed in the interface. It makes zero sense to me to keep most of the attributes out of reach – the whole power of attributes is to let you change the data however you need to so you can work around limits in the interface. It’s not the devs job to protect users from themselves – power users can manage the attributes as they need. Without named attributes, GN is just a toy

6 Likes

Quote from from @jacqueslucke :

4 Likes

Do not agree.
Recently I tried to make a particle simulation with remeshing modifier on top of it. While this technic works fine in general it does not produce any motion blur, cause this attribute isn’t taken into account in the Remesh modifier.
As a way around I tried to sample the particle’s velocity attribute in the geometry nodes and store this attribute in vertex color.

I couldn’t.

Mh … please do not be that selective if you cite JaquesLucke. :wink:

A node group created by someone else uses named attributes and is accidentally overwriting your attribute. In that specific case, the node group should just have used anonymous attributes internally. If it wanted to expose an attribute to you, it should have allowed you to choose the name.

So, generally speaking, when you build a node group that others should be able to use without worrying about attribute name collisions, then you should not use named attributes inside the node group.

As far as I understand, the main problem is that groups would make/access a named attribute globally. If there is some kind of namespace for each group/modifier, there would be no danger that a named attribute could overwrite something which shares the same name.

In a studio setup with many people working and sharing data, there would be no way to guarantee that Blender would work reliably, when a ‘global’ attribute name clash could cause problems, which cannot be predicted and are hard to track down.

I guess, at the heart of the shareability issue of named attributes (means, nesting groups and chaining modifiers could work reliably) are groups which try to write/access “global” attribute names.
Groups do need to act like a scope for “local” attribute names. With group based attribute scoping, groups which use named attributes would be shareable.

Before people all around the world tweak global attributes from within groups, it does make sense that groups do get scoping for named attributes first.

5 Likes

Jacques agree with Hans

Capture d’écran 2021-10-11 145427

best would be that they debate with us, unfortunately that’s not their job

In a studio setup with many people working and sharing data, there would be no way to guarantee that Blender would work reliably, when a ‘global’ attribute name clash could cause problems, which cannot be predicted and are hard to track down.

Why are you making the point that using globals is bad?
We all agree very clearly on this, what is debated is removing globals entirely.
Globals were a very important part of geometry nodes, same in Houdini, removing them from nodetrees entirely like this with no compromise is not reasonable.

what dalai is proposing is the equivalemnt of throwing a baby with the bathwater.
i like my baby
don’t throw it away please
if you don’t like my baby just don’t look at it and ignore

1 Like

During the 2.93 era, share-ability was fine because everyone used attribute remove when applicable in a group. I would like to know what problem there is now that wasn’t there before. Are they afraid that everyone will suddenly get messy because of fields?

1 Like

some users not being smart when making their nodegroups :roll_eyes:
that’s seem to be the real problem? devs are trying to create padded walls to protect beginners?

everyone used attribute remove when applicable

also that’s a very bad practice in general
best to use locals variable to do this
they didn’t exists back in the days

still, having locals do not mean removing globals entirely…

Why are you making the point that using globals is bad?

Its not globals per se, but when globals are used in a way which destroys modularity.

Scoping means, to have a protection layer. local variables are defined inside that layer. With something like group based attribute scoping, there won’t be a name clash of named attributes across groups/modifiers, and there would not be sharing issues.

Yeah, of course.
this is a classic global problem

i agree that they can be problematic, but, again, removing them entirely like it’s no big deal is not reasonable thinking

look at python, we can read/write globals from the scope of a function too.
this is not a problem from python creator, if it cause a problem, that’s user fault.
the language shouldn’t impose users how to behave, if they do the mistake of using globals in a case where it was not necessary and it is causing issue, that’s their problem, they should have read the documentation!

Note that the name clash is still a problem, this proposal is not fixing any name clash, because globals can still be written as group output.

1 Like

Python scopes work. A Python-user could access globals, but it is optional. He could use local variables happily without touching globals.

Blender groups lack scopes. There is no choice to make named attributes local. They are globals per se.

The idea is; proper scopes for Blender node groups could enable local attributes.

Note that the name clash is still a problem, this proposal is not fixing any name clash, because globals can still be written as group output.

Ehm, are you sure?
There is a baby flyyyying out of the bath.

Clashes between groups and modifiers would be fixed. Thats the discussion on shareability about. The user does not need to know if the GN modifier designer uses an attribute name used by another modifier.

You know
I’m not trying to force everyone using on globals
i agree with you,
it should stay optional

yeah look

problem is still here
shade_smooth is “clashed”
and that’s not even a bad thing, it let user interact with builtin attributes
field prorotype way let users interact with builtin attributes more freely
right now it’s feels like a prison
we need to follow the line maked on the ground for us
field prototype way is freedom
new way is full of restriction

These

are simple solutions to be more free
if you do not want to be free do not use them that’s all

You actually show an example how an end user could use a modifier to write to a ‘global’ attribute. Could you explain me, how does your example has an impact shareability of modifiers in general?

You actually show an example how an end user could use a modifier to write to a global variable

well first of all it’s not really a global it’s a return value written in global space if outputted by a modifier
the get/set nodes are the ability to create/write global from function’s scope
i don’t get your second Q

Just to note, named attributes are still used to great effect by way of the group input (in attribute mode) as well as the group output (which is always an attribute field. Fields in general are great for those who expected Geometry Nodes to be like a ‘Cycles’ for geometry, it is a lot more straightforward from an artists’ perspective.

However, I do understand the obvious utility of having dedicated get/set nodes that manipulate attributes without exposing them to the modifier UI (as a feature for power users who know how to handle such a thing in a controlled manner). Perhaps they could be under a menu entry labeled ‘advanced’ or ‘low level’ to emphasize their trickier nature, much like what we already have with various other features that are not recommended for a new user’s learning project.

1 Like

I must disagree, for me the attributes feels like secondary citizen in the modifier interface.

2 Likes

Well, going into the semantics on how various aspects of a feature can go from first class to second class (and visa versa) would open a can of worms that would no doubt bury any feedback that is actually useful for the developers (since I do not think we will be able to come to a consensus at all).

There are a subgroup of users out there who think that FOSS should not even try to innovate or do anything differently at all (as the BF is doing with fields), they’d rather the world of FOSS just shamelessly carbon-copy everything produced by commercial vendors (without even considering if there is a better way of doing things). I am all for the inclusion of a set of lower-level nodes for power users and even TD’s, which I think should provide a good balance that satisfies those who tend to take a more analytical and/or technical approach to making 3D worlds.

1 Like