Projection mapping onto moving objects: mesh warping and edge blending for a live show

Mesh warping: pushing the picture onto the shape

The basic operation is mesh warping. The output image is subdivided into a grid (commonly somewhere between 4×4 and 32×32 for a live rig) and each vertex of that grid can be dragged. Drag them until the projected test pattern lines up with the physical edges of the object, and you have a warp that will hold for as long as nothing moves.

Doing this by eye, on site, is still how a large share of shows are calibrated. It is slow and it is unglamorous: someone stands at front of house with a laptop while someone else calls out whether the line is on the edge yet. The alternative is to build the warp from a model, if the scenic drawing and the projector position are both accurate, the mesh can be calculated rather than discovered, and the on-site pass becomes a check rather than a build.

The practical limit on mesh density is not the software. It is that every vertex you add is a vertex somebody has to verify after the next load-in.

Edge blending across multiple projectors

A single projector rarely has the brightness or the coverage for a large surface, so shows stack them. Two projectors covering one wide surface overlap in the middle, and in that overlap the surface receives light from both, twice the brightness, in a band, straight down the picture.

Edge blending fixes this by ramping each projector's output to zero across the overlap region, so their sum stays constant. The ramp is not linear; it follows a gamma curve chosen to match the projectors' actual light output, and getting it wrong produces either a bright seam or a dark one. On a rig with four or six machines covering a wide scenic build, the blends are the part most likely to need attention on a show day.

The problem of moving objects in a live show

Everything above assumes the object holds still. In a live show it very often does not: pieces fly, track, rotate, or are pushed on by hand. Once the surface moves, a static warp is wrong the moment the move begins.

This is where the practical question sits. How projection mapping works on a moving object is decided long before showtime, by whether the movement is repeatable, and the two answers below are the only ones that survive a touring schedule.

Timecoded motion

The most reliable answer is to make the movement repeatable and put it on the same clock as everything else. If a piece flies in on a motor to a known position over a known duration, the warp can be animated along the same curve. It works because it removes the uncertainty rather than measuring it, and because the same timecode already drives the lighting and the content.

Tracked motion

Where movement cannot be made repeatable, the object can carry markers and a camera system can report its position, with the warp updating live. This is what makes free-moving projection mapping possible at all. It is also fragile: it needs sightlines the show may not want to give up, and it fails in exactly the smoke-filled conditions the rest of the picture depends on.

Content that forgives

The cheapest answer is often authorial. Content with soft edges, without hard registration to a physical corner, will tolerate several centimetres of drift before anybody notices. Content with a crisp graphic line running along the edge of a flat will not tolerate one. Designers who have been burned once tend to design for the tolerance they will actually get.

What it hands over, and what it needs

Projection mapping sits between two other trades and is squeezed by both. Upstream, it needs stage architecture to freeze: the model, the positions, the motion paths. Downstream, it hands a defined canvas to the content team, and to whoever is running the picture live. In between, previs is what lets all three happen in parallel rather than in sequence, because it produces the geometry before the geometry physically exists.

The tools involved are covered separately: MadMapper for the warp and blend layer, Resolume where the same rig also has to run clips live, and Notch when the content itself needs to be generated in real time rather than played back.

Calibration is a daily cost, not a setup cost

The alignment achieved on the first day does not survive a truck. Panels settle, scenic pieces are re-flown a few millimetres out, a projector gets nudged during focus. Every mapped show therefore carries a re-calibration routine, and how long that routine takes is a design decision made months earlier.

Designs that survive routings share a habit: alignment references are built into the physical object (a hard edge, a corner, a marked point) so that recovering the map is a matter of matching known features rather than judging by eye. Designs that skip this are re-aligned by taste every day, differently each time. The tooling for it is under the dedicated mapping stage.

Where projection mapping appears in the archive

Three entries here are mapping problems of very different shapes. A closed cube with the performer inside it has no easy surface anywhere on it; a listed building has compound curves that have to be measured rather than invented; and a performance installation is deliberately hard-edged so that the map can be recovered quickly in a different room every night.

What this trade hands over, and what it is blocked by, is set out under the design sequence. Terms are defined in the glossary.