Jump to content

GDTF Forum

Petr Vanek

Moderators
  • Posts

    296
  • Joined

  • Last visited

  • Days Won

    22

Everything posted by Petr Vanek

  1. 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
  2. 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
  3. Before you define any physical attributes, you have to make sure to understand how positioning, rotation and orientation is defined in GDTF. 3D space definition GDTF defines this this way: The metric system consists of the Right-handed Cartesian Coordinates XYZ: X – from left (-X) to right (+X), Y – from the outside of the monitor (-Y) to the inside of the monitor (+Y), Z – from bottom (-Z) to top (+Z). For a device, everything starts for you with your 3D model. Here is 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 this means: the device is upside down the origin point (0,0,0) is in the center of the base plate (meaning, not in the center of the base model, not at the "end" of legs) you draw the device with it's front in the direction of the -Y axis (facing you in the builder) by placing the "pigtail" model, you indicate the location of the panel with connectors or the power cord the positioning and orientation is how it must be done in the 3D model, especially for the base, because the top geometry (often the base) cannot contain any extra defined position (offsets) and/or rotations If you for example decide that the "front of your device" is where the connector panel is, this would be the result: Rotation Here is GDTF definition: The metric system consists of the Right-handed Cartesian Coordinates XYZ. Let me re-phrase this as this is basically the right handed rule: The right thumb points along the Z axis in the positive direction. Positive rotation is shown by fingers curled in the direction of rotation. When viewed from the top or Z axis the system is counter-clockwise. The top here is you, naturally looking at your hand: The counter-clockwise sounds strange, but because in real life you often "observe" it from the bottom, you consider this "normal" for screw threads and so on, because to screw them in, you turn them to the right. This is how it looks applied to the model/geometry, indicating pan/tilt: So when viewed from the top: Positive values are increasing values, so angles from 0° to 360°, from -360° to 0° of from -360° to 360° are positive, angles from 0° to -360°, from 360° to 0° or from 360° to -360° are negative. When defining angular ranges, you typically start from center (0°) and define - and + ranges. Based on this, you can determine how to correctly fill values for pan/tilt angular ranges, gobo rotations and so on. In the builder You can also use the Builder to show you the positioning (translate) and rotation (rotate), you can choose a mode to manipulate the model: Centered: Model: Displayed values: Moved "to the front", to negative values on Y axis: Model: Displayed values: Rotated "in positive (CCW)" direction: Model: Displayed values: Hope this helps Petr
  4. One of the advantages and ideas of GDTF is a central repository - GDTF Share, connected with a GDTF file editor - the GDTF Builder. Using the Share is pretty straight forward - you can upload, search and download files... but in reality there is much more going on behind the scenes. The Share contains powerful filtering and management system to ensure that this repository is kept nice and tidy, while at the same time any random person still can upload a GDTF creation of their own for others to use. Lets look at that... Searching and filtering Users can search the Share easily: Each file "belongs" to a "folder" of the vendor/manufacturer of the device and then a "subfolder" named by this "device name", with relevant filters: 1) filter for a manufacturer 2) filter for a device name File can be released to the public or can be in a Work in progress (WIP) release state. The WIP status is assigned to files by default and allows authors to keep working on their files and continuously saving their progress... plus their filters: Files are divided into being created by "users" and "manufacturers", the Share then contains respective filters: There are also various tags like "tested in 3D", tested in real world... and their respective filters: File upload To ensure that files are well organized, the upload process contains several steps to assign manufacturer and device. The Upload icon is up at the top: You can choose a file: And Proceed: Manufacturer is automatically detected, but you can also choose if if required: Same for the device name: At the end of these dialogs, you can review everything and can name the revision plus set the status (Released or Work in progress): Manufacturer moderation Manufacturers have special power that allows them to manage "their" folder to keep it organized. To use their "moderator" tools, there is a "Moderator" in the "Show" filter: This allows manufacturers to rename the name of their folder. This is why Robe folder is called "Robe Lighting" while the name of our company is "Robe lighting s.r.o.": Moderating operations can be done on device "subfolders" or on individual files - folders can be merged and renamed: Individual files can be also moved around or have their Revisions renamed: Manufacturer's pages Each manufacturer also has a dedicated page with a representative listing of the files for their devices, here is what it looks like: Hope this helps Petr
  5. First steps of getting into GDTF... let's get right into it. Accounts Create and account in https://gdtf-share.com/ so you can access the Share, Builder and the Forum. Sign into the forum at least once, so your account is activated here. If you are an industry related vendor (for example a manufacturer) drop an email to info@gdtf-share.com , together with brief introduction about who you represent and your Share username. This will provide you with the possibility to enable manufacturer account in the Share and invite to the monthly GDTF manufacturer's interfacing meeting and discussion. If you are after the formal GDTF Specification, get the DIN SPEC 15800:2020-07 . As this is an official DIN document, distribution is possible only through the DIN publishing body, Beuth in this case. https://www.beuth.de/en/technical-rule/din-spec-15800/324748671 GDTF Authoring To create the GDTF files, best way is to use the Builder. There is a quick manual here, so make sure to check it out. But there is nothing like just doing it, over an over again. As with any tool, it is very simple to make a simple basic file, but it takes time to learn the tiny details. Get some inspiration from existing files, the Share offers a lot, we at Robe have also been creating files for all new (and even older) fixtures, so this can serve as a lot of inspiration. Here are few examples to get you started: Very simple tungsten device even without dimmer (but the file provides a single channel control for visualizing purposes), Patt 2013. A typical discharge spot , a moving head fixture, the BMFL, with gobos, prisms, iris... using Mode Dependencies and other features required for a moving head device. A multipixel but single RGBW controlled small LED beam, the LEDBeam 150. For a linear LED unit, check out the VC-Strip 25 8x1. Going up with complexity, a multiring LED wash fixture, the LEDWash 800. For a fixture with many DMX modes and Mode Dependencies, look at the Orbiter. If you need an example of quite complex pixel controlled LED fixture, Tarrantula can be an example. This is also showcasing custom 3D model for the beam pixel lens. Start with visualizing right away Several manufacturers are working on their GDTF implementation. Check out what they are offering and maybe ask for support if not announced yet. You can also use GDTF files right away with either MA3 or VW Vision and although there is always room to implement more niche details, most features needed for the real day to day operation already work very well. Start with a basic device and see what it looks in the visualizer. This allows you to work without a physical fixture and you can explore and test even complex depths of GDTF possibilities. DMX controlling versus general device description For basic DMX controlling, very simple GDTF file is all that is needed, so i would suggest to start with that, but GDTF offers much more, from the 3D models through connectors to real world physical parameters. For that, you will need real measurements of real devices, but again, you can try any values for the start, to get a feel how to enter them into the builder and what the visualizing looks like. Consuming GDTF data If you are more into utilizing and using the GDTF data, definitively check out the DIN Spec as per above. Also, look at the GDTF XSD file and PR for a Schematron validation file (kindly provided by @Janng ). There is also the libMVRgdtf parsing library (ask for access through the info@gdtf-share.com email as per above), or if you like to use GDTF fixtures in a 3D game engine, you might also like to check out the Unreal Engine GDTF implementation, described for example here. As the GDTF format is completely open and there are already some well performing devices files in the Share, is it simple to start with implementation and do some experiments of what the GDTF can provide you with. Hope this helps Petr
  6. >The specs really must permit files to be compressed with deflate. Thank you, we are open to suggestions and proposals. Btw, completely off topic in this thread ?
  7. You can add virtual pan/tilt to the geometry, which then allows the operator to preset these in places like MA3. For remotely connected visualizer (Vision...), virtual channels would not be transmitted, there you would have to do the adjustment by the tools of the visualizer (if available).
  8. The gdtf-share as a landing page has link to all the major destinations (builder, forum, share, help), the share itself links to builder/forum. We will consider it, thank you.
  9. This is new issue, we have seen this on Friday afternoon. Mark the file WIP @NRG Sille please, before this issue is ironed out. Cheers Petr
  10. We will be pushing some improvements out soon. This is partially related to the recent transition to GDTF 1.1 in the builder (Builder v1.4) and to the move to VPLT as a third party independent entity providing oversight over the hosting, in order to maintain an independence from the founding members. We use the builder every day and while we have seen some issues (and we keep reporting them), we were able to maintain our work normally.
  11. GDTF 1.1 specifies default values for each ChannelFunction, because ChannelFunction could have a value range, which is outside of a default value defined on a Channel. The Channel also has a "default channel function" which is giving default channel behavior.
  12. Hello @Snabbelicious, do you use any adblocking software? Or have many tabs open? The builder keeps data stored locally in your browser session. If you "just reload" the page, normally the last fixture is stored under the "Restore last session" icon. Or is there a particular sequence that you know would trigger this? Thank you Petr
  13. Hehe, add Inkscape onto your list Rex ? I do not mean which software can open/create SVGs, but if there is any software that utilizes the SVG 2D symbol from GDTF (thumbnail.svg), this is typically used in planning tools.
  14. Hi all, is there currently any software that utilizes the thumbnail.svg ? thank you P. @moritzs @dmueller @klinzey
  15. Hi @GreenManProductions, maybe you defined the beam as None? You can choose a beam type in the Builder → Geometry → geometry chain → Beam: The BeamType describes how the Beam will be rendered. — “Wash” – A conical beam with soft edges. — “Spot” – A conical beam with hard edges. — “Rectangle” – A pyramid-shaped beam with hard edges. — “None” – No beam will be drawn, only the geometry itself will emit light. Hope this helps, Petr
  16. Hi @Wouter Verlinden, essentially, Channel Function is "the" definition of physical behavior, as defined by the Attribute. So it is correct to create different ChannelFunctions for different behaviors. Now, as for macros, because macro can mean several different things which might not be implemented by visualizers, it is then up to you to decide if you actually like to split them into various ChannelFunctions, which can be nice for the user to be able to select them individually (only color macros, only intensity macros...), or to have only a single tab with "all macros" defined as channel sets. The reason to see the new errors is the transition to GDTF 1.1 DIN SPEC 15800, where each Channel Function now have it's own Default value. Previously, in GDTF 1.0, this Default value was for the whole Logical Channel, which could mean that a value (for example 0) was actually not available within a particular Channel Function (for example defined from DMX 20 through 40). Hope this helps Petr
  17. Hi @Monkeypuzzle, full GDTF spec is here: https://www.beuth.de/en/technical-rule/din-spec-15800/324748671 Your region #2 would be colored in magenta. But your gobo will still be round, meaning the "roundness" or "gobo holder" is defined by alpha (region #1). Size of the gobo itself doesn't matter (maximum size is 1024x1024), smaller picture will be more pixelized, but yes, the ratio of gobo (that is the region #2) vs the holder (#1) is important (for example for beam reducers). Hope this helps cheers Petr
  18. Hello @hantoo, these are largely implementation details in visualizers, as for your definition, you can choose a beam type in the Builder → Geometry → geometry chain → Beam: The BeamType describes how the Beam will be rendered. — “Wash” – A conical beam with soft edges. — “Spot” – A conical beam with hard edges. — “Rectangle” – A pyramid-shaped beam with hard edges. — “None” – No beam will be drawn, only the geometry itself will emit light. So for soft edge you can choose the "wash", for asymmetrical you can choose "rectangle". You could also build an array of "pixels", defined as "wash", especially if these can be controlled individually, this will create the asymmetrical, soft type of output. Hope this helps Petr
  19. @saajjj and @DanyAtCAST, sorry for a later reply and Happy new year! ? Yes, this is intentional. There has been an ongoing effort to clean up the share and to provide much better moderation tools to GDTF authors and device manufacturers, giving them better tools and workflow. This includes a concept of WIP (work in progress), which allows them to hide unfinished work. At the same time, all files have been marked as WIP, because of the huge amount of testing files. Files authors now can (and must) mark the files as "released" to be available. Do note, that prior to this we had tried contacting many authors with questions about the state of their files and also we asked (many) to remove testing files, with a very limited success. Based on a response of authors and manufacturers, this share update has been a necessary and positive step forward. Hope this helps, Cheers Petr
  20. Hello @Monkeypuzzle sorry for a late reply. It seems that the gobo is not in a correct format - it must be well defined in sense of regions: 1 transparent Background 2 opaque region (black) 3 colored region (white or colors) The GDTF spec defines this in more detail. As far as particular implementations, best is to check within each manufacturers support/forums. Hope this helps Petr
  21. Dear @mdodge thank you, appreciated you asked. Not at this point yet, other work was being done to improve the share experience (advanced filtering, manufacturers/products landing pages...), and ongoing work is focused to the new upcoming builder. It is not always possible to draw and easy line in this particular scenario. So we are aware of the request, but no progress at the moment. Let me say that i would also not suggest that you learn how to use the builder on your brand new secret product, but rather get comfortable on some older devices, because there is quite a bit of getting used to, especially if you are used to "develop for DMX", rather then "for visualizers". Also, thanks to the copy/paste, once you have few complete devices, it can be very quick to copy/paste/modify channels into subsequent device. cheers Petr
  22. The GDTF needs to be packed somehow, zip without any further computational overhead is a better choice then for example a tar, that would be harder for Windows users to use. The builder doesn't care when opening if compression is applied or not and from what i know MA (Daniel would need to confirm) will open them in the future too.
  23. Hmm, i am not sure and cannot check right now what MA3 version we are using currently. But, no issues discovered here, we would report it otherwise. Let me add @dmueller in cc, but i am sure he has seen your post in the MA forum.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.