Node Group Inputs #68733

New Issue

Jacques Lucke · 2019-08-16T16:12:51+02:00

Jacques Lucke commented

2019-08-16 16:12:51 +02:00

Node groups serve the purpose of combining multiple nodes into reusable components. To make them more useful, node groups can have a set of inputs that the "caller" has to provide. Currently, node groups have one Group Input and one Group Output node. This works well for many cases. However, I'd argue that there is a better way to do it (both approaches are used in multiple other pieces of software).

Some motivation for implementing a new approach:

When a node group needs more inputs, there is usually a large node on the left side of a node tree that has links to many other nodes. I'd argue that these links add more confusion than they actually provide information to the user. At some point it becomes quite hard to follow these links through the entire node tree.
In the current implementation, there is no mechanism that supports grouping of inputs.
Important information like the min/max/default values is hidden in a panel in the sidebar.

Personally, I think it would be good to allow multiple Input Parameter nodes in a node group. Something like this:

Some notes on this approach:

For different data types, a different set of settings can be shown. Of course the node can also be collapsed when not all information is necessary.
The node can be placed exactly where the value is needed, providing better information when actually working on the node tree.
All the settings can still be shown in a side bar to have all information accessible in a single place.
We could also allow multiple inputs per Function Parameter node for better grouping of related settings.

Implementation wise, this approach might actually be simpler than the old solution.
At the same it scales better when node trees get larger and when we want groups to become more powerful.

Node groups serve the purpose of combining multiple nodes into reusable components. To make them more useful, node groups can have a set of inputs that the "caller" has to provide. Currently, node groups have one Group Input and one Group Output node. This works well for many cases. However, I'd argue that there is a better way to do it (both approaches are used in multiple other pieces of software). Some motivation for implementing a new approach: - When a node group needs more inputs, there is usually a large node on the left side of a node tree that has links to many other nodes. I'd argue that these links add more confusion than they actually provide information to the user. At some point it becomes quite hard to follow these links through the entire node tree. - In the current implementation, there is no mechanism that supports grouping of inputs. - Important information like the min/max/default values is hidden in a panel in the sidebar. Personally, I think it would be good to allow multiple Input Parameter nodes in a node group. Something like this: ![image.png](https://archive.blender.org/developer/F7667372/image.png) Some notes on this approach: - For different data types, a different set of settings can be shown. Of course the node can also be collapsed when not all information is necessary. - The node can be placed exactly where the value is needed, providing better information when actually working on the node tree. - All the settings can still be shown in a side bar to have all information accessible in a single place. - We could also allow multiple inputs per Function Parameter node for better grouping of related settings. Implementation wise, this approach might actually be simpler than the old solution. At the same it scales better when node trees get larger and when we want groups to become more powerful.

Jacques Lucke self-assigned this 2019-08-16 16:12:51 +02:00

Jacques Lucke commented

2019-08-16 16:12:51 +02:00

Added subscriber: @JacquesLucke

Duarte Farrajota Ramos commented

2019-08-16 21:32:20 +02:00

Added subscriber: @DuarteRamos

Demeter Dzadik commented

2019-08-16 23:19:12 +02:00

Added subscriber: @Mets

Demeter Dzadik commented

2019-08-16 23:19:12 +02:00

It would be nice to be able to choose how values like floats and vectors are displayed on the nodegroup input (slider, percentage, color, normal). It could apply to new types a well, for example booleans could be a checkbox or a toggle button.

Demeter Dzadik commented

2019-08-16 23:31:43 +02:00

This comment was removed by @Mets

*This comment was removed by @Mets*

Jacques Lucke commented

2019-08-17 01:39:28 +02:00

We definitely want to give users control over how node group inputs are displayed later on. However, that topic is orthogonal to the one presented in the original post. Maybe, the topic name should have been more precise.

I'll probably create a separate design task for this in the future.

We definitely want to give users control over how node group inputs are displayed later on. However, that topic is orthogonal to the one presented in the original post. Maybe, the topic name should have been more precise. I'll probably create a separate design task for this in the future.

Benjamin commented

2019-08-17 15:24:26 +02:00

Added subscriber: @BenjaminMuller

Benjamin commented

2019-08-17 15:24:26 +02:00

It's not directly related to your proposal, but if we rethink the way we provide group inputs as nodes, we might just as well think about the ability to expose every possible node input type, like for example a dropdown, a color picker, a toggle checkbox, you get it.

It's not *directly* related to your proposal, but if we rethink the way we provide group inputs as nodes, we might just as well think about the ability to expose every possible node input type, like for example a dropdown, a color picker, a toggle checkbox, you get it.

Bartosz Moniewski commented

2020-02-06 19:37:05 +01:00

Added subscriber: @BartekMoniewski

surya kiran reddy commented

2020-04-21 11:04:27 +02:00

Added subscriber: @DirSurya

Moritz Brückner commented

2020-11-21 22:18:06 +01:00

Added subscriber: @timodriaan

Lukas Tönne commented

2021-07-02 12:37:30 +02:00

Added subscriber: @LukasTonne

Lukas Tönne commented

2021-07-02 12:37:30 +02:00

I would like start this task with a list of relatively simple and uncontroversial changes:

Use the existing socket-hiding mechanism for creating single-socket inputs (ctrl+h key, the old SOCK_UNAVAIL flag).

This can be implemented quite easily and it gives us backward compatibility. Adding a group input just hides all but one socket by default.

Users can still create multi-socket nodes with the node properties panel, if they really need that level of control. All sockets will be listed there with a checkbox/icon to toggle visibility.

Remove the "virtual" socket for group extension, or at least hide it by default (checkbox in properties panel to enable it?).
Alternative methods for declaring group inputs/outputs:
1. "+" button in the group interface panel. This has not seen as much use because it lacks features for changing socket types (see below).
2. Context menu to "make this socket a parameter"
3. Drag&drop + pie menu to create a new input (see also future task: Adding nodes with links)
Methods for instancing group inputs/outputs:
1. Select a socket from the "Add Node" menu. The menu will list all the declared group inputs/outputs instead of just a generic "Group Input"/"Group Output".
2. Drag & Drop from the group properties panel.
Fully support changing types, limits, and any other aspect of a declared parameters in the group interface.
Solve problem of group output uniqueness: Only one group output can be active at a time. Which output is active is not consistently solved in Blender: shader nodes react to the "last clicked node", Geometry Nodes stop working altogether when multiple group outputs exist. This should be transparent and predictable.

Future tasks (out of scope here):

Adding nodes with links: drag a link to empty space, add + connect a matching node in place.
Better node search: should allow typing directly when "Add Node" menu is open.
Alphabetic sorting in nodes: The categories don't really help beyond the first level.
Generally clean up categories, a lot of them don't make much sense.
Implement structs for combining sockets. This would fit in with the splitting feature @Mets mentioned, but it's quite a big topic.

I would like start this task with a list of relatively simple and uncontroversial changes: * Use the existing socket-hiding mechanism for creating single-socket inputs (ctrl+h key, the old `SOCK_UNAVAIL` flag). ``` This can be implemented quite easily and it gives us backward compatibility. Adding a group input just hides all but one socket by default. Users can still create multi-socket nodes with the node properties panel, if they really need that level of control. All sockets will be listed there with a checkbox/icon to toggle visibility. ``` * Remove the "virtual" socket for group extension, or at least hide it by default (checkbox in properties panel to enable it?). * Alternative methods for declaring group inputs/outputs: 1. "+" button in the group interface panel. This has not seen as much use because it lacks features for changing socket types (see below). 1. Context menu to "*make this socket a parameter*" 1. Drag&drop + pie menu to create a new input (see also future task: Adding nodes with links) * Methods for instancing group inputs/outputs: 1. Select a socket from the "Add Node" menu. The menu will list all the declared group inputs/outputs instead of just a generic "Group Input"/"Group Output". 1. Drag & Drop from the group properties panel. * Fully support changing types, limits, and any other aspect of a declared parameters in the group interface. * Solve problem of group output uniqueness: Only one group output can be active at a time. Which output is active is not consistently solved in Blender: shader nodes react to the "last clicked node", Geometry Nodes stop working altogether when multiple group outputs exist. This should be transparent and predictable. **Future tasks (out of scope here):** * Adding nodes with links: drag a link to empty space, add + connect a matching node in place. * Better node search: should allow typing directly when "Add Node" menu is open. * Alphabetic sorting in nodes: The categories don't really help beyond the first level. * Generally clean up categories, a lot of them don't make much sense. * Implement structs for combining sockets. This would fit in with the splitting feature @Mets mentioned, but it's quite a big topic.

Tomas commented

2021-07-02 14:18:47 +02:00

Added subscriber: @Rusculleda

Tomas commented

2021-07-02 14:18:47 +02:00

For the dragging a link to empty space feature there's this patch: https://developer.blender.org/D8286

Hans Goudey commented

2021-07-02 15:23:40 +02:00

Added subscriber: @HooglyBoogly

Hans Goudey commented

2021-07-02 15:23:40 +02:00

Remove the "virtual" socket for group extension, or at least hide it by default (checkbox in properties panel to enable it?).

Personally I'm not sure about this, I really like the simplicity of this, it's a very intuitive concept to learn.

> Remove the "virtual" socket for group extension, or at least hide it by default (checkbox in properties panel to enable it?). Personally I'm not sure about this, I really like the simplicity of this, it's a very intuitive concept to learn.

Lukas Tönne commented

2021-07-02 16:15:06 +02:00

@Rusculleda Thanks, i'll be following that patch discussion. At a glance it seems there is some opposition (when is there ever none) to popping up a menu on the drop. I can think of some alternatives (context menu on socket, pie menu, etc). It should still work without this feature though. Potentially can also be an API extension such that a "node from noodle" feature like this can be implemented in a python addon.

@HooglyBoogly It's intuitive, but it rarely works as intended. Usually adding a new socket is only the first step, you then have to name it, give it correct subtype or limits, eventually we should have doc strings for them too so you can explain what a parameter does. The socket is also usually not in the right place and has to be moved up into the right spot. I would rather not have an extra socket on every single input node. If we add a context menu for sockets with an option "Make Group Input" or similar that would basically provide the same functionality without permanently cluttering the node space.

@Rusculleda Thanks, i'll be following that patch discussion. At a glance it seems there is some opposition (when is there ever none) to popping up a menu on the drop. I can think of some alternatives (context menu on socket, pie menu, etc). It should still work without this feature though. Potentially can also be an API extension such that a "node from noodle" feature like this can be implemented in a python addon. @HooglyBoogly It's intuitive, but it rarely works as intended. Usually adding a new socket is only the first step, you then have to name it, give it correct subtype or limits, eventually we should have doc strings for them too so you can explain what a parameter does. The socket is also usually not in the right place and has to be moved up into the right spot. I would rather not have an extra socket on every single input node. If we add a context menu for sockets with an option "Make Group Input" or similar that would basically provide the same functionality without permanently cluttering the node space.

Jacques Lucke commented

2021-07-05 14:42:38 +02:00

Use the existing socket-hiding mechanism for creating single-socket inputs (ctrl+h key, the old SOCK_UNAVAIL flag).

Do you mean to use SOCK_HIDDEN or SOCK_UNAVAIL? Ctrl+h modifies SOCK_HIDDEN.

Solve problem of group output uniqueness: Only one group output can be active at a time.

Personally, I'm not sure if these needs a different solution alltogether. I might be useful to have multiple output nodes in different places. Obviously only one should be active per group output socket.

Better node search: should allow typing directly when "Add Node" menu is open.

This might need a more generic solution that is applicable to other menus as well. Note that this conflicts with the shortcut keys that allow you to open submenus (not a big deal for me, but maybe for others).

I think the highest priority change should be Fully support changing types, limits, and any other aspect of a declared parameters in the group interface.
After that it would be nice to support alternative ways to create group inputs without having to link sockets to a Group Input socket that might be far away. Hiding all but one of the sockets in the group input socket automatically can be part of this.

> Use the existing socket-hiding mechanism for creating single-socket inputs (ctrl+h key, the old SOCK_UNAVAIL flag). Do you mean to use `SOCK_HIDDEN` or `SOCK_UNAVAIL`? Ctrl+h modifies `SOCK_HIDDEN`. > Solve problem of group output uniqueness: Only one group output can be active at a time. Personally, I'm not sure if these needs a different solution alltogether. I might be useful to have multiple output nodes in different places. Obviously only one should be active per group output socket. > Better node search: should allow typing directly when "Add Node" menu is open. This might need a more generic solution that is applicable to other menus as well. Note that this conflicts with the shortcut keys that allow you to open submenus (not a big deal for me, but maybe for others). ---- I think the highest priority change should be `Fully support changing types, limits, and any other aspect of a declared parameters in the group interface.` After that it would be nice to support alternative ways to create group inputs without having to link sockets to a Group Input socket that might be far away. Hiding all but one of the sockets in the group input socket automatically can be part of this.

Lukas Tönne commented

2021-07-05 15:35:35 +02:00

In #68733#1187096, @JacquesLucke wrote:

Use the existing socket-hiding mechanism for creating single-socket inputs (ctrl+h key, the old SOCK_UNAVAIL flag).

Do you mean to use SOCK_HIDDEN or SOCK_UNAVAIL? Ctrl+h modifies SOCK_HIDDEN.

Yes, thanks, that's the one.

Solve problem of group output uniqueness: Only one group output can be active at a time.

Personally, I'm not sure if these needs a different solution alltogether. I might be useful to have multiple output nodes in different places. Obviously only one should be active per group output socket.

Reason i'm including this here is because if we make group inputs single-socket nodes then it would make sense to do the same for outputs. A large node group can define different outputs in different places. But having multiple group output nodes currently is badly defined, it can cause all except one output node to become disabled. Even though each of them only defines one output value and it should be unambiguous which value is used for each socket. The mechanisms that were employed to disambiguate output nodes don't work any more with the new design and have to be adjusted.

Better node search: should allow typing directly when "Add Node" menu is open.

This might need a more generic solution that is applicable to other menus as well. Note that this conflicts with the shortcut keys that allow you to open submenus (not a big deal for me, but maybe for others).

I agree, the menu shortcuts don't make sense to me, actual search would be a lot more useful. Also just personal opinion.

I think the highest priority change should be Fully support changing types, limits, and any other aspect of a declared parameters in the group interface.

Already in progress, see D10912

> In #68733#1187096, @JacquesLucke wrote: >> Use the existing socket-hiding mechanism for creating single-socket inputs (ctrl+h key, the old SOCK_UNAVAIL flag). > > Do you mean to use `SOCK_HIDDEN` or `SOCK_UNAVAIL`? Ctrl+h modifies `SOCK_HIDDEN`. Yes, thanks, that's the one. >> Solve problem of group output uniqueness: Only one group output can be active at a time. > > Personally, I'm not sure if these needs a different solution alltogether. I might be useful to have multiple output nodes in different places. Obviously only one should be active per group output socket. Reason i'm including this here is because if we make group inputs single-socket nodes then it would make sense to do the same for outputs. A large node group can define different outputs in different places. But having multiple group output nodes currently is badly defined, it can cause all except one output node to become disabled. Even though each of them only defines one output value and it should be unambiguous which value is used for each socket. The mechanisms that were employed to disambiguate output nodes don't work any more with the new design and have to be adjusted. >> Better node search: should allow typing directly when "Add Node" menu is open. > > This might need a more generic solution that is applicable to other menus as well. Note that this conflicts with the shortcut keys that allow you to open submenus (not a big deal for me, but maybe for others). I agree, the menu shortcuts don't make sense to me, actual search would be a lot more useful. Also just personal opinion. > I think the highest priority change should be `Fully support changing types, limits, and any other aspect of a declared parameters in the group interface.` Already in progress, see [D10912](https://archive.blender.org/developer/D10912)

Lukas Tönne commented

2021-07-08 16:55:18 +02:00

I started a draft for the single-socket nodes: D11853

I started a draft for the single-socket nodes: [D11853](https://archive.blender.org/developer/D11853)

Iliya Katushenock commented

2022-12-31 22:49:18 +01:00

Added subscriber: @mod_moder

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Node Group Inputs #68733