How PixiEditor's Node Graph Workflow Works

PixiEditor's Node Graph is a visual, connection-based system for building graphics, animations, and brushes as editable recipes rather than fixed pixels. You wire nodes together to define how an image is generated or modified, and because the result is computed from that graph, you can reopen it later and change any step without losing earlier work. It's the right fit if you want reusable, adjustable visuals — procedural art, custom brushes, or effects you'll iterate on — and a poor fit if you just want to smear pixels and be done.

The core idea: a recipe, not a result

In a normal raster editor, painting changes pixels directly. Once you've drawn over something, the original is gone unless you kept a separate layer or a backup.

In the Node Graph, you describe how the image should be produced. Nodes are the steps; the connections between them define the order and flow of data. The canvas you see is the output of that graph, recomputed as you change it. This is what PixiEditor means by "fully non-destructible" graphics and animations — the graph is the source of truth, and the visible image is derived from it.

A simple mental model: think of a cooking recipe. Changing "2 eggs" to "3 eggs" doesn't require throwing out the cake and starting over — you edit the recipe and it re-bakes. The Node Graph is that recipe for your visuals.

What you actually connect

PixiEditor's site describes the Node Graph as the engine behind several features, not a separate mode you visit once:

• Procedural Art — "Connect nodes to easily compose complex visuals. From pre-built effects to custom shaders, the possibilities are endless!"
• Brush Engine — "Build your own advanced brushes using the Node Graph. Sample layers, use custom shaders and more. Start from scratch or tweak the built-in ones."
• Drawing — "Draw in any style with a node-based Brush Engine."

So the same graph concept serves two purposes: generating artwork procedurally, and defining how a brush behaves when you paint with it. A brush built this way can sample layers and apply custom shaders, which is why PixiEditor calls the 2.1 brush engine "node-based."

A concrete example

Say you want a texture of scattered dots whose size and spacing you'll keep tuning for a game background.

1. Start from a generator node that produces the base pattern (dots, noise, or a shape).
2. Feed it into a transform or effect node to control scale, spacing, or color.
3. Connect the result to the output so it renders on the canvas.
4. Adjust a value on any node — dot size, density, color — and the canvas updates without you redrawing anything.

Later, if you want the same texture at a different density, you reopen the graph and change one number. Nothing is baked in. That's the practical payoff of the non-destructive approach: one graph, many variations.

For brushes, the same logic applies. Instead of accepting a fixed brush tip, you assemble one from nodes — sampling layers, applying shaders — and tune it until it paints the way you want.

When this workflow helps — and when it doesn't

The trade-off is upfront effort. Wiring a graph takes longer than drawing a stroke, so it pays off when the work is something you'll reuse or refine. For a single throwaway edit, the plain raster tools are faster.

How it fits the rest of the app

The Node Graph isn't isolated — it sits alongside PixiEditor's other toolsets (Pixel Art, Image Editing, Drawing, Vector Art, Animations), and the site notes you can "mix freely with raster images." So a typical project might combine a procedurally generated background from the graph with hand-painted pixel art on top. PixiEditor runs as a free, open-source, cross-platform desktop app that works offline, which matters if you want to build these graphs without a connection.

If you're deciding whether to invest time in learning it: start with a built-in brush or a pre-built effect, open it, and look at how the nodes connect. That's the fastest way to see whether the recipe model matches how you like to work.