Instagram
YouTube
CAST Blog
MEMBERS ONLY AREA

This page was updated on: March 15, 2022

This page contains information about WYSIWYG’s MVR implementation and is meant to supplement the extensive information & instructions pertaining to MVR presented in WYSIWYG Help. We advise checking back frequently, as it will be updated often with new information that becomes available, and as changes are made, both to the MVR spec and to the implementation itself; information regarding data exchange with other applications that support MVR, as well as changes to these applications which impact the data exchange, are also noted. The numbers below are for reference only; the date that precedes each topic indicates when it was updated.

  1. [March 15, 2022] Reading the MVR spec documentation is highly recommended, in order to gain a better understanding of MVR’s principles and subtleties.
  2. [August 11, 2021] This flowchart provides an example of how an MVR file might progress during a show’s pre-production and how it can help various apps and the lighting console stay “in sync” by facilitating data exchange between them; in this example, WYSIWYG is the (blue-colour) “Lighting Design and Visualizer Application”.
  3. [August 11, 2021] If fixtures are not mapped during import/merge, they are automatically replaced with PLACEHOLDER fixtures. It is important to always map the fixtures – but it is understood that if the necessary fixture is not available in the WYSIWYG Library, it should be possible to complete the import/merge and retain fixture attributes, such as Patch and Unit number. In such cases, we suggest allowing the replacement with the PLACEHOLDER and immediately requesting the fixture profile (by signing in to the Members Only Area and clicking ‘Contact our Library Department’). Once the profile has been added to your Library (instructions will be provided by the Library Department), select the PLACEHOLDER fixtures and replace them by using the Replace Fixtures command [CTRL+H]. (Remember that when an incoming fixture is replaced with a PLACEHOLDER, a Note is added to it, containing the name of the original fixture and its options (mode, etc.); sorting the DATA Spreadsheets by the Notes column will make quick work of selecting the PLACEHOLDER fixtures that are to be Replaced.)
  4. [March 15, 2022] After exporting an .MVR file and importing it into grandMA 3, the imported fixtures must be associated with fixtures from grandMA 3’s grandMA3 or GDTF library, else it will not be possible for the console to control them. (This is done by right-clicking in the Fixture Type field in grandMA 3’s Patch window.)
  5. [August 11, 2021] In order for .MVR files exported from grandMA3 to import or merge, fixtures must have been inserted from grandMA 3’s grandMA 3 or GDTF library. While fixtures from the grandMA 2 library may be usable on the console, no GDTF profile is exported to MVR for these; this results in those fixtures referencing non-existent GDTF profiles and leads to an import error when attempting to import the MVR into WYSIWYG.
  6. [March 15, 2022] Unit Numbers and Position Names are imported by grandMA3 from .MVR files, but these are not exported (back) to .MVR. As a result, if a WYSIWYG-exported .MVR file is imported into grandMA3, modified there, the .show file is saved and exported to .MVR, then, finally, this file is Merged into the original .WYG file, Unit Numbers and Position Names will disappear. MA Lighting is aware of these issues and will fix them as soon as possible.
  7. [August 11, 2021] An update in VectorWorks 2021’s SP4 causes fixtures to which GDTF profiles have not been assigned (in the .VWX file) to export as “3-channel” fixtures instead of the previous “1-channel”. (These fixtures continue to appear with the mode “DMX Mode” in WYSIWYG’s Fixture Mapper.) While this update will not change how such fixtures are (or need to be) mapped, as a result of it, fixtures that have been mapped during a previous import/merge, may need to be mapped again, including when a new version of the MVR is merged into the current .WYG file.
  8. [March 15, 2022] As of Vectorworks 2022 Service Pack 3, when exporting to MVR, 3D models are output in the glTF format by default. This is the new standard for MVR, and WYSIWYG will be updated as soon as possible to allow such .MVR files to import. For the time being however, in order for .MVRs exported from Vectorworks to import correctly, the Use 3ds format option must be checked in the Vectorworks MVR export dialog; if it is not, while the .MVR file will import into WYSIWYG, no 3D models will actually import. This includes Hang Structures!
  9. [August 11, 2021] On occasion, when merging an MVR file, you may be asked to map a fixture that has been mapped in a previous merge. This will typically happen when a fixture’s mode has changed (via its GDTF association) and the new mode requires a different number of DMX channels. It can also happen when GDTFs are not used, if WYSIWYG detects that the incoming channel count of a fixture does not match the existing channel count; this can occur when a fixture is exported from WYSIWYG, the resulting .MVR file is imported into another application and replaced with that application’s own profile.
  10. [August 11, 2021] Since WYSIWYG is not (yet) able to make use of .GDTF files, all GDTFs stored within an MVR that’s imported or merged into a .WYG file will be discarded – and therefore not re-exported when the .WYG file is exported to MVR. Instead, an on-the-fly GDTF profile will be created for every fixture type in the file.
  11. [August 11, 2021] Since GDTF profiles are required by MVR but WYSIWYG cannot (yet) utilize GDTFs, when fixtures are exported, WYSIWYG builds a GDTF on-the-fly for every fixture type in the file. These GTDFs contain all the data required for fixtures to be mapped in the software into which the resulting MVR is imported. However, fixtures’ visualization data (e., Pan & Tilt ranges, speed, zoom capabilities, and so on) is not exported, and all fixtures’ bodies are represented by two boxes (one for the base and one for the yoke). Therefore, if the importing application does not offer a fixture mapper, all fixtures will (most likely) appear identical – and may need to be replaced by some other means, such as replacing them by using a Replace Fixtures command similar to WYSIWYG’s or by associating them with GDTF profiles. (If the importing application does offer a mapper, that application’s own profile should take over and the fixtures should appear as defined by that profile.)
  12. [March 15, 2022] When updating objects in a .WYG file by merging an .MVR file, changes may be ignored if the object’s type has changed. For example, changes to Pipe and Truss objects are rejected. This is because these objects in the .WYG file carry additional, useful information that would be lost if WYSIWYG had to replace the existing Pipe or Truss with an imported <Truss> or <SceneObject> from MVR, as each of these MVR types is converted to a Consolidated Mesh or Library Item (or Group of Consolidated Meshes). This decision was made so that the unique abilities, such as hanging fixtures on hang structures or calculating weights for Reports, would be preserved. Similarly, LED Walls and Screens are not updated during merge because of the special data associated with such objects in a .WYG file. However, this only happens when another application changes the objects’ base type; Capture, for example, changes WYSIWYG-exported truss meshes at a fundamental level, and therefore updates are ignored.
  13. [October 22, 2021] This deficiency was addressed in Release 47 Update 1: as long as hang structures were not altered at a fundamental level by the “in-between  application”, once the merge is complete, these will appear at their new location and with their new orientation. When a new version of an .MVR file is merged into a .WYG file which started from (or was) a previous iteration of that MVR, the locations and orientations of objects that represent hang structures will not be updated (assuming they were changed). Furthermore, as per the previous point, objects that represent hang structures for existing fixtures, which would normally result from an Update Existing Only-type merge operation, will not appear once the Merge is complete. Despite this, Fixtures themselves will always update to the correct location, Position and Focus Position – not to mention that their attributes will always update as per the incoming MVR); as such, correct and most up-to-date fixture information is retained, and pre-visualization and/or pre-programming can continue once a merge is complete (despite some fixtures appearing to hang in mid-air); if desired, the existing hang structures’ may be updated by moving them to their new locations manually.
  14. [August 11, 2021] After a Screen or LED Wall that was exported from WYSIWYG is imported into VectorWorks and, from there, exported “back” to MVR, if the resulting .MVR file is merged into the original .WYG file (or imported as a new .WYG file) the resulting Consolidated Mesh objects which replaces that Screen will be 100% Transparent; the same will happen for LED Walls. For the time being, the only solution here is to select the resulting object, access its Properties > Appearance tab, and, after selecting the Element labelled Material_0, click the Reset button in the Material section of the Properties window, to set all Material properties to 0%. This issue has no other “side effects”: if the object was relocated or had its orientation or image changed, the new data will take precedence as usual. Note: Screen objects which were created in VectorWorks are not affected by this issue.
  15. [August 11, 2021] In WYSIWYG, Groups are considered objects and must therefore belong to a layer. Some applications which support MVR operate like this as well. In other applications, Groups do not belong to any layer, and such applications may export Groups to nameless layers; since Groups must have a name in WYSIWYG, the name !GROUPS (MVR) is added to such layers during import/merge.
  16. [August 11, 2021] Objects’ colours or textures (whether from the Library or an Image Source) will export to MVR, but Material properties will not.
  17. [October 22, 2021] This deficiency was addressed in R47 Update 1. If the layer to which Motion Objects belong is hidden, the objects attached to those Motion Objects will not export; therefore, you must ensure that all Motion Objects’ layers are visible during MVR export.  Furthermore, a warning regarding Groups may erroneously appear when exporting in such cases; this warning may be safely ignored.
  18. [August 11, 2021] Since Video Sources cannot be used with MVR at this time, it is recommended that a Placeholder Image is assigned to all Video Sources. When this is done, the Placeholder Image will export to MVR instead of a random frame from the video (which could be completely meaningless); Placeholder Images can be crafted to be useful, for example to indicate which video feed is assigned to the Screen, LED Wall or other object with which the Video Source is associated.
  19. [August 11, 2021] Since the 10-cm pipes that are created during an MVR import or merge are only required by WYSIWYG, these will not export to .MVR files.
  20. [August 11, 2021] Focus Positions and Focus Points that result from Focus Lines and Focus Arcs will always export to MVR regardless of their layers’ visibility state, when the fixtures assigned to them are exported.
  21. [August 11, 2021] Rounded objects cannot export with smoothing at this time.
Menu