Nodezator is a generalist Python node editor

Blender is the reason why I created Nodezator, that is, because I wanted to use Blender's node editor for general computing as well, not only for 3D related workflows. I even bought Bartek Skorupa's DVD course on compositing with Blender, remember that?

Certainly there must be possible in theory to fork Blender's node-related internals into a standalone app. However, I very much doubt that'd be a trivial task, much less for someone in my situation at the time. When I started making Nodezator I had only been using Python for 2 years and knew nothing of C/C++.

According to Blender's developer website, Python is used for "interface layout, simple tools, key-maps, presets and add-ons", while GLSL is used for shaders and all the rest of the code is C++ (and a bit of C). There's also the size of Blender's repo (1GB + 979MB of LFS storage). With 1GB of source, even with someone skilled enough to disentangle the node editor bits from Blender's source, I believe it would still take a lot of time and probably not an endeavour for a single person. I think that is the reason why no one did it before.

That'd be awesome though!

A while ago, I was asked to write a plugin for Blender since I really liked the program. I looked into it but realized that it was a python-only situation and I really just can't stand coding like that, so I passed on it. But if I could get the python ecosystem without having to code like that - that's a really interesting prospect!

Never looked in to its package size, as far as UI goes, but that does sound like something that could be interesting! I do wonder how different it is from imgui, but there could be something there!

Unfortunately I don't have much experience with other similar projects. I did research many of them before deciding to make my own in case one existed that already met my needs. Didn't find what I wanted, which is why I made Nodezator.

However, this doesn't mean what I found was bad. Quite the contrary. There are a few interesting node editor projects in the Python ecosystem, each awesome in their own particular way. Unfortunately, as I said, I can't say much about them, and some of them don't seem to be maintained often. Even so, I'll mention them here in case you want to take a look.

Ryven - always come up in node editor discussions PyFlow - another one that is mentioned often DearPyGui - python GUI framework built on top of imgui, includes facilities for node editing interfaces (I find their nodes very charming) NetworkX - not a node editor framework, but a lib with lots of utilities for representing and operating on graphs

I’ve had similar interests and realized I essentially needed two things:

1. Something like “FastAPI without the HTTP parts”. Basically a request/response cycle with middleware functionality, where we run a registered Python callable in response to a JSON request, but where that JSON request can be from any source, like “pulled from a queue” or read from the command line, instead of “pushed from a web browser”. For that I essentially pieced together a basic task registration decorator class with pydantic’s `validate_call` decorator and let pydantic handle the serialization/deserialization. There are libraries like FastAPI, typer, Celery and others that do this, but they’re all tightly coupled with specific transports. I want to be able to delegate to a developer “build a function that takes this JSON and performs this task and returns JSON”, but not with HTTP (FastAPI), and I don’t want to be required to add Redis to run some small task (Celery), and I do want the task to be callable by CLI (typer), but not only CLI. It seems like there are all of these tools but none of them are loosely coupled enough to do this in a straightforward way.

2. Some way to run a directed acyclic graph (DAG) of those registered tasks. There are lots of tools that do this in varying degrees of heaviness (Airflow, Luigi, Dagster, etc), but for a lightweight solution this is built into Python with graphlib’s TopologicalSorter. But the point here would be, whichever one of these you pick, it helps to have #1 available in a way that allows for generic “running approved Python functions from JSON”.

So I sort of have those parts of it roughed out, but now I’d also like a better UI for it, for instance to allow for a more high level dashboard red/yellow/green status of things, or to enable a less technical user to adjust the schedule of a registered task, and so on. Django’s admin portal is a first step her but ultimately we’d need something more interactive to make it a team effort where more employees can contribute without needing to know Python.

I'm very defensive of my "repl latency". By that I mean, how much effort/time does it take for me to see the results of my change in action? Every node editor that's found its way into my workflow brings that latency down to real time.

They provide much more information so much faster about every change you're making as you're making it. It's like a causality scope. If the widget you're tuning/iterating on benefits from that, they're a joy.

It's really nice for IoT controls, you can edit stuff without taking a laptop to the thing you're editing.

It also doesn't require memorizing anything, although LLMs largely solve that in text.

But before that one off tasks were annoying in text, every three months having to Google the exact same command syntax or dig up an old script as a reference just for one line of code.

> seems like there’s also a general feeling that this is easier than learning how to code, and I guess my question is… is it?

IMHO, node-based programming will never and should never replace text-based programming. Neither is in fact a replacement for the other. There are problems that benefit more from one approach and other problems that benefit more from the other one. There are also many problems that benefit from the cooperation between both approaches. There's even problems for which we should use neither, for instance, when a spreadsheet would suffice.

Unfortunately, many node editor projects sell/promote their tools as silver bullets that will solve all people's problems and replace all their tooling. I think this attitude prevented a more wide adoption of node editors and harmed their reputation a lot. It also prevented a lot of experimentation with them that could have led to more established and efficient workflows.

In the Nodezator project, it is quite the contrary. I only recommend the usage of a node editor, including my own, for specific problems for which node editors are better suited.

Which kind of problems are that? Well, since node editors are still not used much as tools for general computing, we only know about specific domains, like media compositing, for instance. There's much to be researched and experimented still.

I myself use Nodezator for generating position animation data for a 2D game as well as images that I use in video editing workflows in other apps. This year I've been very busy with development work so I didn't do much research, but since last year I've been experimenting with a lot of different tasks and documented my findings a bit. I'm only scratching the surface though. Experimented with SVG image generation and even parametric generation of 3D models. If you want to know more, you can check this thread on twitter/x: https://x.com/KennedyRichard/status/1747605744361300126

I'd also like to experiment more with workflows for non-programmers in the future (for instance, where someone designs a set of nodes and only teaches a non-programmer how to combine them for various tasks), although I already expect node editors to succeed in various domains regarding this (but as I said before, never replace text-based programming). The reason is that it already is used like that with success in other software. For instance, in Blender 3D, where non-programmers use their node editor for many different 3D-related workflows.

Also, not a node editor, but NetworkX also has ways to represent and operate on graph data.

December last year a user managed to run an instance on browser, as can be seen here: https://sefgit.github.io/nodezator/build/web/ (you must wait a few seconds for it to load, them again after the black screen, at least for me, but it works)

Corresponding repo: https://github.com/sefgit/nodezator/tree/nodezator-pygbag-de...

There are no official plans to bring and support Nodezator on the web for now, given how much Nodezator still has to evolve and implement. However, initiatives like that are very interesting and may indeed inspire and motivate us to pursue the possibility in the future.

I'm happy I also included the more serious one (the one which is just an assisting line), so people can switch to it when they need to focus more on the work, though.

After I announced the feature, back when it was just on a dev branch, a lot of people either implemented the feature on their apps or requested the feature from the devs of their favorite projects.

That's the nice thing about open-source projects, that is, that we can all share knowledge/solutions.

I even wanted to submit an addon to Blender 3D, one of my favorite OSS projects, but unfortunately its more recent versions don't even launch on my 4Gb RAM machine (which is understandable considering how the scope of the project grew in the past years).

Socket proximity detection, regardless of the graphics used, should be available in every node interface, cause moving the mouse precisely between sockets to connect them in a single motion can be annoying, specially considering the countless time we must repeat such action in a single node editing session. Increasing the size of the sockets to help this isn't a good solution either, because it would take precious space from the nodes, which is better left for widgets and other useful controls.

You are completely right. This very week someone on Discord presented a relatively simple script he came up (with help from AI) that could do the job relatively well.

As the creator/maintainer of the app, I always appreciate this kind of feedback.

In this specific case, as I said to the person that presented the script, I did think about the possibility in the past, but didn't put time into it because at the time there were a few corner cases that came to mind.

Also, as someone with insight into the many different parts that comprise Nodezator, it is not enough that a existing/pointed solution works, I must also think about ways in which these solutions integrate with the rest of the app, in order for everything to play well together.

For instance, that is not the only improvement I'm planning for the node definitions. I have several ideas, both mine or shared by other users, for improving the node definitions. So I have to plan everything carefully before deciding on anything to avoid redoing things.

Again, thank you for pointing that out though!

Would be interesting to hear what you feel this is well suited for?

Think of nodes representing computation and lines the flow of data between distinct computational units and you have unix pipelines. This is what node red does.

This editor is more complex since it’s connects output to individual inputs.

Nodezator has a long way to go. I only picked Python seriously back in 2017. At the time, type safety was in its infancy and in my experience most Python learning resources didn't even mention type hints, much less static typing.

Then I started making Nodezator in 2019, but only managed to launch it in 2022 due to a health-related hiatus.

Even so, I already have plans to greatly improve type safety in the future, with a related announcement to be made in a week or so.

Nodezator is a serious project, but since its development depends mostly on one person (me), its progress is relatively slow. Despite that, I manage to publish a couple big releases every year. Slowly but surely, though, Nodezator is evolving, mainly due to continued feedback from the community and userbase. So again, I thank you for the feedback.

While I'm always glad to take inspiration from other projects and did research a few of them before creating mine, ComfyUI wasn't among the ones I researched.

In fact, I'm not sure it even existed at the time. I started making Nodezator at the beginning of 2019 and released it on June 2022, whereas the first tagged version of ComfyUI seems to be from May 2023, according to their repo.

I took a lot of inspiration from Blender though, and in fact reproduced many of its features/behaviours.

1. Playing nice with version control. Opening a graph and moving a node by one pixel should cause not merge conflicts. Stop mixing logic and layout together.

2. Lossless round-tripping to a human-readable text format. Text editing tools are insanely powerful for many things. Not being able to use them is a huge drawback of node-based development

3. A common format that allows people to build tools that are agnostic to your specific environment. Node editors themselves should be like IDEs - not tied to a specific app. I don't use a different code editor when I switch from Godot to Unity - why is the node editor any different.

4. Just better everything. Batch/bulk changes, search/replace, auto-align. The quality of these essential features varies from "passable" to "what?"

Everyone is reinventing the wheel all the time. Every platform, app, environment has it's own way of editing node graphs. And most of them suck. The amount of wasted effort for mediocre outcomes...

Finally - are we sure node graphs are the best metaphor? Modifier stacks (like 3DS Max) give you 80% of what you want for many use-cases and they are a lot easier to learn and use.

Event grids are great for many things - and again they are much simpler.

Maybe node graphs should be the "expert mode" not the default (although the real "expert mode" is surely good old text coding - with all it's faults)

For example, I could use a bunch of arithmetic nodes to implement matrix multiplication, but a RotateAroundPoint node would be far more useful and desirable.

For low-code users, this is often exactly what they need. You could write a RotateAroundPoint function for them to use, but then they’re still managing a lot of the boilerplate around writing code. Graph editors solve many of these pain points when the correct nodes for the problem-space are offered.

The result was FlowHub.org which differentiates between visual changes and textual changes. Which was my main focus.

There is no visual concept for merge conflict or similar but at least versioning is far simpler since comparison between versions is much simpler.

Given the examples, I believe this is targeted to such uses.