Rasterized PNG images are used in GDTF in several places - as a device thumbnail or as a MediaFileName in slots for gobo wheels and animation wheels. While the definition of a device thumbnail is quite simple (a png file to provide the rasterized picture with maximum resolution of picture 1024 x 1024), definition for a gobo slot image is more involved: Gobo images shall be in PNG format with an alpha channel. Indexed, Greyscale and Alpha, 8-bit RGB and Alpha, or 16-bit RGB and Alpha are accepted pixel formats. The Background shall be fully transparent and should be considered to be the equivalent of a gobo holder. The Image region shall be fully opaque aside from anti-aliasing and shall be as large as possible. The Background region, the equivalent of gobo holder, is defined by full transparency (Alpha 0). In the Image region, Pure Black (RGB 0,0,0) is opaque (2), and Pure White (RGB 255,255,255) is transparent (GDTF). Colored gobos (3) shall use an RGB approximation. The RGB approximation shall be calculated on the basis of Pure White being the CCT of the fixture light source and the ICC color profile embedded within the PNG. The default shall be sRGB. - Maximum resolution of picture: 1 024x1 024; - Recommended resolution of gobo: 256x256; - Recommended resolution of animation wheel: 256x256 So for thumbnail images, one can use pretty much any png image with the given dimensions. Ideally, the image should be a square, so the result in any UI is more predictable. This is the default image provided by the builder: What we like to do, however, is to ensure that the image is actually trimmed on a transparent background, so it can better fit into any UI (checker board indicating the transparency): With the transparency: For wheel slot images, you have ensure that the non-transparent (opaque) and transparent (white, colored) portions are correctly defined and also that transitions between them is also correct. Here is a 256x256 example. We actually provide gobo images in maximum possible resolution (1024x1024), for the best outcome in visualizers. It is simple to sample down if needed. The only exception we currently do are devices with tenths of gobos, like the MiniMe and ProMotion, where we scale the images to achieve close to 10MB size of the complete GDTF file. As i mentioned, critical parts are the transitions. On the edge between alpha and color, you should have no extra color (due to antialiasing), just the alpha (transparency): On the edge between white and black, you need to have only colors and no transparency: Same rules apply for the animation wheel: Hope this helps Petr

3D models are one of the essential assets in GDTF. Lets see what we need to do to make our 3D files ready for GDTF. You can either use generic 3D models already predefined by GDTF and available in the GDTF builder, or you can provide your models. Models can currently be provided in the form of 3DS files, or in the future it will be also possible to use glTF files. How to create models of the devices is out of scope of this post, what we will look at today is how to modify and adjust existing 3D models provided by the manufacturer for use in GDTF - apply position, rotation, alignment and adjust the quality of the meshes. I like to use Meshlab for assets preparation for GDTF, but you may choose to use other tools, like Blender, Cinema4D or some other software. We will look at a generic moving head fixture with base, yoke and a head. What you usually get from the manufacturer's documentation is a complete 3D drawing, made of individual parts, assembled into the shape of a real fixture. What we need to do for GDTF is to separate each moving part into an individual model and adjust it's origin point and alignment. Here is GDTF definition: The mesh of each fixture part shall be drawn around its own suspension point. The zero point of a device does not necessarily have to contain the offset related to the yoke, but it must be centered on its axis of rotation. The offset is defined by the geometry and has to be related to its parent geometry and not to the base. Which means that in each model's file it's origin point is defining the rotation point. Here is an example of a complete fixture before adjustment, we can see the individual models listed on the side (marked with 1): As you can also see, the origin point (2) is at the center of the base plate, but this is only correct for the base, not for yoke and head, so it will need to be adjusted. Here is another part of the GDTF definition: The device shall be drawn in a hanging position displaying the front view. That results in the pan axis is Z aligned, and the tilt axis is X aligned. 0,0,0 – center base plate. So the device must be drawn upside down, the head must point to negative values of the Z axis and not to the positive direction (3), which means that all models will need to be rotated and adjusted. Your model will most probably be rotated differently, so take this post as a reference. Meshlab allow us to individually select each model and perform operations on it, like Rotations and Positioning (translate) by defining numbers (degrees or digits) of movement. At the same time, it provides a "freeze matrix" feature, which sets the current transformation matrix into the coordinates of the vertices of the mesh (and set this matrix to the identity). In other words, it sets the origin point to the place you need it to be at :), which is what is needed for correct application in GDTF. Here are the Transform tools in the menu. What i like to use instead of multiple rotations is a tool called "Flip and swap axis". One important note: you must always first perform a translation (positioning, to define the origin point - point of the rotation) and the only a rotation, otherwise the rotation would happen along a wrong axis/point. So in my case (your model might be different) we adjust the base by axis flipping and swapping as follows: We can now see that the base bottom plate is facing positive direction of the Z axis, good. Now we need to apply rotation to the yoke and head, because what we have so far looks like this (example of head): The model needs to be positioned (1) and also rotated, so the X axis is defining our rotation (2). You will need precisely measured positions for these offsets, often these will come from manufacturer's drawings or other documentation. Here is the result after applying the Translation and then Rotation in Meshlab: And this is adjusted model of yoke: After we adjust all (base, yoke, head) and If you open all three models together, they will be overlapping each other: This is because the offsets of these models will be defined later, in the GDTF file. For the offsets in GDTF, we will again, need precisely measured values from the device's documentation. Our files are almost ready, but we still must ensure that the models have certain complexity, as for example defining them too detailed (most common case) results in high demand for processing power of the visualizers. You can prepare a detailed, high vertex count file if you perhaps have a demand for a particularly detailed rendering, but for normal operation, you should conform to the GDTF definition: All models of a device combined should not exceed a maximum vertices count of 1200. To ensure this requirement, we must often simplify the model. Meshlab offers it's "Simplification" tool: Before simplification: Simplified, by adjusting the "Target number of faces". See number of vertices at the bottom: Now we can add the models into GDTF in the Builder, here is the result, with corresponding offsets. Here is the base: Yoke: And head: Hope this helps Petr