A Look into GDTF Files Provided by GDTF Service

GDTF Service started offering GDTF files for device manufacturers who are not ready or not planing to create GDTF files for their devices by themselves. For many, especially small manufacturers, this is a very interesting offering and a way to get into the GDTF space. This service can cover the needs of lighting designers and planners who are now requiring GDTF files for all new products as GDTF is quickly becoming an industry used standard.

Executive Summary

The currently provided GDTF files are functional, with basic amount of data, and mostly technically correct and will serve the customers’ needs very well. More testing would be useful either by GDTF Service or by the manufacturers who are purchasing these files, especially now in the early days of the service.

Deeper look at the data provided inside these GDTF files

Metadata section

The metadata part of GDTF like product name, RDM identifiers, operating temperatures, description and more… looks correct inside of the checked files and the only missing piece of information seems to be a “Leg height” value. While this is a minor piece of information, it goes deep into 3D models definition, as per the section Geometry, below.

Raster image thumbnail is provided and it is in 300x300 pixels - square dimensions. We applaud GDTF service for the decision of using square images (throughout the GDTF file) as it makes it much easier when used in user interfaces or on websites. It could be nicer if the background was transparent but that is a minor detail.

The 2D thumbnail is provided and looks well defined. What will need adjustments are dimensions of the 2D symbols as these should correspond with the dimensions of the 3D models (at this time, the 2D dimensions seem arbitrary). Same is valid for the inclusion of the Thumbnail Offsets X and Y, which are missing.

GDTF files revision section is there to allow file authors to summarize what parts of the GDTF file have been adjusted. At this point GDTF Service is using a generic “Update upload” wording which is not very useful.

Geometry section

Most checked GDTF files did contain 3D models specific to the described device, which is great. Where the challenge seems to be is in obtaining low polygon meshes. Most checked models seems to be in a very high detail, containing too many vertices which can cause rendering issues for most software. 3D decimation can help, but often low-poly models must be specifically created for each device.

As mentioned in the above section, the missing Leg height is indicating an incorrect alignment of 3D model for the geometry of the base. GDTF specifies how the base should be defined inside GDTF: 0,0,0 – center base plate. This is to be able to use these models for detailed measurement where a clamp or a clamp adapter attaches onto a device’s base. For this, the origin point of the 3D model must be aligned with the outside of the bottom of the bottom base plate. The observed models typically have their origin point (0,0,0) aligned with the bounding box of the model, thus causing a small difference of (precisely) the height of the legs of the device. In some checked devices just plain 3D boxes were used instead of real 3D models and the origin point was defined in the center of the box. This is not good and the GDTF provided PrimitiveTypes for base, yoke and head should be used instead. That would provide more correct measurement information and better user experience.

As far as the rest of the Geometry section, it seems mostly correct, including information provided for example in the Beam geometries.

Wheels

Gobo and Color wheels and wheel slots are correctly described, allowing good user experience for UI in console slot selection and for visualizing. Gobo images do follow the GDTF Specification, which defines the very specifics of transparent and opaque portion and we applaud GDTF Service for this. The resolution of provided gobo images is 300x300 pixels.

Prism definitions seems to currently be missing in GDTF Service provided files.

Physical measurements

Movement

Movement (pan, tilt, zoom) ranges (in degrees) seem to be provided, as these are the easiest to acquire. More details about the speed of movement or acceleration is missing. These detailed data would typically be either coming from the device manufacturers themselves or the device would need to be provided for measurement. Rotation speeds, shutter speeds, insertion depth of framing shutters and others are not included.

Emitters, Filters, DMX Profiles

At this point there seems to be no information about Emitters (describing light sources) or about Filters (color mixing flags, gels and filters in wheels).

No information about curves of movement or dimming (DMX Profiles) is included, but at this point there doesn’t seem to be any software that would utilize this data.

Controlling - DMX data

DMX Modes, channels and channel sets seem to be created with good understanding of both the GDTF Specification and also of the environment in which these files will be used at.

Correct GDTF attributes (listing of attributes with extended description and the GDTF Spec provided attribute definition) are used to describe the functions of the devices. This includes attribute selection for device functions like Strobing, Shutter or Colors, requiring good acquaintance with the GDTF Specification and GDTF Service is demonstrating fairly good grasp of the concept.

Channel sets are basic, mostly as provided by the Auto-fill functions of the GDTF Builder, and offer sufficient information for controlling and visualization.

GDTF Builder itself could provide more defaults for channel sets of wider range of channel functions (for example Zoom, Focus, Shutters and so on), GDTF files creators would have easier job and files would be more standardized.

Gobo and color wheel channel set definitions do link channel sets to the respective wheel slots, while at this time omitting details about physical indexing of wheel slots. Some wheel related channel functions seem to be linked to wrong wheels.

DMX Macro section is completely empty and providing at least Lamp ON/OFF commands would be useful.

Our verdict

Files provided by GDTF Service offer a good start in the GDTF journey for lighting manufacturers who do not want to create the files by themselves.

Some small amount of incorrect data was found but not to be a show breaker. Most likely the GDTF Service is checking and testing their data, yet either GDTF Service or the lighting manufacturer should do some (more) testing of these files in real consoles like Chamsys or gMA3 to discover and eliminate the occasional issues as found here. This is important especially when the service is looking to be providing more GDTF files on commercial bases. Over time these small issues will hopefully not be present anymore.

Files used for this review

Six files were analyzed during this testing. Tree of those files are listed and archived below. For show purposes make sure not to download GDTF files from here but always check the GDTF Share for latest versions.

• MegaLite Framebot 600 in GDTF Bench MegaLite Framebot 600 (GDTF Bench ) archived here

• Strand Acclaim LED Fresnel in GDTF Bench Strand Acclaim LED Fresnel (GDTF Bench ) archived here

• Vari-Lite VL2600 Wash in GDTF Bench Vari-Lite VL2600 Wash (GDTF Bench ) archived here

Updated versions of the files

Since publishing of this article GDTF Service has updated (only) one of the three files archived above. Here are links to latest versions of the three files in the GDTF Share, should they be updated in the future:

• MegaLite Framebot 600 in GDTF Bench MegaLite Framebot 600 (GDTF Bench ) 

• Strand Acclaim LED Fresnel in GDTF Bench Strand Acclaim LED Fresnel (GDTF Bench ) 

• Vari-Lite VL2600 Wash in GDTF Bench Vari-Lite VL2600 Wash (GDTF Bench )