Support node groups in asset browser #92811

New Issue

Jacques Lucke · 2021-11-04T11:32:42+01:00

Jacques Lucke commented

2021-11-04 11:32:42 +01:00

No description provided.

Jacques Lucke commented

2021-11-04 11:32:42 +01:00

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

Jacques Lucke commented

2021-11-04 11:32:42 +01:00

Added subscriber: @JacquesLucke

Paul Larson commented

2021-11-05 01:56:08 +01:00

Added subscriber: @GeorgiaPacific

Julian Eisel commented

2021-12-06 15:35:56 +01:00

Added subscriber: @JulianEisel

Julian Eisel commented

2021-12-06 15:35:56 +01:00

I don't think there is much work needed here. But somebody who understands the workflows and possible use-cases better needs to assess that. Nodes are flexible, and there may be a bunch of corner cases I didn't consider so far.

Node group drag & drop from the Asset Browser already works (604e61d81d)
Dependent data-blocks should be handled already. E.g. dragging in a geometry node group from an external asset library referencing an object from its source file should also import that object. But needs confirmation/testing.
Dependent external files are not handled properly yet. E.g. dragging in a node group referencing an image stored in the asset library doesn't copy the image properly. WIP in D12423: AssetBrowser: Localize external files., but also needs confirmation/testing for nodes in particular.
Supporting automatic previews would be nice. Needs different solution based on the node tree type (shader nodes vs. geometry nodes vs. compositing nodes, etc.)
What else? :)

I don't think there is much work needed here. But somebody who understands the workflows and possible use-cases better needs to assess that. Nodes are flexible, and there may be a bunch of corner cases I didn't consider so far. * Node group drag & drop from the Asset Browser already works (604e61d81d) * Dependent data-blocks should be handled already. E.g. dragging in a geometry node group from an external asset library referencing an object from its source file should also import that object. But needs confirmation/testing. * Dependent external files are not handled properly yet. E.g. dragging in a node group referencing an image stored in the asset library doesn't copy the image properly. WIP in [D12423: AssetBrowser: Localize external files.](https://archive.blender.org/developer/D12423), but also needs confirmation/testing for nodes in particular. * Supporting automatic previews would be nice. Needs different solution based on the node tree type (shader nodes vs. geometry nodes vs. compositing nodes, etc.) * What else? :)

Jacques Lucke commented

2021-12-06 15:55:49 +01:00

Thanks for the overview. We can test loading dependent data-blocks, but I'd also assume that this should work already.
For preview generation we have #93754 and want to look into it soon. If you have any ideas for how that should work, please leave a comment there (maybe there could be multiple operators to create previews for node trees in the future?).

Is there already an API we could use to integrate node group assets into the Add menu? That's not blocking for me, but would be good to know.

* Thanks for the overview. We can test loading dependent data-blocks, but I'd also assume that this should work already. * For preview generation we have #93754 and want to look into it soon. If you have any ideas for how that should work, please leave a comment there (maybe there could be multiple operators to create previews for node trees in the future?). Is there already an API we could use to integrate node group assets into the Add menu? That's not blocking for me, but would be good to know.

Vladislav Macíček commented

2021-12-11 02:17:40 +01:00

Added subscriber: @Aeraglyx

Brecht Van Lommel commented

2021-12-14 19:00:31 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2021-12-14 19:00:31 +01:00

For previews we need different methods depending on the node types:

Geometry: handled in #93754
Shader: create temporary material containing the node group, connect first output to material output and then render as if it was a material datablock.
Compositing: link some standard image or patterns to the inputs and evaluate in the compositer? But not clear this is useful.

For integration in menus, I can see some options (not necessarily mutually exclusive):
Add new metadata convention to specify the menu as a string, with syntax to support nested menus like "Patterns > Wood > Oak". Use existing catalog hierarchy in Add menu, filtering out any catalogs that have no relevant assets. With some way to mark a subset of the catalogs to be shown in menus.
** Support showing a subset of the asset browser as a modal popup, including previews. Could possibly also include native nodes.

Using the catalog hierarchy in the Add menu seem elegant, because who wants to organize their assets multiple times? But it does assume that users would be ok with organizing menu assets in catalogs separate from other assets (or suffer huge menus). This approach currently makes most sense to me, but I'm not sure about the right choice.

Menu integration could first be done for Add menu in the node editor. But the Add menu in the 3D viewport and the Add Modifier menu in the properties editor could follow? For modifiers there might to be some metadata to indicate if the geometry node group is usable as a modifier, or more of a lower level building block for the node editor. Not sure if this is in the plans of the geometry nodes team, but I think it would be interesting to have a workflow for creating custom modifiers that look much like native ones.

We should consider hiding node group datablock selector buttons in nodes/modifiers by default, at least for such assets but possibly always. I think that generally you do not want to switch to another group, you would just add a new node. The information if a node group is used in other places is useful though, there could be some way to show that still, either always or when you enter the node group for editing.

For previews we need different methods depending on the node types: * Geometry: handled in #93754 * Shader: create temporary material containing the node group, connect first output to material output and then render as if it was a material datablock. * Compositing: link some standard image or patterns to the inputs and evaluate in the compositer? But not clear this is useful. For integration in menus, I can see some options (not necessarily mutually exclusive): **Add new metadata convention to specify the menu as a string, with syntax to support nested menus like "Patterns > Wood > Oak".** Use existing catalog hierarchy in Add menu, filtering out any catalogs that have no relevant assets. With some way to mark a subset of the catalogs to be shown in menus. ** Support showing a subset of the asset browser as a modal popup, including previews. Could possibly also include native nodes. Using the catalog hierarchy in the Add menu seem elegant, because who wants to organize their assets multiple times? But it does assume that users would be ok with organizing menu assets in catalogs separate from other assets (or suffer huge menus). This approach currently makes most sense to me, but I'm not sure about the right choice. Menu integration could first be done for Add menu in the node editor. But the Add menu in the 3D viewport and the Add Modifier menu in the properties editor could follow? For modifiers there might to be some metadata to indicate if the geometry node group is usable as a modifier, or more of a lower level building block for the node editor. Not sure if this is in the plans of the geometry nodes team, but I think it would be interesting to have a workflow for creating custom modifiers that look much like native ones. We should consider hiding node group datablock selector buttons in nodes/modifiers by default, at least for such assets but possibly always. I think that generally you do not want to switch to another group, you would just add a new node. The information if a node group is used in other places is useful though, there could be some way to show that still, either always or when you enter the node group for editing.

Jacques Lucke commented

2021-12-14 19:26:12 +01:00

Using the catalog hierarchy in the Add menu seem elegant, because who wants to organize their assets multiple times? But it does assume that users would be ok with organizing menu assets in catalogs separate from other assets (or suffer huge menus). This approach currently makes most sense to me, but I'm not sure about the right choice.

I also like the idea of using the catalog hierarchy in the add menu. Think long term the menu will get huge regardless of how we organize it exactly. For me that's definitely better than introducing a different kind of category without clear motivation now. If we later notice that it would be nice to decouple the menu sorting from asset catalogs, that could be an opt-in feature for assets. So by default we use the asset catalog hierarchy, unless the user explicitly decides to organize the menu differently.

Not sure if this is in the plans of the geometry nodes team, but I think it would be interesting to have a workflow for creating custom modifiers that look much like native ones.

We don't have it planned yet but that generally sounds reasonable and shouldn't be too hard to do. Personally, mid to long term I'd like to spend some time rethinking the modifier stack. Just stacking different effects is often to inflexible. I think there is a nice middle ground that is as easy to use as a modifier stack but gives at least some of the benefits of a node editor, still all within the properties editor though.
Instead of having a linear list of effects, we could have some kind of hierarchy of effects/modifiers (ui could be similar to the outliner or asset catalogs). Every row would be a modifier. Settings are either shown in a separate panel or are somehow integrated into the hierarchy. One goal is to allow having multiple independent effects on the same original object.
I think an approach like this could make for a very nice user experience where you only have to drop into the node editor when you need features that couldn't also be easily displayed in a panel. Still needs more thought though.
I'm fine with hiding the group data block selector as an intermediate step.

> Using the catalog hierarchy in the Add menu seem elegant, because who wants to organize their assets multiple times? But it does assume that users would be ok with organizing menu assets in catalogs separate from other assets (or suffer huge menus). This approach currently makes most sense to me, but I'm not sure about the right choice. I also like the idea of using the catalog hierarchy in the add menu. Think long term the menu will get huge regardless of how we organize it exactly. For me that's definitely better than introducing a different kind of category without clear motivation now. If we later notice that it would be nice to decouple the menu sorting from asset catalogs, that could be an opt-in feature for assets. So by default we use the asset catalog hierarchy, unless the user explicitly decides to organize the menu differently. > Not sure if this is in the plans of the geometry nodes team, but I think it would be interesting to have a workflow for creating custom modifiers that look much like native ones. We don't have it planned yet but that generally sounds reasonable and shouldn't be too hard to do. Personally, mid to long term I'd like to spend some time rethinking the modifier stack. Just stacking different effects is often to inflexible. I think there is a nice middle ground that is as easy to use as a modifier stack but gives at least some of the benefits of a node editor, still all within the properties editor though. Instead of having a linear list of effects, we could have some kind of hierarchy of effects/modifiers (ui could be similar to the outliner or asset catalogs). Every row would be a modifier. Settings are either shown in a separate panel or are somehow integrated into the hierarchy. One goal is to allow having multiple independent effects on the same original object. I think an approach like this could make for a very nice user experience where you only have to drop into the node editor when you need features that couldn't also be easily displayed in a panel. Still needs more thought though. I'm fine with hiding the group data block selector as an intermediate step.

Maciej Morgaś commented

2022-01-13 09:49:50 +01:00

Added subscriber: @MaciejMorgas

Tim Neumann commented

2022-02-27 19:29:43 +01:00

Added subscriber: @TimNN

Philipp Oeser commented

2022-04-11 17:39:42 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2022-04-11 17:39:42 +02:00

Note we have #97237 (Asset Browser: dragging custom node group asset adds broken node) -- where this drag n drop of custom nodegroups goes wrong...

Note we have #97237 (Asset Browser: dragging custom node group asset adds broken node) -- where this drag n drop of **custom** nodegroups goes wrong...

Pauan commented

2022-05-15 04:53:09 +02:00

Added subscriber: @pauanyu_blender

Jacques Lucke commented

2022-10-20 15:19:59 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Jacques Lucke closed this issue

2022-10-20 15:19:59 +02:00

Jacques Lucke self-assigned this 2022-10-20 15:19:59 +02: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

Support node groups in asset browser #92811