MaterialX icon indicating copy to clipboard operation
MaterialX copied to clipboard

Graph Editor : Functional Nodegraphs in working document are editable

Open kwokcb opened this issue 9 months ago • 2 comments

Issue

If you have a functional nodegraph in a document that you load in, it will show up and be editable. Node instances can be expanded and editable.

This is inconsistent with the same type of graphs loaded in from std library which are hidden and expanded instances are not editable.

Proposal

Make these have consistent non-editable behaviour.

kwokcb avatar May 04 '25 13:05 kwokcb

I would actually propose the opposite- to have it so all functional nodegraphs can be opened for editing (eg to see how they work, or to copy/paste things from them into a different nodegraph you're editing), and have it so the file system's read-only status of the nodegraph's file dictate whether you can save changes to a nodegraph back to that file. Presumably, nodegraph files for stdlib and other published studio libraries would be made read-only.

If you can't open and edit functional nodegraphs, how would you author them, or fix bugs or improve them?

dbsmythe avatar May 04 '25 15:05 dbsmythe

Hi @dbsmythe ,

I actually logged this a while back and it did behave like this but seems to have regressed?

The logic was added for safety for the editor. In it's current state:

  1. In place editing can easily corrupt the data (graph). i.e. make it mismatch the definition.
  2. There is no validation mechanism to check the modified graph against the definition.
  3. There is no mechanism to update ("publish") the corresponding definition to be valid. In fact there isn't even a compound graph to definition publishing mechanism (*)
  4. There is no way to handle node instances of definitions that have been modified.

BTW, I'm not sure if initial write state of a document is a robust criteria. e.g. if you load from string there is no read/write state. If I import a file that's read only what does that mean ? What if you only want some of the definitions to be read-only ? etc.

I thus put forth that until definition editing / publishing logic is clarified and the editor supports it that it's better to not allow this workflow for now.

(*) I did start to add in compound nodegraph to node definition publishing into this editor which is similar to Maya's or QuiltiX. There are user requests for this on Slack just for this part, but the proposed changes have not been checked in and there is no progress due to lack of resolution for definition management logic.

I don't know of any tool that allows in-place definition editing.

I'll leave this info with a ping with @lfl-eholthouser. IMO, either way is fine as long as it's safe and users are clear on what's happening.

kwokcb avatar May 06 '25 12:05 kwokcb