Support token editing within GraphEditor UI by mialana · Pull Request #2943 · AcademySoftwareFoundation/MaterialX

mialana · 2026-05-20T17:50:51Z

Preview of new detailed Tokens Table feature.

Hello! This is a PR for Dev Days 2026. It features:

Token editing directly within the graph editor UI
Display of other token data within Tokens table to improve user experience. Namely:

A Source Element column, which contains the graph element where the token is declared / was discovered during upwards traversal.
A Affected Inputs column, which lists which of the node's inputs reference the token.

Tooltip features for both the overall tokens table and each of the individual columns (see preview GIF below).

Preview of new supplementary tooltip features.

Feel free to point out any inefficiencies or inconsistencies I've made in implementation. Thank you!

…l of node inputs Signed-off-by: mialana <aliu@amyliu.dev>

Signed-off-by: mialana <aliu@amyliu.dev>

…ring for interface inputs Signed-off-by: mialana <aliu@amyliu.dev>

Signed-off-by: mialana <aliu@amyliu.dev>

kwokcb

Hi @mialana,
This looks really good! There are some minor comments on variants to check.

I see you find all parent tokens for the active child node.
You could simplify logic by just getting the tokens for the current (selected) node/nodegraph. The user interaction and display would be simplified as well as a user knows exactly what scope the token change is occurring at. I leave it up to you -- either way is fine.

I didn't run this but have you checked that a token change can indeed cause the image's referenced to update, or is this a second step after the core + edit logic here is added ?

Thanks.

kwokcb · 2026-05-20T18:50:44Z

+            handleTokenMapping(interfaceElem, currElem);
+
+            // If the node is a nodegraph, also check for tokens on corresponding nodedef
+            if (mx::ConstNodeGraphPtr nodegraph = currElem->asA<mx::NodeGraph>())


I believe this logic will need to also handle node instances as the corresponding nodedef could also have exposed tokens. I don't think there is an example such as nodedef so may need to make one. Perhaps a simple example is a nodedef implemented as a image node + a token node, where the image node's filename and the token input are exposed as interface inputs.

Sure! Do these new additions cover the cases you are thinking of?

Looks good. Thanks.

kwokcb · 2026-05-20T18:56:14Z

+        {
+            std::string key = token->getName();
+
+            // Insert into map, but do not allow parent values to override child values


Thanks for handling token hierarchies.

I believe you will get the correct ordering if getActiveTokens() maintains child->parent ordering (which it should). Another option would be to use full paths and check if the current token is a parent.

Right, I did go down the implementation code of getActiveTokens(). If I understand it correctly, it traverses inheritance, calls getChildrenOfType<Token>(), and appends the return tokens to a result vector.

But of course I can also look into the other solution you suggested! Is there a helper function anywhere in the code base for detecting if path strings have parent-child relationships?

Thanks for checking the logic. If this is ordering than it's fine.

Signed-off-by: mialana <aliu@amyliu.dev>

mialana · 2026-05-20T21:28:25Z

Hi @mialana, This looks really good! There are some minor comments on variants to check.

I see you find all parent tokens for the active child node. You could simplify logic by just getting the tokens for the current (selected) node/nodegraph. The user interaction and display would be simplified as well as a user knows exactly what scope the token change is occurring at. I leave it up to you -- either way is fine.

I didn't run this but have you checked that a token change can indeed cause the image's referenced to update, or is this a second step after the core + edit logic here is added ?

Thanks.

Great! Yes, here is a demo where I edit a token in the table, and the material preview is updated thereafter.

For the design decision you mention, my initial thought process was that displaying parent tokens is useful as then the table exposes all tokens that are available for use in filename-type inputs of the current node -- i.e. all the tokens that are currently in scope.

Does that make sense to you as well? Thank you for the code review!

kwokcb

This looks good to go.

Just leaving a final test check that the editing values works for the cases in
the token_graph and token_graph_material. A snapshot or short gif/video would be good to show the result. There is a nodedef with token instance so that will check the latest logic you added in to cover that case. Thanks!

kwokcb · 2026-05-21T15:03:15Z

+        {
+            std::string key = token->getName();
+
+            // Insert into map, but do not allow parent values to override child values


Thanks for checking the logic. If this is ordering than it's fine.

kwokcb · 2026-05-21T15:03:57Z

+            handleTokenMapping(interfaceElem, currElem);
+
+            // If the node is a nodegraph, also check for tokens on corresponding nodedef
+            if (mx::ConstNodeGraphPtr nodegraph = currElem->asA<mx::NodeGraph>())


Looks good. Thanks.

…class Signed-off-by: mialana <aliu@amyliu.dev>

Signed-off-by: mialana <aliu@amyliu.dev>

mialana · 2026-05-27T20:37:05Z

MaterialX Token Editing - 'token_graph_material.mtlx' Functionality Demo

MaterialX Token Editing - 'token_graph.mtlx' Functionality Demo

@kwokcb Sorry for the delay in getting these videos posted. I will say that the videos demonstrate that the editing process is not yet completely bug-free. Namely:

In token_graph_material.mtlx the third test scenario with token_nodedef_graph will invoke an error message: "Could not find a matching implementation for node 'token_image' matching target 'genglsl'". From debugging, this occurs from calling updateMaterials() after editing. It seems that during this re-render the graph node traversal is different / incomplete, causing the implementation NG_token of ND_token to not be visited at all.
In token_graph.mtlx, only the Parent_Token_Graph test case has a material preview in the viewport. Furthermore, the mini 2D preview of the filename input in the sibling test does not show up (and never did).

Given these videos, I am curious whether you'd like to fix these bugs before this PR is approved? I believe that the problems demonstrated should have already existed before my changes, and if possible could be addressed separately.

I can also provide some more details on anything if needed! Thank you, hope my update make sense and let me know preferred next steps.

kwokcb · 2026-05-28T12:59:18Z

Hi @mialana, This looks really good! There are some minor comments on variants to check.
I see you find all parent tokens for the active child node. You could simplify logic by just getting the tokens for the current (selected) node/nodegraph. The user interaction and display would be simplified as well as a user knows exactly what scope the token change is occurring at. I leave it up to you -- either way is fine.
I didn't run this but have you checked that a token change can indeed cause the image's referenced to update, or is this a second step after the core + edit logic here is added ?
Thanks.

Great! Yes, here is a demo where I edit a token in the table, and the material preview is updated thereafter.

For the design decision you mention, my initial thought process was that displaying parent tokens is useful as then the table exposes all tokens that are available for use in filename-type inputs of the current node -- i.e. all the tokens that are currently in scope.

Does that make sense to you as well? Thank you for the code review!

Thanks for the update preview. Looks great.
For exposing all the tokens. I think the only concern I have is that parent tokens can affect more than the currently selected node. e.g. a parent token could affect 2 or more child images. Seems good to leave it as is and gather
user feedback on this.

kwokcb · 2026-05-28T13:03:32Z

MaterialX Token Editing - 'token_graph_material.mtlx' Functionality Demo

MaterialX Token Editing - 'token_graph.mtlx' Functionality Demo

@kwokcb Sorry for the delay in getting these videos posted. I will say that the videos demonstrate that the editing process is not yet completely bug-free. Namely:

In token_graph_material.mtlx the third test scenario with token_nodedef_graph will invoke an error message: "Could not find a matching implementation for node 'token_image' matching target 'genglsl'". From debugging, this occurs from calling updateMaterials() after editing. It seems that during this re-render the graph node traversal is different / incomplete, causing the implementation NG_token of ND_token to not be visited at all.

In token_graph.mtlx, only the Parent_Token_Graph test case has a material preview in the viewport. Furthermore, the mini 2D preview of the filename input in the sibling test does not show up (and never did).

Given these videos, I am curious whether you'd like to fix these bugs before this PR is approved? I believe that the problems demonstrated should have already existed before my changes, and if possible could be addressed separately.

I can also provide some more details on anything if needed! Thank you, hope my update make sense and let me know preferred next steps.

Hmm. The first seems like a bug in the editor update logic not picking up the local nodedef properly but is picked up on initial file load. . Can you leave a new issue for this. Thanks.
token_graph.mtlx is unrelated and is relate to discovery of what is considered "renderable". Should log another issue for this, but you don't need to do this :).

kwokcb

Thanks for your work on this Amy. This looks good to go!

If you can log the update issue you found at your convenience that would be much
appreciated. Thx.

jstone-lucasfilm

Thanks @mialana and @kwokcb! I'm looking forward to reading through this code in more depth, and on my first read I had one thought on the introduction of std::atomic to the Graph Editor.

jstone-lucasfilm · 2026-05-28T15:13:22Z

+    std::ostringstream _affectedInputsStream{};
+
+    // Track whether changes were made to inputs in order to re-build stream accordingly
+    std::atomic<bool> _isAffectedInputsDirty{ true };


Perhaps the introduction of std::atomic to this code is not needed? Assuming this code will only be called from the single-threaded UI of the Graph Editor, I wouldn't imagine we need to bring new thread-safe constructs into this logic.

mialana added 10 commits May 14, 2026 19:21

Fix discovery of tokens to accumulate current tokens through traversa…

019edba

…l of node inputs Signed-off-by: mialana <aliu@amyliu.dev>

Merge branch 'main' into support-token-editing

cc15276

Implement token data as persistent map on ui node class

3709caf

Signed-off-by: mialana <aliu@amyliu.dev>

Write out edited token value and store affected inputs per token

18b0081

Signed-off-by: mialana <aliu@amyliu.dev>

Fix for material render preview immediate update and resolve value st…

ee565f7

…ring for interface inputs Signed-off-by: mialana <aliu@amyliu.dev>

Merge branch 'main' into support-token-editing

090bf5c

Clean up comments and allow for tooltips per column in tokens table

b526ec7

Signed-off-by: mialana <aliu@amyliu.dev>

Create help marker for tokens table, fill in all column tooltips

7e81ef7

Signed-off-by: mialana <aliu@amyliu.dev>

Lint, supplementary comment

b3cee30

Signed-off-by: mialana <aliu@amyliu.dev>

Match private member function naming convention

04f9d02

Signed-off-by: mialana <aliu@amyliu.dev>

mialana changed the title ~~GraphEditor: Support token editing through UI~~ Support token editing within GraphEditor UI May 20, 2026

jstone-lucasfilm added the devdays26 label May 20, 2026

Move token mapping logic to an inline lambda to avoid repeated code

8d0767b

Signed-off-by: mialana <aliu@amyliu.dev>

kwokcb reviewed May 20, 2026

View reviewed changes

Handle tokens defined on custom node instances

33fe3a7

Signed-off-by: mialana <aliu@amyliu.dev>

kwokcb reviewed May 21, 2026

View reviewed changes

Move inline lambda token mapping handler to static member of UiToken …

3644bd6

…class Signed-off-by: mialana <aliu@amyliu.dev>

mialana force-pushed the support-token-editing branch from e8d5b3e to 3644bd6 Compare May 23, 2026 18:14

jstone-lucasfilm and others added 2 commits May 26, 2026 09:39

Merge branch 'main' into support-token-editing

0a6f9e5

Clean up minor code practice

7e9717e

Signed-off-by: mialana <aliu@amyliu.dev>

kwokcb approved these changes May 28, 2026

View reviewed changes

Merge branch 'main' into support-token-editing

74b237a

jstone-lucasfilm reviewed May 28, 2026

View reviewed changes

Conversation

mialana commented May 20, 2026

Uh oh!

kwokcb left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mialana commented May 20, 2026

Uh oh!

kwokcb left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mialana commented May 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kwokcb commented May 28, 2026

Uh oh!

kwokcb commented May 28, 2026

Uh oh!

kwokcb left a comment

Choose a reason for hiding this comment

Uh oh!

jstone-lucasfilm left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

kwokcb left a comment •

edited

Loading

mialana commented May 27, 2026 •

edited

Loading