2025-09-05 Design Session: Node-Groups different Editors

[dfelinto]

Attendees:

• Dalai Felinto
• Simon Thommes

Meeting to go over the design of having a node-group to be available on different editors. This is presented as meeting notes instead of a design proposal because first we want to show this to the team and gather early feedback from other studio artists.

• Motivation
• Add Node Menu Categories and Assets
• Editor Compatibility
• Copy & Paste
• Usage

Motivation

Simon and Andy are working on assets to be embedded in Blender 5.0. Some of the util nodes they are creating could be used as well on the Geometry Nodes, as on the Compositor editor.

However at the moment there are no ways to:

• Make sure a node-group is available in more than one editor.
• Copy-paste a selection of nodes that contain “incompatible” nodes, without losing some of the connections and nodes.

Add Node Menu Categories and Assets

This could be done for Blender 5.0 independently of everything else.
Proposal: Unify the menu entries for the different editors.

At the moment the same node may be in very different categories in different editors. For example, the entire Vector category is a top-level menu entry on the Compositor and Shader Editor, while on the Geometry Nodes it is inside the Utilities menu.

This inconsistency is already a problem for users that may not know where to find a node. This becomes much worse once we have the same Node-Group Asset to show on different Editors menus.

The proposal is to unify some of the menu entries:

• All Editors can have a utilities category.
• The nodes inside the Converter category (from Shader) should be in different categories.

Option A: Top-Level (preferrable)

• Make Color a top-level menu for all the editors (already the case for Compositor and Shader).
• Make Vector a top-level menu for all the editors (already the case for Compositor and Shader).

Option B: Utilities

• Move Color inside Utilities (for Compositor and Shader).

Additionally the Material category in Geometry Nodes could go inside the Geometry. At the moment Material is next to Texture but there is no relation between them.

Analysis

(red): Categories which are relevant only for this Editor.
(green): Categories which are already unified.
(yellow): Categories which need unification.

Editor Compatibility

Expected behaviour: If a node-group only has nodes that also exist in other editors it should be available in all of those editors. Additionally, if the node-group author wants to make the node-group to show (or not show) in specific editors it should be possible.

Proposal: A new Editor Compatibility option (auto by default) to set the compatible editors.

Copy & Paste

Pasting should always paste all the nodes and preserve their connections. If there are incompatible nodes user should get a little notification about it (on top of the run-time error on the nodes themselves).

(This should also be implemented for Tool specific nodes that are pasted on a Modifier node-tree).

When pasting a node-group that is not compatible, this should be rather visible. For example, by using the same visual language we use for Undefined Nodes + an Info on the header:

Usage

We considered the Tool/Modifier compatibility topic in the discussion, but concluded that the Usage is still necessary since it address a different use case (it is about showing the node-group on the modifier list/tool menus).

[Gerstmann_Bradley]

very happy to see the discussion about this topic.
It’s definitely a huge problem when users need to maintain different node groups specific for each different Node Editor.

Although I think the issue is also linked with more issues.
For example, GN has attribute, shader has none.
the core function may be in a sharable node group, but there must also be parameters specific for each node editor.
As a result, there should be some node group that’s core function to avoid duplication, but also the real node group being used by the users for each editor.

and so on so forth.

[brecht]

@dfelinto

We considered the Tool/Modifier compatibility topic in the discussion, but concluded that the Usage is still necessary since it address a different use case (it is about showing the node-group on the modifier list/tool menus).

I would have actually expected the usage toggles to be extended for this, since it’s also about showing in certain menus.

• Geometry
  • Node
  • Modifier
  • Tool
• Compositor Node
• Shader Node

The override/auto toggle is not so clear if it only applies to a subset of these though.

We could also imagine a compositor node used as an operator/tool in the image editor, or even a shader node as an tool in paint modes. Though not anytime soon.

[dfelinto]

@brecht

I would have actually expected the usage toggles to be extended for this, since it’s also about showing in certain menus.

There is a difference though between a node-group that is compatible with Tools, and a node-group which you want showing as a tool in the e.g., Viewport header.

Similar for Modifiers. Not all node-groups which are compatible with modifiers should be listed on the Add Modifier menu.

For simplicity sake we kept Usage separate (however we set it after the Editor Compatibility Panel to indicate co-relation).

What we could do is to have Modifier/Tool showing up both on Usage and Editor Compatibility. And although this would make sense, it may be overkill. Or maybe it makes it extra clear that Extra Compatibility is for Shift + A menus, and Usage is for top-level listing (tools menus / modifier).

even a shader node as an tool in paint modes

How do you see this working? We couldn’t come up with an example of this given that shader is dealing with BSDF and not colors directly.

[brecht]

Or maybe it makes it extra clear that Extra Compatibility is for Shift + A menus, and Usage is for top-level listing (tools menus / modifier).

I don’t understand the purpose of this distinction. If I enable Usage > Modifier, it shows up in the equivalent of the Shift+A menu for modifiers. To me it seems all top level in the respective editors (node editor, properties editor, 3D viewport).

@dfelinto

How do you see this working? We couldn’t come up with an example of this given that shader is dealing with BSDF and not colors directly.

For example texture coordinate and ambient occlusion nodes are only available for shaders. The BSDFs indeed would not make that much sense.

[SimonThommes]

@brecht

The override/auto toggle is not so clear if it only applies to a subset of these though.

This is the crux of why, for now, we opted to make the distinction in the design. The intent of exposing a node-group as a tool, has nothing directly to do with the fact whether or not there are tool specific nodes used inside of it. I wouldn’t want to derive this kind of information from the context automatically. That’s different from the general case of editor compatibility imo.

If we opted to not include an Auto setting and would only set the editor compatibility by context on creation, the lists could be one indeed imo. But that comes at the cost of convenience when building a node-group that is compatible with multiple editors. Users would need to mark the node-group as compatible with the other editors explicitly first. This also implies that they need to know what makes a node-group compatible beforehand.

There could be a button to derive the compatible editors as an explicit step, so the user wouldn’t need to know all compatible nodes by heart, while keeping this an explicit option.

With an explicit setting you can also easily run into the issue that a user marked their node-group as compatible with all and then changes it (maybe by changing a nested node-group) to be only compatible with one. The top-level node-group does not automatically get updated, so any of its users wouldn’t know that this is what is breaking the compatibility.
Of course, this is also an issue when using the Override setting. But then the creator of the node-group actively opts into maintaining that setting properly.

@brecht does that make it clearer why we decided like this for now? Does that change your opinion of merging the lists in any way?

I generally agree with what you’re saying, I just think this reason makes it a worthwhile trade-off.

[brecht]

I think automatically determining it is fine. But I’d personally prefer to call this “usage” in the user interface, rather than introducing new “editor compatibility” terminology.

> Usage

  [  Auto  |  Override   ]
       [x] Compositng
       [x] Geometry
       [x] Shader

  > Geometry

       [x] Modifier
       [x] Tool

[SimonThommes]

Generally that seems fine with me, but does that imply anything about the warnings?

I guess instead of warning about nodes that are incompatible it would warn about nodes used in an illegal editor context, which makes sense.

So I’m understanding correctly:
Your point is main about how it’s presented in the UI and to not introduce a new concept of compatibility if it’s not required, correct?

But I think I’d make a small tweak then:

> Usage

  > Editor
       [  Auto  |  Override   ]
       [x] Compositng
       [x] Geometry
       [x] Shader

  > Geometry
       [x] Modifier
       [x] Tool

[brecht]

I guess the warning would be something like “is not marked for use in shader nodes” or “incompatible with shader nodes” if it actually contains nodes that are incompatible.

I’m fine with the UI you proposed. Another alternative would be something like this, where unchecking “Geometry” would hide the Geometry subpanel.

> Usage

  [  Auto  |  Override   ]
       [x] Compositng
       [x] Geometry
       [x] Shader

  > Geometry

       [x] Node
       [x] Modifier
       [x] Tool

[OmarEmaraDev]

@dfelinto

• Move Color inside Utilities (for Compositor and Shader).

This should not be an option, because Color contains some of the most “core” nodes of the compositor, so moving it inside utilities is a bad idea.

[dfelinto]

@OmarEmaraDev

This should not be an option, because Color contains some of the most “core” nodes of the compositor, so moving it inside utilities is a bad idea

I agree. Which is why this is not the preferrable option. It was listed there though for completion, and to illustrate why, in this case, Geometry Nodes will likely have to bite the bullet and have Color as a top-level category.

Vector is likely better inside Utilities though.

[Raiko]

I’m not sure if it’s been mentioned already, but when reusing node groups between editors, there’s the issue that it’s still not possible to assign implicit fields to node group input sockets in shader and compositor nodes.

So, for example, the Geo nodes version of my Rounded Polygon Texture node has an implicit field for the Vector input, but when copying the exact node setup to shader and compositor nodes, there is no straightforward way to assign an implicit field to that input.

[thorn-neverwake]

The number of nodes that would be “shared/compatible” between shading and geometry nodes - is it such a low number that this isn’t worth the effort?

[spitzak]

There can just be one list, with “Geometry Node”, “Geometry Modifier”, “Geometry Tool” as 3 items in it.

[Nima_Darius_Parsa]

Hi, does this issue still require design work?