In the simplest of terms, NXT combines multiple layers of nodes into a single composite layer that is then executable. It is something like Photoshop layers for code. Users are able to mute, solo, override, and extend layers of code. The resulting composite clearly visualizes where attributes and values originated. Colors, node paths, and conveniently placed links allow users to quickly debug code.
Weâd love for you to give it a try and check out the 2 minute overview video.
Havenât had the opportunity to try it yet, but this looks fantastic. Soo glad I didnât embark on building a similar tool.
Whatâs really exciting to see is execution stacks of nodes (with shared variable capabilities and inheritance). IMO this is a vast improvement over just a loose node graph when it comes to representing a sequential build process.
A few questions:
Can you visualize the progress of the stack/graphs during the execution?
Can you visualize and/or report when a node fails? And as a follow-up question, can you save and pull up a prior build attempt state (for troubleshooting)?
Are there performance implications with the token system? I would probably keep Python code extremely lite in nodes anyways, only referencing single function calls from core scripts.
Do NXTâs graph files follow a common format like JSON?
Can you save/reference/inherit individual nodes or node stacks?
Is it possible to execute a graph without the full interface, and expose variables that could be modified from an execution command?
If you can expose variables to be modifiable by a run command, is it possible to also query what they are. (Think building a dynamic property panel from the graph)
Sorry I have soo many questions! Really just speaks to my level of interest.
@Crispy4004 I think I can answer most of your questions.
Yes - we have 2 ways of visualizing during execution, a node has a red outline, and there is a panel on the left that visualizes the entire node exeuction.
When a node fails the python traceback of the failure is printed to the output log of the editor with a link that you can click to travel to the failing node. Regarding the saving and restoring of a build state, this is not possible today, but some pieces of this are being built, would need more context on what you expect.
As with anything, yes, but resolve has not gotten in our way in large graphs(1300 nodes) so far. You can run the editor in ârawâ mode where resolve doesnât happen.
Nxtâs layer files are in fact json, just with specific expected keys. Weâve designed them to be human readable and mergable, most of our save files are in git.
Not in the system today, however if you layer a graph in, you can instance pieces of a graph into another graph. Referencing pieces of a graph has been tossed around, but no firm decision made yet.
YES! We run graphs from the cli most of the time, and we have a cli interface to edit any attribute in the graph. There is also a python interface we use in pipeline tools to run graphs.
Well since all attributes of nodes are query-able, the answer is yes to this. We have a system for building simple pyside UIâs from a graph structure, Iâd need to understand your question more to give you a better answer.
If you have time I would love to hear your feedback on using nxt. We have a series of tutorials on the website here Tutorials - NXT User Docs that cover a lot of the basic concepts.
Just saw this today, it looks awesome and Iâm getting a little bit of deja vu of Disneyâs dRig from going through the videos - especially with the variants, layers, colours, seeing the combined stack, except of instead of building the node graph under the hood, its exposed directly to the user.
Couple of questions:
Can the graph be cooked down to a single python build file?
Are lambda functions supported? - Iâve had issues with executing them in the past with local scopes when calling them from external files.
In addition, is there an execution order you can define or is it based on hierarchy and connection.
The biggest gotchaâs Iâve found with build systems is persistence - I do like the self/stage propagation mechanic - wondering if your going to expose that a little bit more in the interfaces like a reference table etc?
Iâm guessing renaming propagation is on the table - Iâm happy to âpull my pants upâ the meantime but with large graphs I can see renaming attrs etc in large amounts of nodes might get painful.
Is the assumption that this calls an API, is the API, or a adhoc/as-you-see-fit approach? - I can see it being used for both. My only qualm is if you need to pull the backend apart down the road and move the code out of the system what does that look like - tokens getting baked down into individual python files etc?
At the moment, no we do not have a way to âprintâ a graph to a .py file. Weâve talked about it and have some ideas, but nothing solid yet.
Yes! Weâve taken special care to support lambda in the node code block. We have a unittest just for that, if you can break it please let us know.
We have several ways to control the execution order. In general, yes, without special direction NXT will execute hierarchies depth first. However, our API allows you to execute arbitrary lists of node paths. Also, multiple start nodes can be saved into a graph and the API can be told to execute from those points.
Build system persistence, as you put it, is something weâre always pushing on. We have plans for a pause > edit > resume workflow, as of now we just have a pause > inspect > resume. At any point its possible to see a âcachedâ view of the data, in that view NXT shows exactly what code ran, as well as what attributes are available on the STAGE and self objects. We do have a widget called âWorkflow Toolsâ, not yet documented. It basically allows you to create a little window with buttons for executing nodes on demand, very powerful for riggers. You can see it used in the openrig graphs.
As far as rename propagation goes, we do have a basic find and replace system that we hope to expand as we have the time and need.
Our visual editor is fully separated from from our core API, so with only the core installed you can execute graphs. Its designed so that the actual logic to load and execute graphs only relies on built-in Python. Allowing farm nodes to run NXT with as little friction as possible.
We see NXT as an execution orchestrator, meaning your heavy lifting logic is probably best left in external libraries. Going back to your first question, weâve seen the value in having a way to get your orchestrating code out into a giant build script, but we havenât landed on the right way to do that.
We really appreciate feedback positive and negative. We want to make NXT the best tool it can be.
Thank you for creating and graciously open sourcing it as well. Been using it since December 2020 and I hardly ever use the Maya script editor and I have also been moving all my personal project pipelines and workflows to use NXT.
@satishgoda Weâre glad to hear youâre using and enjoying nxt.
We do not have a public roadmap at this point for nxt. Our highest priority right now is to improve nxtâs integration with DCCs other than maya. We expect experimental Blender support to arrive in the next release, and unreal support to follow shortly after. If you have anything youâd like to see in future releases, weâre excited to hear new ideas.
Have a look at this discussion on GitHub. It should add some context and explain the design logic a bit. We need to write a docs page on the topic. Thanks for the question!
the meantime but with large graphs I can see renaming attrs etc in large amounts of nodes might get painful.
