Attribute Edit Node: Make attribute workflow more intuitive
I propose the
Attribute Edit Node
: It is a mix between a group and a frame, with dynamic attribute sockets inside
Benefits:
-
Visual representation of information flow
Attributes are always bound to geometry/in the geometry data itself 🡒 this should be represented in the node tree. Let the user see where the attributes go with node noodles. -
Use of normal math nodes, parallel workflow
By allowing the use of "normal" nodes inside the Attribute Edit node the workflow would be more consistent with other node editors (eg. shaders) so learning and understanding attribute editing would become much more accessible. Currently, manipulating different attributes on the same geometry has to be done one-after-the-other, which forces a visual order that is not needed. This is also what Erindale mentioned here .
(Internally, these nodes had to function context dependent, operating on a single value or on a list of values, similar to what Jacques Lucke proposed here )
-
No more temporary attributes
Currently, when working with several Attribute Math nodes in a row, you either have to use temporary attributes that are no longer needed in the end, or override the same attribute repeatedly making the attribute name not reflect the actual value.
Temporary attributes clutter the attribute list or have to be deleted manually. Overriding existing attributes is error-prone. -
Visual error feedback
When an attribute is not found or any other error occurs, this can be shown directly on the problematic node noodle or socket. -
Frame what belongs together
Currently, a node tree commonly consists of sections where you only manipulate attributes before then joining or doing something else with the geometry. Framing these sections inside a super-node would help to organize the nodes. Single attributes should not be accessible outside this frame.
Empty Attribute Edit Node:
This is what an empty
Attribute Edit
node could look like, without unmodified attributes collapsed (which should an option).
Inputs and Attribute Fill
Instead of using an
Attribute Fill
node, one could simply plug a value into the corresponding socket. New attributes could be created, similar to node group sockets.
Rule: Noodles can go in, but no noodles are allowed to go out. This prevents the user from plugging attributes from one geometry into another geometry (which wouldn't work of course).
Here's a more complex example (hanging sheets from
Still Life by Erindale Woodford
) where you can see that manipulating attributes is commonly done in one long linear queue of nodes. Current:
With
Attribute Edit
node: No temporary attributes, no forced linear order
Details
As far as I know, the attribute list is only evaluated when the node is connected to the Geometry Modifier output. I suggest letting the user also create attribute sockets by hand for the case when the node is not evaluated (similar to node group sockets) but immediately remove unknown attribute sockets which are not connected to another node.
This way, known (evaluated) unmodified attributes could dis- and reaper dynamically without disrupting the user.
A few other nodes would have to be adjusted/added for this workflow. In the example above, I mocked the missing nodes with groups in light gray.
If you think "Sounds cool in theory, but how would ..." please leave a comment and let us discuss!
2 Comments
take my upvote and my hope that this will be a thing. very much needed to make attributes more comprehensible
This issue will probably be addressed differently .