From a lighting plan to a browser preview: what has to survive the trip?

Opening an MVR file is not the same as importing a lighting plan.

A parser can read GeneralSceneDescription.xml, create a collection of objects and report success. The result can still be useless.

Fixtures may be in roughly the right place but lose their identity. Addresses can be missing. Geometry can arrive four kilometres long. Layers can be flattened into one anonymous pile. The preview looks busy, the console shrugs, and technically nobody has thrown an exception.

A useful browser preview has to preserve more than pixels.

An MVR file is not a screenshot

MVR — My Virtual Rig — describes the physical and logical structure of a show setup. Its job is not to store one final camera view. It carries objects, hierarchy, transforms, device references and patch information so another application can reconstruct the project.

The MVR specification describes that scope explicitly: real-world components, logical patch information and the kinematic chain have to survive the exchange.

GDTF handles the device definition beside it. MVR says which fixture is in the scene and where it belongs; GDTF says what that fixture is and how it behaves. The shorter explanation is in GDTF vs MVR — fixture definition vs scene exchange.

For a browser-based lighting plan, the important question is therefore not “Did the upload complete?” It is “Can somebody still understand and use the rig afterwards?”

Fixture identity has to survive

A fixture is not just a mesh with a transform.

At minimum, the receiving tool needs a stable identity, the intended fixture type, its selected DMX mode and the names or numbers people use to recognise it. Those pieces connect the imported object to patch, control, collaboration and later exports.

Lose that identity and several identical moving lights become unrelated 3D models. They may look fine from the front. They no longer behave like a lighting system.

Stable identifiers also matter once more than one person touches the scene. A comment, selection, change or future MVR update has to refer to the same object without guessing that “Moving Head 12” probably still means the twelfth item in an array.

Patch information is part of the plan

Universe, address and DMX mode are not optional decoration.

A rig can be visually perfect and still arrive at a console with nothing useful patched. We recently tested exactly that failure mode: the fixtures existed, but invalid or missing address data left the desk with no sensible way to place them.

After repairing the MVR with valid addresses and consistent numbering, the same scene imported cleanly into both MagicQ and grandMA3 onPC. No renderer changed. The difference was that the plan finally described an executable patch instead of an attractive arrangement of lamps.

Importers should validate this data and explain what is wrong. Silently inventing addresses may make a screenshot look complete, but it also creates a new patch that nobody asked for.

Transforms need units, hierarchy and a shared idea of forward

Every object needs a position and orientation. That sentence hides an impressive number of ways to be wrong.

A matrix may be valid while using a different axis convention. A child transform may be interpreted as world space. A fixture can stand in the correct location while its head points backwards. A truss can be imported with the correct numbers and the wrong unit.

MVR specifies metres for its legacy .3ds geometry. glTF also uses metres. Treating glTF coordinates as millimetres does not make the import slightly inaccurate; it produces trusses several kilometres long and tens of metres high. The maths is consistent. The venue is less convinced.

Hierarchy matters for the same reason. A fixture attached to a truss should remain attached when the truss moves. A moving head needs its base, yoke and head relationship. Flattening every transform into a bag of world-space objects discards information the next tool may need.

Layers and positions carry planning intent

A lighting plan contains organisation that is not visible in a beauty render.

Layers separate systems, departments or working areas. Positions identify meaningful rig locations. Names and numbering help humans navigate a project that may contain hundreds of similar objects.

A browser viewer does not have to reproduce every source application's interface. It does have to preserve enough structure that the project remains legible.

That means showing empty layers rather than pretending they never existed, keeping fixture and truss relationships, and avoiding accidental semantics. In MVR, a Position reference is not simply another transform and it is not an invitation to invent multi-group membership.

Some of this is still active work in FlexViz. The important product decision is already made: imported structure should be retained deliberately, not flattened because a simpler database table was convenient.

Geometry should fail visibly, not silently

Real MVR archives are not curated demo files.

They contain old .3ds meshes, glTF assets, parametric objects, incomplete GDTF files and exports that interpret the standard with varying enthusiasm. A production importer needs fallbacks.

If a fixture mesh is missing, the useful result is a clear generic stand-in that keeps position, type and patch visible. An invisible object is worse. A hard failure that hides the rest of the scene is worse again.

The same rule applies to unsupported detail. Preserve the information that can be trusted, flag what could not be reconstructed and let the user decide whether the missing piece matters.

A browser preview is a continuation of the plan

FlexViz is not trying to replace Vectorworks, Capture or the CAD package in which the rig was drawn.

The browser solves a different part of the workflow.

• Open the current scene without installing the authoring tool.

• Switch between top, front, left, right and 3D views.

• Inspect fixture identity, transforms and patch.

• Share the scene with somebody who needs to review it, not redraw it.

• Connect live control when the visual result matters.

That only works if the browser receives a plan rather than a loose collection of triangles.

The useful hand-off is not CAD to screenshot. It is CAD to structured scene to a view that remains understandable, inspectable and shareable.

What has to survive the trip

The minimum useful chain is straightforward to list and annoyingly detailed to implement:

• Identity — stable IDs, fixture type, mode, names and numbers.

• Patch — universes, addresses and footprints that another tool can actually use.

• Transforms — positions, rotations, units and parent-child relationships.

• Organisation — layers, positions and the structure people use to navigate the rig.

• Geometry — real assets where possible, explicit fallbacks where not.

• Behaviour — enough GDTF data to turn a placed object back into a controllable fixture.

FlexViz already imports MVR and GDTF scenes into plan and live views, including fixture placement and patch data. Layer handling, missing-geometry fallbacks and round-trip fidelity are being tightened as part of the beta work.

That wording is deliberately less exciting than “one-click interoperability”. It is also closer to the actual engineering problem.

A successful import is not a green toast message.

It is a plan that still makes sense after it leaves the tool that created it.