What a lighting plot records and why it outlives the production

By Joey Calkins · Section Light

A lighting plot is a scaled drawing of a rig, and it is the least glamorous document a designer produces. It is also the one that survives. Cues live in a console file that will be unreadable in fifteen years. The plot is a drawing, and drawings keep.

What is actually on it

Every fixture in its true position, drawn to scale on the plan of the building, with the information an electrician needs to hang and address it: what type of unit, which way it points, which circuit and control address it takes, what colour it carries, and what accessory sits in front of it. Unit numbers tie each symbol to a row in the paperwork.

Graphic conventions for all of this are published as a recommended practice by the entertainment technology community rather than invented per production, which is why a crew that has never met the designer can read the drawing on the morning of the load-in. That is the entire point: the plot is written for people who will not be in the room when it is explained.

The plan cannot tell you whether the light arrives

A plan shows position. It says nothing about height, throw distance or the angle at which a beam meets an actor's face, and those decide whether a unit does its job. The section drawing carries that: the room in profile, the bar at its real height, the beam drawn from the fixture to the stage.

Most focus disappointments are section problems discovered on a plan. A unit that looks perfectly placed from above can be too steep, so that eyes fall into shadow, or too shallow, so that the beam spills onto the set behind. The article on front light in this section deals with what those angles do to a face.

The plot is one document in a set

Alongside it sit the instrument schedule, listing every unit with its data; the channel hookup, which reorders the same information by control number for the console operator; and focus notes recording what each unit was pointed at and how tightly, taken during the focus session and worth more than anyone expects two weeks later. A magic sheet, the designer's own one page summary of what does what, exists because none of the formal documents are usable at speed during a cue session.

Why the drawing and the database must be the same thing

The same fact appears in the plot, the schedule and the hookup, which means it can disagree with itself in three places. Purpose built paperwork tools exist precisely to keep the drawing and the data synchronised, so that changing a colour once changes it everywhere.

Where they are maintained separately, the failure is predictable and expensive: a unit is re-coloured on the plot on the Friday, the schedule is not updated, the colour call is cut from the old schedule, and the gel that arrives is wrong for a unit that is already hung. The load-in does not discover this until it is standing on a ladder.

What survives, and what quietly does not

The plot survives because it is a drawing, and drawings can be printed, scanned and read by anyone. The cue data does not, because it lives in a manufacturer's file format tied to a console generation. When that console is retired, the show becomes an object nobody can open.

A neutral text representation for lighting console data was standardised by the industry's own bodies for exactly this reason, and exporting to it is the difference between a production that can be revived and one that has to be redesigned from photographs. It is usually a menu item nobody uses, and it takes a minute at the end of a run.

What the plot does not record

It records means, not results. Nothing on it says what the third act looked like, why a unit was placed where it was, or what the designer was after. A revival built from the plot alone reproduces the rig and not the production.

Intent lives in other places: the cue synopsis, the focus notes, the designer's own annotations, and photographs taken under the actual states rather than at a photo call lit for the camera. Productions that intend to be remounted are well served by treating those as deliverables rather than as by-products.

What we cannot verify

Practices vary by country, by house and by scale, and the conventions described here reflect published recommended practice rather than universal rule; an opera house, a touring one-nighter and a school hall run different paperwork for good reasons. Claims about how well a particular software package preserves data over time come from its publisher, and long term readability of any proprietary format is a prediction rather than a fact.