GDTF vs MVR — fixture definition vs scene exchange
GDTF describes the fixture. MVR carries the rig.
That sentence is deliberately simplified. It is also a much better starting point than treating both formats as mysterious files that happen to come out of your preferred Lighting- and Rig-Planning Tool.
If you have worked with modern lighting software for a while, you have probably seen GDTF and MVR mentioned in the same sentence.
That makes sense. They were designed to work together.
It also makes them very easy to confuse.
One describes the device. The other describes the project that uses it.
That difference is the whole point.
Start with one moving light
Take a moving-head fixture sitting on a truss.
To control and visualise that fixture, software needs to know quite a lot about the type of device:
which DMX modes exist
which channels control intensity, colour, pan, tilt and the rest
what the fixture looks like
which parts of its geometry move
physical and optical properties
identifiers and metadata
That information belongs to GDTF.
A GDTF file describes what that device is and how software can work with it.
But it does not answer another set of questions:
Is this particular fixture actually used in the show?
Where is it hanging?
Which universe and address is it patched to?
What is its rotation?
Which truss is it attached to?
What other fixtures, scenery and objects are in the project?
Those are scene questions.
That is where MVR comes in.
GDTF describes a type; MVR describes instances
This distinction is easier to see if you think in software terms.
A GDTF definition is roughly comparable to a type.
It says:
This is what a fixture of this model and mode looks like and how it behaves.
An MVR scene contains instances of devices and objects.
It says:
There are twelve of those fixtures in this project. Here are their positions, rotations, patches and the rest of the scene around them.
The analogy is not technically perfect, but it is useful.
You normally do not want twelve separate fixture definitions for twelve identical lamps. You want one reliable definition and twelve scene objects referring to it.
What GDTF carries
GDTF — General Device Type Format — is the open standard for describing devices used in the entertainment industry.
For lighting fixtures, that includes things such as:
DMX modes
channels and channel functions
geometry and moving parts
physical properties
optical data
wheels, gobos and related resources
manufacturer and model information
The currently published GDTF specification is GDTF 1.2, defined as DIN SPEC 15800:2022-02.
The goal is fairly straightforward: a console, visualiser and planning application should not each need an unrelated proprietary description of the same physical fixture.
If you want the longer version of why that matters, start with the article “What is GDTF — and why do fixture profiles need a standard?”
What MVR carries
MVR — My Virtual Rig — works one level higher.
It is an open scene-exchange format for entertainment-industry applications. The current published specification is MVR 1.6, defined as DIN SPEC 15801:2023-12.
An MVR file can describe a scene containing things such as:
fixtures
trusses
scenery and other geometry
positions and rotations
patch information
grouping and hierarchy
references to GDTF fixture definitions
In other words, MVR is not another fixture-profile format.
It is the thing that lets one application say:
Here is the project I am working on.
and another application have a reasonable chance of understanding it.
Why MVR needs GDTF
Imagine an MVR file says:
Fixture 42 is a Robe Whatever 9000, hanging at this position, patched to universe 4, address 101.
That gives the receiving application useful scene information.
But to simulate or control the device properly, it still needs to know what Robe Whatever 9000 actually means.
How many DMX channels does the selected mode have?
Which one is dimmer?
How does pan work?
What geometry should be displayed?
That is the device-definition problem again.
MVR therefore does not try to reinvent GDTF. It can carry or reference the GDTF data needed to describe fixture types used in the scene.
The two formats solve different layers of the same interoperability problem.
A practical example
Say a show starts in a planning application.
You draw:
four trusses
48 moving lights
24 LED fixtures
scenery
fixture positions
patch information
The fixture types themselves are described using GDTF.
Export the project as MVR and another compatible application can receive the scene instead of somebody rebuilding it by hand.
The receiving tool can then use the included or referenced GDTF definitions to understand the fixtures themselves.
That is the useful version of interoperability:
do not redraw the rig, and do not redefine the fixtures.
MVR does not mean every application will look identical
This is where standards meet software and reality gets involved.
Two applications can read the same MVR file and still produce different results.
One may support a piece of scene geometry the other ignores.
One may interpret a transform differently because the source file contains something unusual.
One may use more of the GDTF data than another.
One may encounter a .3ds mesh from an older toolchain and discover that the last twenty years of 3D file formats have not, in fact, been a coordinated team effort.
Supporting MVR therefore means more than successfully parsing GeneralSceneDescription.xml.
A useful importer needs to deal with what real applications actually write.
That distinction matters enough to deserve its own article later.
What each format does not do
A useful way to separate the two is to ask what they deliberately do not describe.
GDTF does not describe your show
A GDTF fixture definition does not know that you hung twelve copies on upstage truss, patched them to universe 3 and rotated four of them by 180 degrees.
That belongs to the scene.
MVR does not redefine how a fixture works
MVR should not need to invent another independent model of the fixture's DMX channels, geometry and behaviour.
That belongs to the device definition.
There is overlap in the information applications need to process, but the responsibilities are deliberately different.
GDTF and MVR in FlexViz
FlexViz uses the formats in the same separate roles.
GDTF provides fixture data: modes, channels, geometry and device behaviour.
MVR brings in the project around those fixtures: placement, patch, scene objects and the relationships needed to reconstruct the rig in another application.
That separation is useful internally as well.
If a fixture profile is wrong, that is a fixture-data problem.
If the fixture is in the wrong place after import, that is a scene/import problem.
Mixing those concerns would make interoperability harder rather than easier.
The short version
If you only remember two lines, make them these:
GDTF describes what a device is.
MVR describes where devices and other objects are in a project and moves that scene between applications.
Or, less formally:
GDTF describes the fixture. MVR carries the rig.
There are plenty of details underneath that sentence.
But unlike many standards explanations, you do not need to read the XML schema before the distinction becomes useful.