Page MenuHome

Support node groups in asset browser
Confirmed, NormalPublicTO DO

Assigned To
None
Authored By
Jacques Lucke (JacquesLucke)
Nov 4 2021, 11:32 AM
Tokens
"Love" token, awarded by TImNN."Love" token, awarded by luischerubini."Love" token, awarded by silex."Love" token, awarded by Branskugel."Love" token, awarded by WorldBuilder."Love" token, awarded by Aleks41."Love" token, awarded by Behija."Love" token, awarded by HEYPictures."Love" token, awarded by Baardaap."Love" token, awarded by Schamph.

Event Timeline

Jacques Lucke (JacquesLucke) changed the task status from Needs Triage to Confirmed.Nov 4 2021, 11:32 AM
Jacques Lucke (JacquesLucke) created this task.

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 (rB604e61d81d63)
  • 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? :)
  • 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 T93754 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.

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

  • Geometry: handled in T93754
  • 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.

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.