Studio rigging and pipeline tool, NXT, released as open source

Released today, NXT (Node eXecution Tree) is a new open source python layering and sequential execution tool for animation and VFX.



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.


-the NXT team


This looks really fantastic. Probably one of the more fleshed out OSS node graph tools I’ve seen.

1 Like

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:

  1. Can you visualize the progress of the stack/graphs during the execution?

  2. 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)?

  3. 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.

  4. Do NXT’s graph files follow a common format like JSON?

  5. Can you save/reference/inherit individual nodes or node stacks?

  6. Is it possible to execute a graph without the full interface, and expose variables that could be modified from an execution command?

  7. 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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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 that cover a lot of the basic concepts.

1 Like

Perfect! Thank you for clarifying.

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:

  1. Can the graph be cooked down to a single python build file?
  2. Are lambda functions supported? - I’ve had issues with executing them in the past with local scopes when calling them from external files.
  3. 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’ :slight_smile: 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?

Neat stuff!

Hi @chalk,
NXT dev here, great questions!

  1. 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.
  2. 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. :slight_smile:
  3. 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.

1 Like

Just came across this!

1 Like

Thanks for the feedback and great questions - the dev team is tracking this thread.

Thanks to Miquel with MGear for hosting the podcast! He’s provided great support and early feedback on how to have mGear and NXT work well together for pre/post rig scripts.

I wanted to surface a USD/NXT project and example content from Sue Sauer

Squarebit studios has a NXT rig project.
([email protected] for consulting and expressive high end rigging)

1 Like

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.

Is there a roadmap for NXT for the year 2021?

Thank you,

1 Like

@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.