I noticed that two tasks were created, one for the attributes sockets Geometry Nodes 2.0 side of things and one for an anonymous attributes proposal. In the Geometry Nodes Blender Chat channel, Dalai remarked that ‘there will be two prototypes. one for geometry socket expander, one for annonymous attributes (either field or the other)’. Judging from what has been shared above, there are significant differences between this proposal and the fields proposal. I am partial to the fields one and its advantages, but my voice does not count nearly as much as those who are experts and make a living full-time with 3D work. My concern, though, would be that a decision would be made between the fields proposal and this one even before a prototype is built for testing, which I think would be sad. I would really like to test a fields prototype and hope that it gets made.
From a user perspective this could be more complicated to use than the fields proposal? As for this one you’d have to deal with value and attribute sockets, the two different versions of nodes and diving into attribute processors. If this would need to support callbacks too, for example for textures, I don’t see much benefit over the fields proposal?
@RiccardoBancone All of what you describe can work. By “keeping the attribute processor simple” I meant to keep it conceptually simple. More features can still be added to it, like writing to persistent attributes directly. The existing attribute processor patch already contains a Position Output node because we were prototyping this already.
The same can be done if it is not possible to write to persistent attributes within the attribute processor. You just need another level of node groups (so there is one node group that contains the attribute processor and set attribute node).
@GeorgiaPacific We still have to decide exactly what prototypes will be build and what they contain. I want to try the fields as well.
The main benefit is that this proposal does not need callbacks to solve the main problems that we are trying to solve. Not using callbacks does have some advantages, because the data flow easier to describe. Besides that, I agree that it will probably be less cumbersome to work with fields in many cases (especially if you need the additional flexibility provided by fields of course, but even without that as well).
Feels like it’d take more effort to communicate what attribute can or cannot be written to in a particular context, than it’d take to setup the affordances for writing to persistent attributes inside an attribute processor. I don’t think I understand how that particular limitation would simplify anything.
If I’m following correctly, you mean in order to overwrite an existing attribute (created outside the attribute processor), the processor would need to be contained inside another (but regular) node group, along with a set attribute node (for the actual attribute writing) ? that seems very convoluted to me but I may be misunderstanding.
Is this because of scopes ?
This is more or less what you answered me when I asked the implications of choosing the fields idea, and while I do appreciate your reply, I don’t really know what this entails. Will these callbacks impact performance ? do they make for code that’s harder to maintain ?
I agree with this, the attribute processor would be conceptually simple, but Its use very convoluted.
It doesn’t make node setups simpler, but it does remove responsibilities from Attribute Processor, making it conceptually simpler. Anyway, it’s not really a topic we need to discuss right now, because it’s not essential to the overall proposal. If and how you can write to persistent attributes with an Attribute Processor can be decided in more detail later if necessary (there are multiple different ways to do it).
They probably would not impact performance, the operations that are happening should still be the same, just the node group layout is different. Fields probably also don’t make the code harder to maintain compared to other proposals, hard to say. That does all sound quite good, and I agree.
However, not everyone thinks that introducing fields (and therefore callbacks) as a fundamental way of working in geometry nodes is a good idea. There is a risk that node groups become harder to understand and reason about, especially when one is trying to “follow the data”. Other than that, I’m not aware of strong arguments against fields. However, this argument is strong enough to justify exploring different ways of doing the same thing.