NodeBox 3: a node-based environment for generative art and graphic design

What the node-based workflow actually gives you

NodeBox is a new software application for creating generative art using procedural graphics and a new way to approach graphic design, and the three highlights in the README are the whole proposition.

The first is that it is node based, using a non-destructive workflow where every operation is represented by a visual block of code. The second is that it is open to extend, meaning you can look at and change the source of every code block. The third is that nodes can be written in Python or Clojure.

Non-destructive is the word that carries the most weight. In a conventional drawing tool, an operation changes the thing you are drawing, and undo is a history of the document. Here, an operation is a node, the node has inputs and outputs, and the result is computed by the graph. Change a value in the middle of the graph and everything downstream recomputes. That is the same model as a node editor in a game engine, applied to graphic design rather than to a scene graph.

The second highlight is the one that makes the first safe. Because every block is real source code, a node you did not write is still a node you can read, and a node you do not understand is a node you can open and change. For a tool that asks a user to compose a system rather than fill in a dialog, that is the difference between a tool people trust and a tool people work around.

The homepage is nodebox.net, which carries the downloads, the documentation and the forum. The licence field on the repository says GPL-2.0, the primary language is Java, and the last push was on 2026-10-16.

Building on macOS and Windows

The build system is Ant driving Maven, and the README gives per-platform instructions.

On macOS, NodeBox requires a recent Java JDK with a baseline of JDK 25, and Homebrew for Ant and Maven.

brew install ant maven

Then the clone and the development run.

git clone https://github.com/nodebox/nodebox.git
cd nodebox
ant run

# To create a full app (the build will be in dist/mac):
ant dist-mac

So ant run gives a running development version, and ant dist-mac produces a bundled application in the dist/mac directory. Those two targets are the pattern for every platform.

On Windows the list is longer, because the installer is built with the WiX Toolset rather than with a platform-native packager. You need Git, a recent Java SDK, Ant and the WiX Toolset, and three environment variables have to be set before anything works.

set JAVA_HOME=c:\java\jdk
set ANT_HOME=c:\java\ant
set WIX_HOME=c:\java\wix
set PATH=%PATH%;%ANT_HOME%\bin;%WIX_HOME%\bin

And then the same clone, the same ant run, and ant dist-win to produce an MSI in dist/windows, after setting the correct version in the version.properties file under the resources directory.

The WiX dependency is the notable difference from the macOS path. A Java application is portable enough to be packaged without a native toolchain, but a Windows installer needs one, and the README makes it a required step rather than an optional extra.

The Linux and BSD instructions, and the JDK version they disagree with

The Linux section gives one block per package family, and they are the shortest instructions in the README.

On Ubuntu or an APT based distribution.

sudo apt install git openjdk-11-jdk ant
git clone https://github.com/nodebox/nodebox.git
cd nodebox
ant run

On Fedora or a YUM based distribution.

sudo yum install git java-11-openjdk ant
git clone https://github.com/nodebox/nodebox.git
cd nodebox
ant run

On Arch there is an AUR package, nodebox-git, which can be installed with yaourt, or cloned and built with makepkg into a package file and then installed with pacman -U. Once installed, NodeBox launches as a desktop application or from the terminal with the nodebox command.

On FreeBSD and PC-BSD it is the pkg package manager.

sudo pkg install git openjdk-11 apache-ant
git clone https://github.com/nodebox/nodebox.git
cd nodebox
ant run

Here is the inconsistency worth flagging. The build matrix line at the top of the README says JDK 25 only, and other JDK versions are not supported. Every Linux and BSD instruction above still asks for openjdk-11 or java-11-openjdk, which is Java 11, not Java 25. The macOS and Windows instructions correctly say a recent JDK with a baseline of 25.

So the Linux and BSD blocks are behind the current requirement, and a reader following them literally will hit a build failure rather than a clear version error. Installing a JDK 25 on those distributions is the fix, and the packagings differ enough per distribution that the instruction could not simply be substituted without knowing each one's package name.

The end-to-end suite and the documentation layout

The repository has a UI end-to-end suite, and the way it is invoked is worth noting because it is opt-in.

NODEBOX_E2E=1 ant test-e2e

The environment variable gates it, and the README says to run it with a graphical session available, which makes sense for a desktop application whose tests drive the interface.

The artefacts, screenshots and stack traces, are written to build/e2e-artifacts by default, and the location can be overridden with the NODEBOX_E2E_ARTIFACTS environment variable. Both of these are the kind of detail that saves an afternoon when a test run fails on a machine you did not configure.

The developer documentation lives in a docs/ directory with three documents, and the README lists them. docs/README.md is the index, docs/development.md covers the build and test workflow, and docs/architecture.md is the system overview. The repository also has an AGENTS.md, an AUTHORS file and a .travis.yml, the last being a leftover from the earlier continuous integration setup given that the README's build badge points at a GitHub Actions workflow instead.

The repository layout shows the shape of the project. There is a build.xml for Ant, a pom.xml for Maven, a src/ directory for the application, a lib/ and libraries/ directory, a platform/ directory for platform-specific code, a res/ directory for resources, an xml/ directory, a specs/ directory, examples/ with a 01 Basics and a 02 Topics directory, an artwork/ directory, and an appcast/ directory for the release feed.

Where NodeBox 3 is the wrong choice

The first limitation is that the output is a desktop application, not a deployable artefact. The build targets produce a macOS app bundle, a Windows MSI and a Linux package, and the example files are in a repo of project directories. A generative artwork you make here is a thing you ran in NodeBox, not a thing you put on a web page, unless you port it. That is a different market from the browser-based generative art tooling.

The second is the toolchain. Ant, Maven, a JDK, and on Windows the WiX Toolset, is a substantial build environment for a graphics application, and the JDK 25 requirement plus the openjdk-11 instructions in the Linux section means the documented setup does not currently agree with the documented requirement.

The third is the release history. The recent releases are v3.1.0 from 2026-06-14, then Version 3.0.53 from 2022-02-18 and Version 3.0.52 from 2021-01-15. So the tagged 3.0 line ran from 2021 into early 2022, and the next tag is a 3.1 in mid 2026, with commits in between. The naming also changes between the two, from Version 3.0.x to v3.1.0, which suggests the tagging practice was reset along with the version line. For a project with a long history, that is worth asking about before depending on a specific build.

The fourth is the Java dependency in a design tool. A generative art application implemented in Java is unusual, and it means the whole JVM is in the process, with its startup cost and its memory profile, for a task that a browser or a native application would do more cheaply.

The fifth is that the language choice for nodes is Python or Clojure, both of which need to run inside the JVM. Clojure is a natural fit, and Python needs a JVM-hosted interpreter, which is one more moving part in the node evaluation model.

How NodeBox 3 compares with TouchDesigner and with Processing

TouchDesigner is the closest comparison by purpose, and the difference in approach is what the node is. In TouchDesigner a node is a compiled operator in a network, and the network is the program. In NodeBox every operation is a block of code in a dynamic language, and the graph wires them together. The first is a real-time system aimed at live visuals and installations; the second is a design tool aimed at static or sequence-based generative work.

The second comparison is with Processing and its derivatives, and here the difference is the graph. A Processing sketch is a program in one file that you run top to bottom, so a change to a variable early on affects everything downstream but you see it by re-running. A node graph makes the same dependency structure visible and editable, which is a different way of working on a system with many parameters.

The third comparison is with p5.js or a browser-based canvas tool, and the difference is delivery rather than capability. Generative work that ends up in a web page belongs in the browser, where the code is the deliverable and the sketch is a development tool. NodeBox's deliverable is the application, so a piece made there generally has to be reimplemented in a browser-facing language to be published, and the graph itself is not portable.

The fourth is a comparison within the design world rather than the programming one. NodeBox sits closer to a visual design tool that happens to compute, than to a code editor, and its non-destructive graph is the part that makes it worth learning for anyone who has used After Effects or a node-based compositing tool.

Licence, project state and what to check before you build

The licence field on the repository says GPL-2.0, with a LICENSE.txt file at the root, so the source is open under copyleft and anyone running a modified build as a service has obligations. The AUTHORS file at the root records contributors, and the repository also carries a CODE_OF_CONDUCT-style contributor setup through the AGENTS.md and the GitHub configuration.

The project is not archived and the last push was on 2026-10-16, so the code is current. The release history, as noted, has a long gap between the 3.0 tags and 3.1.0, and the README's build badge points at a GitHub Actions workflow named Build and run tests, which is the current continuous integration. The .travis.yml at the root appears to be a historical leftover.

There is also a convert_svg_files.py at the root, which tells you something about the assets, and the artwork/ directory holds the icons and branding, with the appcast/ directory holding a release feed, which is the mechanism an application uses to tell a desktop updater that a new version exists. The makeinstaller.nsi and FileAssociation.nsh files are the other legacy Windows packaging pieces alongside the WiX setup.

Four things to check before you build it.

The JDK version, which the build matrix says must be 25, and which the Linux and BSD instructions in the README have not caught up with.

The examples, which are organised into a 01 Basics and a 02 Topics pair of directories, and which are the fastest way to see what the graph model looks like in practice before you build anything.

Whether the E2E suite is something you can run, since it needs a graphical session, and whether the ordinary test target is enough for your changes.

And the licence, if you intend to distribute a build, since GPL-2.0 covers the application code and the artwork directory will have its own terms to check.

Editorial conclusion

NodeBox 3 suits a designer or programmer who thinks in graphs and wants to build a visual system rather than draw a picture, and who is prepared to work inside a Java application with Ant and Maven on the build. It is the wrong tool if you want to ship a generative artwork to the web, since the artefact here is a desktop application, and the wrong choice if you want a hosted node editor. Before building, note the JDK 25 requirement, which is stricter than the openjdk-11 packages several of the README's Linux instructions still tell you to install, and that the release history jumps from a 3.0 series in 2022 to 3.1.0 in 2026.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. nodebox/nodebox on GitHub
3. Project website
4. README
5. Releases