Thanks for the detailed proposal!
I can see how this solves some problems. However, for me this does not solve enough problems to justify the new concepts and problems it introduces. Most your arguments for why this is is needed are valid and I think most (including me) will agree with that.
The only thing I don’t necessarily agree with is that you should not be able to choose between value and attribute within a node (your 5th argument). Admittedly, the current ui for this is quite clumsy. However, there are ways to solve that. For example, have a look at my Compact Nodes experiment. Having to use an Attribute Load node every time you want to use an attribute in a node seems excessive. Related to that, I think that in the future one should be able to type in expressions into all attribute input sockets.
Tell me when I’m wrong, but this proposal does not make node trees less linear than before, right?
Furthermore, it introduces the new problem that e.g. the Result output of your Attribute Math node has no meaning when it is used on a different geometry, which could be quite confusing. This is especially problematic because there is no clear definition of what “different geometry” means. Does any geometry node output a new geometry? I assume the Attribute Math node outputs the same geometry, but what about the Point Distribute or the Join Geometry node? What happens when we add a “white list” mode to the Attribute Remove node, does it remove all the temporary attributes as well?
Overall, I think this is a bit of a mix between what we have right now and a “Fields” proposal I made some months ago (although yours is arguably much better presented). I think it solves the same problems you mention (except for the one I don’t agree with) and has the following benefits on top of that:
- Normal
Mathand similar nodes can be used, no need for specialAttribute Mathnodes. - It allows breaking up long node chains that process attributes.
- The constant folding you mention becomes trivial.
- It’s easier to share node groups between shader and geometry nodes.
Since I wrote the proposal, I haven’t really worked on it anymore. Mainly because the initial feedback I got was rather negative. The fear is mostly that the concept of a “Field” is too abstract and can be confusing to most users, even though the behavior is well defined. Personally, I still see the great expressiveness and flexibility of the “Fields” proposal and do prefer it over your proposal here which does raise similar concerns.
If I had the ultimate decision power and people wouldn’t be suffering from the current workflow as much, I’d probably explore this idea a bit further and would probably prioritize it even higher than the Attribute Processor (which would become significantly less important if we had these “fields”).
However, I do think that the Attribute Processor is a good compromise that solves the most important usability problems we have right now in a good way. I’d argue that once all/most of the Attribute ... nodes are available in the Attribute Processor (and it becomes fast to use), most of the problems you mention become much less of an issue in practice. The “Fields” proposal would still add more flexibility and expressiveness to the geometry node tree, but there we would to discuss whether this is worth the added mental complexity.