Documentation Resources for GDTF Introduction Start by registering a free account on the GDTF Share, this allows you to use the GDTF Fixture builder and also to join this GDTF Forum and ask questions. GDTF Builder GDTF files are created in the free to use GDTF Fixture builder - a web based editor to create and modify GDTF files. There are several documentation resources for the GDTF Builder: How to Create a GDTF Lighting Fixture YouTube video series from 2024. Introduction to the GDTF Builder YouTube video series. GDTF Builder manual describes creation of a GDTF file from start to the end. How to articles, describing dedicated topics in more detail, for example Wheels, Virtual channels or Prisms. Robe Knowledge Sharing (RKS) articles on the GDTF forum, describe particular domain knowledge to depth, for example basics on 3D positioning, orientation and rotations or 3D geometry preparations. GDTF Share The GDTF Share is a platform for the exchange of GDTF files. It provides a central repository, connected with a GDTF file editor, for upload, search and download of GDTF files, with powerful filtering and management system for users and GDTF files creators. GDTF Share manual - explains how to create a free account, how to navigate the GDTF Share and how to upload, manage and download GDTF files. How to Create an Account for the GDTF Builder and GDTF Share Tutorial YouTube video series. Other resources for the GDTF Specification The GDTF Specification is the text of the DIN SPEC 15800:2022-02 also known as GDTF Version 1.2. GDTF Spec documentation on this server. GDTF & MVR Specification working repository on GitHub GDTF Forum - ask questions about GDTF & MVR here FAQ - answers for questions frequently asked by manufacturers and entertainment professionals

One of the often raised questions about GDTF is "which data is required to be included inside GDTF files". This can be dependent on the use-case for the file and it is always subjective, but here we try to summarize the issue to provide a hierarchical approach to understanding user needs. GDTF Data expectation per use-case: Use case → Control Planning Previz Rendering Feature ↓ Fixture name essential essential essential essential Manufacturer essential essential essential essential RDM complementary Description complementary essential essential essential Product image complementary essential essential essential 2D thumbnail complementary essential complementary complementary Operating temperatures complementary Weight essential Leg height essential complementary complementary 3D model template essential essential essential essential 3D model real fixture complementary complementary complementary essential 3D model PBR workflow peripheral Beam model basic shape essential essential Beam model real world complementary complementary 2D model symbols complementary Gobo images essential complementary complementary essential Prism slots complementary complementary essential Color slots essential complementary essential Animation wheels complementary complementary essential Virtual channels (dimmers, tilt…) essential Channel dependencies complementary DMX (control) description essential essential essential DMX Macros complementary Beam data complementary complementary essential Colors (emitters, filters) complementary complementary essential Movement speeds complementary complementary essential Movement acceleration complementary complementary essential Movement ranges essential complementary complementary Movement directions essential complementary complementary DMX profiles (curves) complementary complementary complementary Subphysical properties peripheral Wiring object data (Power usage...) complementary GDTF Data expectation combined: Essential Nice to have Like to have Basic metadata Fixture name Manufacturer RDM Description Product image 2D thumbnail Operating temperatures Weight Symbols Leg height 3D model template 3D model real fixture 3D model PBR workflow Beam model basic shape Beam model real world 2D model symbols Media Gobo images Prism slots Color slots Animation wheels Control Virtual channels (dimmers, tilt…) Channel dependencies DMX (control) description DMX Macros Physical measurements Beam data Colors (emitters, filters) Movement speeds Movement acceleration Movement ranges Movement directions DMX profiles (curves) Subphysical properties Wiring object data (Power usage...)

Hi @Andriy K, thank you, sounds good. We have done a lot of work in the past to accommodate this. The GDTF spec got support for multiple geometry trees, we sped-up the multi-geometry tree rendering in the GDTF Builder, and i believe software using GDTF also improved over time. For us, things are a bit more complex but for you this should make your experience much better.

If you have the opportunity, please visit the GDTF booth at the Plasa 2024 show, at stand A69.

Hello Andriy, yes, we deal with the same issue. If i can advice you, duplicate the geometry tree and make the modes to use Break 1. We have quite a few devices where using multiple geometry trees is complicating things for us for several other reasons, so we stick to a single tree but have to deal with these DMX Break implementation issues. On gMA, you can patch but you must re-calculate yourself, because the software pushes the other breaks to another universe. You can also raise an issue with WV and MA. Cheers Petr

I have looked at the file in the builder. This is a good start, but you do need to tweak it to make visualization working: - Ideally, you should build the fixture up side down, as the GDTF specification says. This will in default view allow you to see the beams pointing down from the device. The up side down rotation of the models should ideally be done in an external 3D software. - the model of axis has it's origin point (the center or the pivot) outside of the model, this is why the rotation is not following the real fixture behavior. To fix this, in the 3D software where you created this model, you need to set the origin point to the correct place. - the beam geometries are inserted too deep into the geometry of the "axis", thus they cannot shine their beams out. Hope this helps

A random strobe has a random behavior. Having said that, it might be possible to link a global strobe attribute to a geometry parenting the sub-beams, then the trickle-down principle would make them to strobe together, in random way but together, if the used visualizer supports that.

Hello, this is not an oversight but it was a deliberate change from original version of GDTF. Each ChannelFunction has it's own default value as the LogicalChannel's default value is in many cases not valid for all ChannelFunctions. Also, when switching between ChannelFunctions, it was important to be able to tell to the system what value to load upon the change of the function. Kind regards Petr

Hello @CharlieWinter, repackaging and re-zipping GDTF and MVR is possible. It could be that gMA3 is not yet supporting compression of the zip archives and that they are expecting a zip but without compression, which is something you can typically set during the zipping process. Hope this helps Petr

Hello, you can make the beam large (like a tube) and set the Beam geometry's Beam Type to None or to Glow: See here: https://gdtf-share.com/share.php?page=home&manu=User+Test&fix=RGB+Tube I didn't test in gMA3 but i presume that it would work, Hope this helps, cheers Petr

If the effect uses 2 channels (16bit) and you want to enter the data in 8bit fashion (0-255 values), you somehow have to define the value for the second channel. In the input field, the first value (from the left) is what you most likely have in your DMX table, the second value (after the slash "/"), is most typically will be 0 for you, except for 255, which will be 255/255 (to have full maximum value). Hope this helps. Maybe discuss this with your R&D people, to have more clarity if needed... they will be able to help you too. cheers Petr

Hello @CarlosDVS, switching the input field between 8/16/24/32/% is just a view on how you enter the data. So by switching it to 8, you can enter your data in the 8bit, as per your DMX table... see for example here: When switching between these values, you can see what you values look like in different resolutions or a percentage:

Here is a list of frequent errors we can see some new GDTF authors are making, together with description on how to eliminate these issues. By following this advice you will be creating GDTF files of much better quality. Custom GDTF Attributes Do not define custom attributes. If you think that the attribute you are needing is not in the GDTF Builder, look more closely. In 99%, the needed attribute is already defined in GDTF and thus it allows all software utilizing GDTF to know which real world behavior is described by that GDTF attribute. If unsure about creating a new attribute, ask in the forum, especially if you want to be sure that your GDTF file is correct. Here are some commonly missed GDTF attributes: Dimmer, which is controlling intensity of the device. Do not create an attribute "Intensity". Colors. Do not create "Red" of "Green". These already exist as for example ColorAdd_R, ColorAdd_G, ColorAdd_B for direct color mixing, ColorRGB_Red, ColorRGB_Green, ColorRGB_Blue for indirect color mixing, ColorSub_C, ColorSub_M, ColorSub_Y for Cyan, Magenta, Yellow subtractive color mixing. You can view the list of all GDTF attributes with extended description for each item here. Coarse and Fine Channels When defining a DMX Channel, you can choose a Resolution of the channel. This then allows you to assign a DMX offset for Coarse and Fine, as per image below. Do not create channels "Dimmer Fine" or "Red Fine" channels. Emitters/Filters Only define a color Emitter or a Filter if you have measurements of the colors. Do not define Emitters/Filters to just click some random R, G, B values. 3D Models Ideally, use a real 3D model of the device. If you do not have a 3D model of the fixture, you can use the default head, yoke, base models provided by the GDTF Builder, if these default models look like the real device you are describing. If the default head, yoke, base models do not describe your device correctly, it is often better to use the predefined cube or cylinder as a model. Do not use for example the default base instead of a generic cube, it will look very ugly. Beam Geometry For beam geometry, typically use a cylinder with a small height. Do not use randomly some other predefined models like the head or base. Hope this helps. If unsure, just ask here in the forum. Petr

GDTF Builder has been updated with the following changes: Ensure that when saving a GDTF file, the spinning animation is closed down after file upload procedure Improved GDTF Share performance when saving GDTF files Do not mark DMX Breaks with offsets larger then 512 as errors Ensure correct reading/writing of GDTF files after copy/paste of geometry references

Hello @Brothers, we are hoping for a fix for this to be released this week. It is pretty difficult to reproduce so we hope we are eliminating the issue. cheers Petr