Looks great!
You can access the single components, albeit only indirectly with the vector math node and it’s not that inconvenient when packaged into a node group like on the left.
You still have to feed them back into the position though which also requires two nodes at least…
An expression node would really be great, but I disagree that the node math itself is not the way to go. I think the shader nodes have demonstrated, that node math is a pretty viable approach.
For me the issue currently is, that the attribute operations really don’t seem to be integrated well into the node interface.
Yes, they are nodes, but the node connections don’t really convey the same thing they do in the other node editors.
The noodles - as a visual representation of the data flow - help me as user to understand what is happening in the script. But in this case the data I’m interested in - meaning the attributes - isnt’t actually represented by the node connections.
I get, that the attributes are inseperable from the geometry, and currently the node connections are more a transfer of the attribute context than the data flow.
The node graph itself doesnt’ really help me to understand whats happening or how things relate, other than that certain operations happen before others.
Except for separating and the merging geometry, which means splitting things up into seperate contexts that can’t even interact until they are combined again, is always linear. Even though whats actually happening with the attributes can be wildly interconnected. But that interconnectedness isn’t represented with the nodes at all.
The only way to currently get what’s happening is to go through the nodes one by one and trying to figure out, where attributes come from and how they are used. It also doesnt help, that we currently have no way to check, where attributes are used that.
This isn’t a gripe with the system itself, that is shaping up to be really awesome, but rather the current state of the interface. 