Geometry Nodes to Blender’s Compositor: The Utility Nodes Worth Porting First

The Compositor’s logic gap is real, and Geometry Nodes already solved it

Spend an afternoon building a complex comp tree in Blender and you’ll hit the same wall. The Compositor’s node set assumes you’re pushing color and float data, and the moment you need actual logic — is this value greater than that one, branch on a condition, count something discretely — you’re reaching for approximations that technically work but feel wrong. Geometry Nodes, meanwhile, has a complete set of utility nodes for exactly this kind of work. Porting a subset of them into the Compositor would close a gap that’s been annoying artists and technical directors for years.

Here’s a node-by-node look at what would actually change, and why.

Integer Math

This is probably the highest-priority port. The Compositor works almost entirely in floats, which is fine for color math but creates real problems as soon as you need discrete values: frame numbers, pixel offsets, tile counts, index-based lookups. Right now the workaround is to round a float and hope nothing downstream drifts. For pixel-exact positioning — snapping an element to a grid, for example — that imprecision compounds.

An Integer Math node covering Add, Subtract, Multiply, Divide, Power, and especially Modulo would make pixel-grid arithmetic clean and reliable. Modulo in particular is nearly impossible to fake correctly with floats at arbitrary precision. It’s used constantly in tiling, repeating patterns, and frame-cycling logic, and every current approximation eventually fails at an edge case.

Compare Node

Geometry Nodes’ Compare node handles Equal, Not Equal, Less Than, Less Than or Equal, Greater Than, and Greater Than or Equal across multiple data types in a single node. In the Compositor today, you chain Greater Than and Less Than Math nodes together, sometimes subtracting their outputs to approximate equality. It works. The intent disappears into the wiring.

A unified Compare node would also enable type-aware comparisons — integers to integers, without a float conversion step in the middle introducing imprecision. For compositing rigs that react to scene properties or frame ranges, this is table stakes. It’s not an exotic feature; it’s a missing basic.

Boolean Math

The current workarounds are well-known: Multiply approximates AND, Maximum approximates OR, a Less Than node with a threshold approximates NOT. These work when your inputs are clean binary — 0 or 1. Compositor values rarely stay that clean. Alpha channels have fringing. Masks have soft edges. The approximations start outputting 0.3 instead of 0, and suddenly you’re not doing logic anymore, you’re doing something fuzzier that breaks the downstream rig in ways that are hard to trace.

A Boolean Math node — AND, OR, NOT, NAND, NOR, XOR, XNOR — would let you commit to binary intent. You threshold your inputs once, run clean Boolean operations, and push crisp results downstream. The current approach forces a constant background concern about whether inputs are clean enough, which is a leak in the abstraction.

XOR specifically is underused. Exclusive-or between two masks gives you everything in one but not both — useful for difference matting, detecting changed regions between frames, and building highlight/shadow separation rigs. Right now it requires a small tree of additions and clamps to approximate.

Switch Node with Unified Type Support

Geometry Nodes’ Switch node works across Boolean, Integer, Float, Vector, Color, String, and Geometry. In the Compositor, you can conditionally route image data through a Mix node set to 0 or 1, but that’s semantically a blend, not a switch. When you want exactly one or the other — no interpolation — you’re improvising. For float or vector data, the options are worse.

Unified type support matters most when building modular rigs that reuse subgraphs with different input types. A Switch that works on any type makes those rigs composable. Without it, you rebuild the branching logic from scratch for each data type, which multiplies maintenance burden on complex setups.

This one will require design work in the proposal, not just implementation. The Compositor’s type system differs from Geometry Nodes’, so the mapping isn’t direct. Worth flagging explicitly in a GSoC proposal.

Bit Math

Narrower use case, but it fills a specific gap. Bitwise AND, OR, XOR, NOT, left shift, and right shift on integer values come up when working with packed data — 16-bit or 32-bit values encoding multiple channels, frame flags coming from a pipeline, or EXR metadata stored in integer fields. Without a dedicated node, you’re doing bit manipulation through float arithmetic, which works until rounding errors collapse the packed value. Not the first thing to implement, but in a professional pipeline context it matters more than its niche reputation suggests.

String Nodes

String support in the Compositor is thin. The most useful ports from Geometry Nodes would be:

• Value to String — driving dynamic text overlays from scene data, frame numbers, or render metadata without leaving the comp tree
• Join Strings — building composite labels or constructing file path strings inline
• Replace String — pattern substitution when building overlay text programmatically
• Slice String — extracting substrings, such as shortening a scene name or stripping a path prefix from a file label
• String Length — less glamorous but needed for any padding or alignment logic

Dynamic text overlays driven by scene properties are genuinely painful right now. A common workaround is using drivers and custom properties to feed text into a 3D Text object, rendering that, and compositing it over your output — several layers of indirection for something that should be two nodes. String nodes won’t appeal to every user, but anyone doing broadcast work or automated render pipelines will feel the absence immediately.

What a GSoC proposal should prioritize

If scope is limited — and it usually is in a single GSoC term — the order that makes the most sense is probably: Integer Math first (broadly useful, relatively self-contained infrastructure), then Compare (unlocks clean conditional logic), then Boolean Math (cleans up masking and logic workflows that currently rely on float approximations). Switch type unification and String nodes are valuable but build on the math and logic layer being solid first.

The proposal should also address the type system mismatch explicitly. These aren’t copy-paste ports. The Compositor processes image buffers, floats, and vectors, and each ported node needs a clear mapping to those types. The design question around Switch, in particular, will need more than just implementation time.