-
Notifications
You must be signed in to change notification settings - Fork 358
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add API to allow input reordering on node graphs #2116
base: main
Are you sure you want to change the base?
Conversation
Would this need some work on the usd side to capture the ordering somewhere? Perhaps UsdUI or something? |
Hi @meshula, Does USD already have separate specifiers for UI ordering (e.g. is this this stacking order in UsdUITokenType ? |
Stacking order relates to the screen depth of nodes (this node should appear over that node if they overlap). Reading the mx code, I see that childOrder is not a user imposed reordering of the nodes, but rather encodes a construction order. Since hdMtlx iterates that list, there's no reordering hints necessary at that end as order is implicit in that loop. ✅ #does-it-usd |
Thanks for the explanation about stacking order. To confirm your summary of
Thus this utility to change construction ordering is being proposed to help support both the above workflows for user ordering. That all said there is nothing required on the usd side. If at some point in the future definitions or graphs have additional meta-data to specify input ordering than this can be brought up. |
@kwokcb Rather than making this a core method of the |
@jstone-lucasfilm - Do you believe that this operation would only be used by people authoring python code? It seems like there might be use cases outside of python, and providing it as part of the C++ API would allow everyone to benefit from a common implementation. Maybe there are other reasons other than using it as a python API example that you think it shouldn't be part of the C++ API? |
@ld-kerley My initial sense is that this new method is a very thin wrapper around the existing That makes me wonder whether it's better as a "best practices" example for new MaterialX developers, provided either in C++ or Python, rather than a core method that we provide along with It's a very subjective sense on my part, though, and I'm open to a discussion of the benefits of this new API method in addition to our existing ones. |
I guess I think things like input validation are exactly the sort of things it's good to share as part of the library, instead of leaving it to the users to implement themselves. If the hesitation is to increase the API surface of the Nodegraph object itself - perhaps we could start creating free function that perform these helper tasks, but still include them as part of the library? |
Yes, I was thinking that @kwokcb's new That might point to the idea of making this a "best practices" example somewhere in the MaterialX codebase, allowing developers to derive their own custom logic from this pattern, rather than making this a permanent feature of the NodeGraph API. I'm definitely open to ideas on this, and we don't yet have an obvious home for best practices C++ examples in MaterialX, though I think having one would potentially be a real benefit to users. |
Workflow Motivation
In order for users to specify interface ordering for node graphs they need to re-order the storage order of child inputs. Additionally, when creating new definitions (
nodedef
) they may which to specify the ordering of child inputs as part of definition publishing.Proposal
Provide a simple atomic API to allow for inputs on node graphs to be re-ordered without affecting non-input child ordering.
The proposed API name is:
NodeGraph::setInputOrdering()
where a list all input names specifies the desired ordering.