Core rendering system in Nuke, Fusion, or similar — processes node trees and effects with either real-time display or farm computation. Determines speed, memory efficiency, and output precision.
Compositing Engine
The compositing engine is the heart of any professional compositing software—it's the engine that executes your node structure in real-time or during the final render. It's best to think of it as an intelligent calculator that tracks every connection between nodes, optimizes data flow, and decides which calculations happen in what order. In Nuke, you work with the DAG engine (Directed Acyclic Graph), which is extremely efficient because it detects redundant calculations and caches results between frames. Fusion runs a similar logic, only with 3D integration more deeply embedded into the engine.
The speed of your work depends directly on engine optimization—and you notice it immediately when scrubbing through long shots or rendering complex keyer stacks. An efficient engine prioritizes what you're currently seeing (viewport optimization) and pushes more complex calculations to the back. This is why playback runs smoothly, even though you've chained seven rotoscope nodes, four qualifiers, and a 3D tracker. It's not magic—it's clever resource allocation by the engine. It also recognizes that certain nodes can be cached because they don't change—for example, a static Grade node before a roto animation.
When rendering on the farm, the engine becomes even more critical. Your node structure must be interpretable by the engine so it can be distributed across hundreds of CPUs. This is a balancing act: too many dependencies between nodes, and the engine can't parallelize; too little structure, and you'll hit bottlenecks, especially with 4K-60fps work. That's why it's important to understand where the engine detects bottlenecks in your script—nodes that are blocking everything.
Practically, this means: keep your flows linear and avoid circular dependencies (which the engine immediately rejects). Use expression linking intelligently—every expression costs CPU time during rendering. And when you work with high bit depth (16 or 32 bits), the engine consumes more memory but becomes more precise. Most errors don't arise from misuse, but from your script overwhelming the engine—too many Read nodes simultaneously, uncompressed sequences, or a loop you didn't intend to create.