Attribute Processor for UX improvement #85655

New Issue

Dalai Felinto · 2021-02-15T14:26:39+01:00

Dalai Felinto commented

2021-02-15 14:26:39 +01:00

Plan of Attack

Support changing the data type of a group input/output socket.
New nodetree type with domain property, and treating geometry in/out sockets differently (they are not shown inside.
Group input/output socket option to expose it outside or leave it only inside.

Design

A new nodegroup type that supports attribute dataflow. This is added as a node and created from inside out (as oppose to the existing Node Group where you first group existing nodes).

The domain (point, corner, ...) is exposed outside as a node property.
When creating new input/output sockets users can type the name of the attribute directly.
This uses the attribute search
This creates a new input/output with the default value matching its name.
Connecting sockets to the Group Input/Output nodes also work

Changes that affect other node groups as well:

The node group datablock show go to the sidebar.
The socket input/output can have its type changed (Color/Geometry/String/...).

{F9887618, size=full}

Background

While the attribute workflow is a powerful way to do complex operations, and its generality will make it useful in a lot of situations, but common feedback is that node trees will become very linear, because temporary values must be stored in attributes, rather than passed around with node links.

This is an example of a typical more complex attribute operation. While just a few attribute nodes are simple and easily readable, this sequence of nodes is hard to understand.
{F9805345, size=full}

Key Concepts

Scope This node only changes attributes, and it can only read attributes. It is not a change to the entire execution method of geometry nodes.
Visually, this is a variation of a node group:
It has two different kinds of inputs: Group Inputs and Attributes Inputs (strings) - besides the Geometry It has no outputs - besides the Geometry
** When collapsed more attribute inputs can be visible (the ones not exposed).
Attributes are added explicitly on the left side of the node, it does not automatically populate with all available attributes.
Domain selector on the left side This defines the "element" part of the processor idea. Every input attribute will be read with this domain, with interpolation if necessary.
Data type selection Because it is not possible to know the data type of every attribute statically (without executing the node tree), this information needs to be stored by the node for each attribute.
When you add a new input attribute with the + button, the data type is chosen based on the data stored for "attribute search". After, you can adjust the input data type. I propose putting this option in a drop-down next to the attribute.
** You can decide to expose the attribute as an input attribute visible/editable when the node is collapsed.
The node can use the function nodes evaluation system, so any node supporting that can be used (currently only nodes available in the geometry node tree).

### Plan of Attack - [ ] Support changing the data type of a group input/output socket. - [ ] New nodetree type with domain property, and treating geometry in/out sockets differently (they are not shown inside. - [ ] Group input/output socket option to expose it outside or leave it only inside. ### Design A new nodegroup type that supports attribute dataflow. This is added as a node and created from inside out (as oppose to the existing Node Group where you first group existing nodes). * The domain (point, corner, ...) is exposed outside as a node property. * When creating new input/output sockets users can type the name of the attribute directly. * This uses the attribute search * This creates a new input/output with the default value matching its name. * Connecting sockets to the Group Input/Output nodes also work Changes that affect other node groups as well: * The node group datablock show go to the sidebar. * The socket input/output can have its type changed (Color/Geometry/String/...). {[F9887618](https://archive.blender.org/developer/F9887618/mockup-processor.png), size=full} ### Background While the attribute workflow is a powerful way to do complex operations, and its generality will make it useful in a lot of situations, but common feedback is that node trees will become very linear, because temporary values must be stored in attributes, rather than passed around with node links. This is an example of a typical more complex attribute operation. While just a few attribute nodes are simple and easily readable, this sequence of nodes is hard to understand. {[F9805345](https://archive.blender.org/developer/F9805345/image.png), size=full} ### Key Concepts * **Scope** This node *only* changes attributes, and it can only read attributes. It is *not* a change to the entire execution method of geometry nodes. * Visually, this is a variation of a node group: **It has two different kinds of inputs: Group Inputs and Attributes Inputs (strings) - besides the Geometry** It has no outputs - besides the Geometry ** When collapsed more attribute inputs can be visible (the ones not exposed). * Attributes are added explicitly on the left side of the node, it does not automatically populate with all available attributes. * **Domain selector on the left side** This defines the "element" part of the processor idea. Every input attribute will be read with this domain, with interpolation if necessary. * **Data type selection** Because it is not possible to know the data type of every attribute statically (without executing the node tree), this information needs to be stored by the node for each attribute. **When you add a new input attribute with the `+` button, the data type is chosen based on the data stored for "attribute search".** After, you can adjust the input data type. I propose putting this option in a drop-down next to the attribute. ** You can decide to expose the attribute as an input attribute visible/editable when the node is collapsed. * The node can use the function nodes evaluation system, so any node supporting that can be used (currently only nodes available in the geometry node tree).

Dalai Felinto commented

2021-02-15 14:26:39 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Dalai Felinto commented

2021-02-15 14:26:39 +01:00

Added subscriber: @dfelinto

Hans Goudey self-assigned this 2021-02-15 14:29:12 +01:00

Hans Goudey changed title from ~~Attribute "Container" for simplified nodetrees for UX improvements~~ to Attribute "For Each Element Frame" for UX improvement

2021-02-15 21:59:34 +01:00

Hans Goudey commented

2021-02-15 21:59:34 +01:00

Added subscriber: @lone_noel

Andres Stephens commented

2021-02-16 01:57:33 +01:00

Added subscriber: @AndresStephens

Andres Stephens commented

2021-02-16 01:57:33 +01:00

Could be a nice replacement for groups, or to add this kind of IN/OUT nodes inside of groups, but I don't think it's a good alternative to what groups provide. Though for looping structures, this would make sense.

Miro Horváth commented

2021-02-16 14:21:12 +01:00

Added subscriber: @MiroHorvath

Charlie Jolly commented

2021-02-17 16:10:30 +01:00

Added subscriber: @CharlieJolly

Charlie Jolly commented

2021-02-17 16:10:30 +01:00

In #85655#1112593, @AndresStephens wrote:
Could be a nice replacement for groups, or to add this kind of IN/OUT nodes inside of groups, but I don't think it's a good alternative to what groups provide. Though for looping structures, this would make sense.

The For Each Element Frame title suggests looping but I'm not clear if this task is suggesting it is for looping or not. Can this be clarified or will that be another task?

> In #85655#1112593, @AndresStephens wrote: > Could be a nice replacement for groups, or to add this kind of IN/OUT nodes inside of groups, but I don't think it's a good alternative to what groups provide. Though for looping structures, this would make sense. The **For Each Element Frame** title suggests looping but I'm not clear if this task is suggesting it is for looping or not. Can this be clarified or will that be another task?

Hans Goudey commented

2021-02-18 04:54:47 +01:00

This isn't about looping. It's about using a different evaluation method to change attributes on a geometry.

Kenzie commented

2021-02-19 17:37:45 +01:00

Added subscriber: @KenzieMac130

Kenzie commented

2021-02-19 17:45:15 +01:00

How about the name along the lines of "Attribute Processor"? Since the user is designing a network which processes attributes in a sandboxed environment.

I think this name also adapts well if the process was done in parallel since a "for loop" concept might make the user expect or want some sort of feedback from a "previous itteration" which in this case cannot be guaranteed.

How about the name along the lines of "Attribute Processor"? Since the user is designing a network which processes attributes in a sandboxed environment. I think this name also adapts well if the process was done in parallel since a "for loop" concept might make the user expect or want some sort of feedback from a "previous itteration" which in this case cannot be guaranteed.

Hans Goudey commented

2021-02-19 18:07:01 +01:00

I like that name a lot, thanks!

Hans Goudey changed title from ~~Attribute "For Each Element Frame" for UX improvement~~ to Attribute Processor for UX improvement

2021-02-19 18:07:48 +01:00

Brecht Van Lommel commented

2021-02-19 20:16:01 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2021-02-19 20:16:01 +01:00

This seems quite similar to what we need for new texture nodes #54656 (Cycles/Eevee texture nodes for modifiers, painting and more). I imagine you'd want to be able to access the same kinds of texture nodes, color ramps, etc here too. The big difference being that in this attribute processor design the attributes are passed in explicitly, whereas in texture nodes they are brought in through nodes, either explicitly by name or automatically by some node types. So hopefully both systems can shared a lot of code in the end or even converge to the same thing.

An alternative would be to support evaluating expressions. Again not quite the same since they only evaluate to a single value and the UI is quite different, but in many cases it's a solution to the same problem. We already have an implementation for drivers:
https://developer.blender.org/diffusion/B/browse/master/source/blender/blenlib/BLI_expr_pylike_eval.h

This seems quite similar to what we need for new texture nodes #54656 (Cycles/Eevee texture nodes for modifiers, painting and more). I imagine you'd want to be able to access the same kinds of texture nodes, color ramps, etc here too. The big difference being that in this attribute processor design the attributes are passed in explicitly, whereas in texture nodes they are brought in through nodes, either explicitly by name or automatically by some node types. So hopefully both systems can shared a lot of code in the end or even converge to the same thing. An alternative would be to support evaluating expressions. Again not quite the same since they only evaluate to a single value and the UI is quite different, but in many cases it's a solution to the same problem. We already have an implementation for drivers: https://developer.blender.org/diffusion/B/browse/master/source/blender/blenlib/BLI_expr_pylike_eval.h

Hans Goudey commented

2021-02-19 20:31:08 +01:00

Right, I believe Jacques has been talking about expression node for a while. Personally I would strongly prefer to prioritize a node-based approach first.

It's a bit silly, but a texture fits surprisingly well into the idea of geometry component attributes. So I expect it wouldn't be too hard to share code, it should just be a matter of gathering the input and output arrays and making sure the relevant nodes have a multi-function implementation.

Right, I believe Jacques has been talking about expression node for a while. Personally I would strongly prefer to prioritize a node-based approach first. It's a bit silly, but a texture fits surprisingly well into the idea of geometry component attributes. So I expect it wouldn't be too hard to share code, it should just be a matter of gathering the input and output arrays and making sure the relevant nodes have a multi-function implementation.

Jacques Lucke commented

2021-02-22 13:32:43 +01:00

Added subscriber: @JacquesLucke

Jacques Lucke commented

2021-02-22 13:32:43 +01:00

I think it should be relatively straight forward to use some node groups in shading and geometry nodes (and possibly other contexts). Obviously, only a subset of the available nodes can be used in such node groups.
The Attribute Processor design mockups are mostly just syntactic sugar for the geometry nodes context imo. The same functionality could be achieved without introducing new ui concepts. E.g. one could just have a different kind of Group node (which is similar to what I did in Animation Nodes, given that I couldn't introduce new ui concepts there).

I think it should be relatively straight forward to use some node groups in shading and geometry nodes (and possibly other contexts). Obviously, only a subset of the available nodes can be used in such node groups. The Attribute Processor design mockups are mostly just syntactic sugar for the geometry nodes context imo. The same functionality could be achieved without introducing new ui concepts. E.g. one could just have a different kind of Group node (which is similar to what I did in Animation Nodes, given that I couldn't introduce new ui concepts there).

Hadrien Brissaud commented

2021-02-25 00:23:26 +01:00

Added subscriber: @hadrien

Hadrien Brissaud commented

2021-02-25 00:23:26 +01:00

I'm not sure why a new UI is necessary since this seems to cover exactly what node groups do ? Is the idea to communicate to the user that they are working in a special sandbox and only certain nodes are allowed ?(as opposed to a regular node group which has no such limitations)
Apart from that you have my blessing. I've also started finding long string of attribute nodes unnecessarily difficult to read.

With the introduction of this attribute processor, would attribute-specific nodes still be necessary ? (attribute color ramp, etc) Would they keep existing alongside the attribute processor ?

I'm not sure why a new UI is necessary since this seems to cover exactly what node groups do ? Is the idea to communicate to the user that they are working in a special sandbox and only certain nodes are allowed ?(as opposed to a regular node group which has no such limitations) Apart from that you have my blessing. I've also started finding long string of attribute nodes unnecessarily difficult to read. With the introduction of this attribute processor, would attribute-specific nodes still be necessary ? (attribute color ramp, etc) Would they keep existing alongside the attribute processor ?

Kenzie commented

2021-02-25 01:45:36 +01:00

In #85655#1118629, @hadrien wrote:
With the introduction of this attribute processor, would attribute-specific nodes still be necessary ? (attribute color ramp, etc) Would they keep existing alongside the attribute processor ?

I feel like the already existing attribute nodes can stay since they are useful in a pinch when you want to just do a simple operation or two (maybe the attribute texture would need to eventually be depreciated and moved to a processor when the blender internal textures are finally removed). Aside from that there would likely need to be other attribute management nodes (like delete, set defaults, and rename) that wouldn't fit well in the attribute processor design.

> In #85655#1118629, @hadrien wrote: > With the introduction of this attribute processor, would attribute-specific nodes still be necessary ? (attribute color ramp, etc) Would they keep existing alongside the attribute processor ? I feel like the already existing attribute nodes can stay since they are useful in a pinch when you want to just do a simple operation or two (maybe the attribute texture would need to eventually be depreciated and moved to a processor when the blender internal textures are finally removed). Aside from that there would likely need to be other attribute management nodes (like delete, set defaults, and rename) that wouldn't fit well in the attribute processor design.

Dalai Felinto commented

2021-02-25 10:56:58 +01:00

@brecht is the idea for texture nodesfor them to be part of the material nodetree? as a special "custom texture" node?

Brecht Van Lommel commented

2021-02-25 14:16:08 +01:00

In #85655#1118781, @dfelinto wrote:
@brecht is the idea for texture nodesfor them to be part of the material nodetree? as a special "custom texture" node?

I think it's effectively a node group with an arbitrary number of inputs and outputs, that supports a subset of all shader nodes and can be created or used outside of materials. So it would be integrated the same as a shader node group, but with naming / icons / coloring to distinguish it.

> In #85655#1118781, @dfelinto wrote: > @brecht is the idea for texture nodesfor them to be part of the material nodetree? as a special "custom texture" node? I think it's effectively a node group with an arbitrary number of inputs and outputs, that supports a subset of all shader nodes and can be created or used outside of materials. So it would be integrated the same as a shader node group, but with naming / icons / coloring to distinguish it.

Rahul Chaudhary commented

2021-02-27 12:14:59 +01:00

Added subscriber: @RC12

Erindale commented

2021-03-02 22:47:42 +01:00

Added subscriber: @Erindale

Chris Clyne (Lateasusual) commented

2021-03-07 20:09:18 +01:00

Added subscriber: @lateasusual

Eyad Ahmed commented

2021-03-09 14:36:54 +01:00

Added subscriber: @IyadAhmed

Hans Goudey commented

2021-03-11 06:58:58 +01:00

Here are a few thoughts on the interface side of this:

While it might not be strictly necessary, a UI that is different from existing node groups should be prioritized to make this usable (after all, the task is for UX improvement).
If it's possible to collapse this, it should be possible to see both the input and output attribute names in separate lists on the collapsed version.
If it's possible to collapse this, it should not work like a frame node. Instead the node group should always display collapsed on the top level, and open like in the mockups when you enter the node group.
Input attributes are interpolated to the domain chosen in the drop-down, and all output attributes use that domain as well. The domain choice is very important.
Input attributes are read with a certain data type chosen statically in the interface. The data type can be chosen automatically with a similar method to attribute search when you add a new input attribute, but it must be possible to change this with a drop-down.
Any drop-down choices should be exposed in the main node editor region, not just the sidebar.
Connecting a link from inside the "frame" to the right side can add an attribute output, but you would need to choose the name.

Here are a few thoughts on the interface side of this: - While it might not be strictly necessary, a UI that is different from existing node groups should be prioritized to make this usable (after all, the task is for UX improvement). - If it's possible to collapse this, it should be possible to see both the input and output attribute names **in separate lists** on the collapsed version. - If it's possible to collapse this, it should **not** work like a frame node. Instead the node group should always display collapsed on the top level, and open like in the mockups when you enter the node group. - Input attributes are interpolated to the domain chosen in the drop-down, and all output attributes use that domain as well. The domain choice is very important. - Input attributes are read with a certain data type **chosen statically in the interface**. The data type can be chosen automatically with a similar method to attribute search when you add a new input attribute, but it must be possible to change this with a drop-down. - Any drop-down choices should be exposed in the main node editor region, not just the sidebar. - Connecting a link from inside the "frame" to the right side can add an attribute output, but you would need to choose the name.

Bartosz Moniewski commented

2021-03-12 01:15:45 +01:00

Added subscriber: @BartekMoniewski

Amaral Krichman commented

2021-03-12 02:59:35 +01:00

Added subscriber: @karmaral

Satish Goda commented

2021-03-12 03:05:42 +01:00

Added subscriber: @satishgoda1

Dalai Felinto commented

2021-03-12 15:56:26 +01:00

For the records, I removed these mockups since they are outdated. I also removed any reference to layout since this behaves more like a node group.

"The same behavior can be basically recreated with non-attribute nodes executed per every element. Here is a rough mockup of that same node tree with parallel evaluation:"

"And a different take on visuals by @lone_noel:"

For the records, I removed these mockups since they are outdated. I also removed any reference to layout since this behaves more like a node group. "The same behavior can be basically recreated with non-attribute nodes executed per every element. Here is a rough mockup of that same node tree with parallel evaluation:" ![Per Element Frame.png](https://archive.blender.org/developer/F9805352/Per_Element_Frame.png) "And a different take on visuals by @lone_noel:" ![image.png](https://archive.blender.org/developer/F9805363/image.png)

Dalai Felinto commented

2021-03-12 19:44:22 +01:00

Updated the task with the discussions the node group team had today. I added the following:

Plan of Attack

Support changing the data type of a group input/output socket.
New nodetree type with domain property, and treating geometry in/out sockets differently (they are not shown inside.
Group input/output socket option to expose it outside or leave it only inside.

Design

A new nodegroup type that supports attribute dataflow. This is added as a node and created from inside out (as oppose to the existing Node Group where you first group existing nodes).

The domain (point, corner, ...) is exposed outside as a node property.
When creating new input/output sockets users can type the name of the attribute directly.
This uses the attribute search
This creates a new input/output with the default value matching its name.
Connecting sockets to the Group Input/Output nodes also work

Changes that affect other node groups as well:

The node group datablock show go to the sidebar.
The socket input/output can have its type changed (Color/Geometry/String/...).

{F9887618, size=full}

Updated the task with the discussions the node group team had today. I added the following: ### Plan of Attack - [ ] Support changing the data type of a group input/output socket. - [ ] New nodetree type with domain property, and treating geometry in/out sockets differently (they are not shown inside. - [ ] Group input/output socket option to expose it outside or leave it only inside. ### Design A new nodegroup type that supports attribute dataflow. This is added as a node and created from inside out (as oppose to the existing Node Group where you first group existing nodes). * The domain (point, corner, ...) is exposed outside as a node property. * When creating new input/output sockets users can type the name of the attribute directly. * This uses the attribute search * This creates a new input/output with the default value matching its name. * Connecting sockets to the Group Input/Output nodes also work Changes that affect other node groups as well: * The node group datablock show go to the sidebar. * The socket input/output can have its type changed (Color/Geometry/String/...). {[F9887618](https://archive.blender.org/developer/F9887618/mockup-processor.png), size=full}

Kenzie commented

2021-03-13 04:01:41 +01:00

(Edit: Upon further inspection of the mockup it seems the potential issue was already accounted for)

Simon Sommer commented

2021-03-17 10:08:32 +01:00

Added subscriber: @CreatorSiSo

Simon Sommer commented

2021-03-17 10:08:33 +01:00

I think the best way of doing this is actually to introduce the attribute prozzesor node which allows you to select a attribute nodes graph like for a group node (but just with this graph type) and then opening the graph via TAB in a completely new nodes editor (no transperancy like in a group node). This is also how i would structure everything nodes in general because it just makes sence to dive deeper into the Objects/Geometry/Attributes for all of the little parts you want add to something (also its probably best way to do iterational and more complex stuff like bluring and so on in a place with a lot of space and not inside a frame inside the geometry nodes

not like this:

Also the other nodes that use should obviosly stay because they are used to manipulate the geometry with attributes and the attribute nodes would be uses to make changes to one or multiple attributes.

I think the best way of doing this is actually to introduce the attribute prozzesor node which allows you to select a attribute nodes graph like for a group node (but just with this graph type) and then opening the graph via TAB in a completely new nodes editor (no transperancy like in a group node). This is also how i would structure everything nodes in general because it just makes sence to dive deeper into the Objects/Geometry/Attributes for all of the little parts you want add to something (also its probably best way to do iterational and more complex stuff like bluring and so on in a place with a lot of space and not inside a frame inside the geometry nodes not like this: > ![Per Element Frame.png](https://archive.blender.org/developer/F9805352/Per_Element_Frame.png) > ![image.png](https://archive.blender.org/developer/F9805363/image.png) Also the other nodes that use should obviosly stay because they are used to manipulate the geometry with attributes and the attribute nodes would be uses to make changes to one or multiple attributes.

Dalai Felinto commented

2021-03-22 14:57:40 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Dalai Felinto closed this issue

2021-03-22 14:57:40 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Attribute Processor for UX improvement #85655

Plan of Attack

Design

Background

Key Concepts

Plan of Attack

Design