To be honest, to me it feels like an exachange. We would certainly gain a significant workflow improvement compared to current state of GN nodes, which as you correctly describe is usually unreadable and very slow to create, especially when one has to create tons of arbitrarily named intermediate attribute variables.
On the other hand, the Sverchok workflow seems way too alien to how procedural modeling is handled in other mainstream procedural DCCs out there, so if users were to migrate from them to Blender, or use them in the same pipeline as Blender, it’d come with a lot of pain of just how different the workflow mindset is.
I’ve made a few proposals on how to improve the workflow in the original GN thread (with screenshots):
The idea was to simply replace that grueling attribute wrangling in form of a long, linear attribute math nodes by a simple node trees similar to ones people are already using in Blender for years in material/shader editor. I really don’t think that the Attribute Processor node is a fortunate way to go about it. It’s building an infrastructure around a technical limitation, so instead of solving that technical limitation, it will actually become more entrenched in the workflow.
But I ultimately crashed into the same issue you describe: “attributes that are irreparably tied to the enigmatic “Geometry” socket”. So I started co
But then it hit me. Why not just let us construct attributes using nodes the same way we can do in shader editor, like this for example:
So that if you create any arbitrary node network, which outputs a bool/float/vector/color math function in the end, not a geometry data, then plugging it into any node which inputs and outputs the geometry data would automatically, implicitly tell GN “Hey! Let’s run this math function used as an attribute input on each element of the geometry input.”:
That way there would not be a need to “get” any geometry data to feed the purely mathematical function with. It’d be implicit, and simple.
The only somewhat technical obstacle I see is that if you wanted to feed your math function with some attribute, if you wanted to have automatically populated attribute name list, like with nodes that input/output geometry, you’d have to walk upwards in the node tree to the geometry node and fetch the attributes from there. Which could be tricky if the result of that math node tree is used in more than one geometry nodes.
But at the same time, this is not an unsolvable problem. We have somewhat solution to that kind of problem already. For example, in material editor, there’s UV Channel node which takes UV channel name as a string, yet you can apply this material to multiple objects with UV channels of different names. So I’d be fine with a limitation of not having attribute autocomplete list in non-geometry nodes and the attribute-name-getting non-geometry nodes failing (returning 0) when plugged into geometry nodes which don’t have an attribute of a given name. It’d still be worth it if we got a freedom to construct the math node networks in GN the same way we do in material editor.
I am sorry if this clutters/derails your very elaborate and carefully crafted post. The point I am trying to make is that we do not have to give up the attribute workflow in order to make it faster to use and more readable. At the same time, I do agree with you that the Attribute Processor node doesn’t feel like a right solution. It feels like turning a lack of design or a technical limitation into a feature. What I propose is to have “attribute processing” as a first class, top level feature, not decoupled away in some special node with a limited feature set.