nDisplay keeps one camera view synchronized across many machines

The stage

Epic Games documents nDisplay as a system inside Unreal Engine that synchronizes rendered output across networked computers so that many displays, or many processing zones on one LED wall, show a single coherent view. The nDisplay Overview for Unreal Engine 5.8 describes a cluster of one primary node and any number of secondary render nodes, each rendering a viewport sharing the same view origin, so the assembled image reads as one space rather than mismatched tiles. The workload can be split further, with an inner frustum, the wall area visible inside camera frame, rendered on a second GPU to protect frame rate. This is a living reference tied to a specific engine version, retrieved 16 September 2026.

What the documents establish

The documentation establishes what nDisplay is for in Epic's own terms: frame synchronization across render nodes, configured through an nDisplay Config Asset that stores cluster topology, display specifications and GPU assignments, then mapped to screens through output mapping. Epic's Film & Television product page lists nDisplay alongside virtual scouting, virtual cameras and Live Link as one item in a broader toolset, not the whole of it. nDisplay solves a narrow problem, keeping render nodes in lockstep, and says nothing about color pipeline, tracking or genlock. Both sources are Epic's own material; neither independently verifies performance under a named vendor's hardware.

The department view

The people who touch nDisplay directly are rarely in front of the camera. A virtual production technician or the crew running the brain bar builds the Config Asset before the DP lines up a shot: assigning which PC drives which viewport, matching GPUs to screen segments, and deciding whether the inner frustum gets its own node. The documentation notes the nDisplay Root Actor need not live in the level at all; a cluster can launch from an external config file or through Switchboard, separating the technical setup from the level itself. The trade-off is coverage against complexity: more nodes buy resolution and frame-rate headroom, at the cost of a network that must stay synchronized for the whole shoot day.

What to check before you build

This is an editorial checklist, not Epic's own guidance. Confirm the wall size and node count actually require multi-machine rendering; a small single-screen setup may not need a cluster at all. Confirm which engine version the documentation applies to, since options change between releases. Confirm with the LED and processing vendor how their genlock interacts with nDisplay's own frame sync, since Epic's documentation covers the engine side only.

• Does this build's screen count actually require more than one render node?
• Which engine version does the nDisplay documentation describe, and does it match the pipeline in use?
• How does the LED vendor's genlock guidance interact with nDisplay's cluster timing?

nDisplay is a synchronization layer, not a virtual production system by itself. Treating it as a checklist item rather than the whole workflow keeps the conversation focused on what actually needs multiple machines in lockstep.