A photoreal previs can still run on the wrong fixture data

The picture

Across the live-events lighting software in this batch, a dependency is documented rather than merely inferred: a rendered lighting cue is only as accurate as the fixture profile loaded into it, and a wrong or generic profile can render as convincingly as a correct one. The GDTF Group's own site describes the General Device Type Format as the industry's shared way of exchanging fixture data, stating its purpose is to give professionals accurate profiles that work the first time, every time, so that, in the Group's words, fixtures work exactly as intended.

What the documents show

A named, documented instance of the dependency appears in Syncronorm's own showcase account of Battle of the Busk, an educational lighting event at the LDI Exhibition. There, lighting designer Luther Frank is described using Depence for the first time on a rig of nine fixture types, several newly released; after the design was exported by MVR into Depence, Frank connected the software live to an MA3 console to test profiles, identify quirks, and clean up issues before the files reached the stage. That is a documented instance of a designer treating the profile, not the render, as the thing requiring verification. Separately, the Vectorworks newsroom article on Spotlight and Vision describes the same mechanism from the vendor's side: GDTF files travel with the MVR export because previsualization software needs correct fixture data, distinct from 3D geometry, to behave correctly. No source reviewed documents a production where an unverified profile caused an error visible only later; this entry does not claim one occurred.

What it is allowed to decide

On these sources, a lighting previs image can support decision class 5, technical execution, once its fixture profiles are verified against the physical rig, as in the documented Battle of the Busk workflow, but not before. It holds Provenance, since GDTF ties a profile to a stated manufacturer and device. It does not hold Photometric authority by default: the same render can come from a verified profile or an unverified substitute, and nothing visible in the image distinguishes the two. That is the batch's central documented failure mode, evidenced here rather than asserted.

The disclosure label

A disclosure for a lighting previs image in this category, dated 16 September 2026 and asserted by the programmer who built it, would read: this class 5 technical-execution render's Photometric authority depends entirely on whether its GDTF fixture profiles were verified against the physical instruments, a step documented here as a live console connection and profile test, not on rendering quality; state which verification, if any, was performed.

• Was each fixture profile supplied by the manufacturer, edited in-house, or substituted for a similar model?
• Was the file connected to a physical console or rig to test profiles before the image was shown to a client, as in the Battle of the Busk case?
• Would the image look any different if a wrong profile were silently substituted for the correct one?

The documented cases here agree on one point: the render itself cannot carry this warning, so whoever approves the picture has to ask for the profile record separately.