Jump to content

GDTF Forum

Petr Vanek - Robe

Moderators
  • Posts

    426
  • Joined

  • Last visited

  • Days Won

    41

Everything posted by Petr Vanek - Robe

  1. The idea was that these are a "truthy and falsey", so they are equal - no equals to off, yes equals to on.
  2. Do you mean "browser autofill", not the builder provided Auto Fill sets, right? (this one: ) I think the generic autofill can actually get in the way a lot and copy/paste seems much safer. I would suggest a clipboard manager, i have been using https://hluk.github.io/CopyQ/ although not on Windows/OSX.
  3. >i'm writing an open-source GDTF-Parser for Rust Great! >Page 35 ChannelFunction.ModeMaster is not defined as optional but in some GDTF-Files from GDTF-Share there is nothing there... Thank you for the report. If you encounter more unclear places, please report to https://github.com/mvrdevelopment/spec/issues thank you Petr
  4. Hi @michaelhugi, yes, this is currently being developed. There is an existing API that the builder already uses and it is being extended to allow data consumers to pull the data and also data creators to upload the data. Kind regards Petr
  5. I reported the not loading file, the problem might be that three.js which we are using might not load it, which could be the issue. I did try another three.js based viewer and it worked, but the loader might be different under the hood there... we will see that the devs will have to say... cheers P.
  6. The channel default is defined by logical channel → initial function → channel function default value. The channel function defaults are used when channel functions are switched automatically based on channel dependencies. In that moment, the uses might want to have a value different then the lower bound of the channel function, for example to have a middle value.
  7. @etiles interesting, thank you. Is it possible the provide the 3DS file which gives you troubles to import? Also, i presume you need to use older Blender (2.79), to export 3DS, or do you use Blender 2.8x and you installed an extension? Petr
  8. Good points. As for the new attributes, Tint already exists (we must add physical unit, i think this should be ΔUV defining the amount of shift from the light source's defined ΔUV). What do you think would be the physical units for CCT and White Point? Kelvin? What would those custom color parameters be? It does makes sense to be specific, of course, if possible... cheers P.
  9. Hi @erwan see that original file V1.1 attached as SampleGeneralSceneDescription.xml, i am also attaching recent GeneralSceneDescription.xml which is V1.4 which has one device inside. Hope this helps, Kind regards Petr SampleGeneralSceneDescription.xml GeneralSceneDescription.xml
  10. Prisms in GDTG are part of the Wheel and in particular, they are inside of what is called a Wheel Slot. Prisms definitions in GDTF allow precise definition of each of the prism facet and it is done by using transformations represented by Rotation matrices. There are many resources on rotation matrixes, for example this Wikipedia article and also many game engine related tutorials and articles, like this one, which is useful for our 2D prism definitions. In the GDTF Builder, there is a really nice Prism editor which can do some of the math for you, like rotations and transformation (movement): The editor also allows you to visualize multiple facets at the same time and show a circular view, which is useful for checking the final result. Here you can see linear and circular prism represented by the Rotation matrix and also visualy: When defining prisms/prism facets, it is good to know how the Rotation matrix works or at least what each field means. Here i labeled the fields important for prism definition: It is important to know what are the units used for the transformation. For the sake of simplicity, we can say here that the unit used in the matrix is "the radius of the unaltered beam". This sounds weird, so lets make an example: Let's say, that we wont to define a linear prism, which looks like this: We need to define three beams. First one in an unaltered form, so horizontal and vertical scale are 1, and there is no rotation and no offset (translation): Now we define one facet to the left, touching the first beam. As the translation is to the left (negative) and it it 2x the radius of the unaltered beam, we enter -2 into the Horizontal translation field: Now, we define the facet to the right, just touching the first beam. As the translation is 2x the radius of the unaltered beam, we enter 2 into the Horizontal translation field: So anytime we want to move the beam from the original position, we simply use the original beam as the reference. Of course, in real life, we will need to do a bit of math, here is a practical example: Linear 4-facet prism Measured projection on a wall: Unaltered beam diameter: 53 Offset of beam centers from center of unaltered beam, facets 1,2,3,4: -99, 30, 30, 99 Vertical translation: facet 3: 30/53*2 = 1.1320754716981132 facet 4: 99/53*2 = 3.7358490566037736 facet 1: negative value of facet 4 facet 2: negative value of facet 3 Horizontal and vertical Scale: If the altered beam was different, for example 55: 55/53=1.0377358490566038 Resulted preview: And the definition: Circular prisms The Builder Prism facet editor contains a handy tool to define what is the offset of the facets from the center and will calculate parameters for the desired number of facets placed in a circle around the center: Here is the initial generated result (preview): And the definition: But you must pay attention also to the rotation of each facet. The above example shows us that some facets are actually rotated: Which we must adjust by using the Rotate tool on each of the facets where this is required (-90, -180, -270): To achieve our final look: And definition: Hope this helps Petr See all Robe Knowledge Sharing Articles.
  11. ErrorCode67: "If two channel functions use the same DMX range, mode masters should be defined" 🙂 P.
  12. Hi guys, i listened to your discussion on Friday, certainly a good talk about GDTF, the name check was totally unexpected 🙂 , thank you 🙂 All credit here to the team, both in the GDTF group and also in Robe - to the guys collecting the data and punching it in 🙂 As for the few things i remember i wanted to comment on: - gobo rotation between fixtures/manufacturers - yes, GDTF is providing mapping between control and physical, so as long as you say what speed and direction you need and the data is present in the GDTF, the console has the ability to send out the required DMX for multiple fixtures to work in the same way. - as for the prism visualizing in the builder, this in fact does exist, see here: As for "ensuring that manufacturers do a good job", i wish that that includes both fixture manufacturers and also console manufacturers 🙂 Please feel free to ask here any question that you might have raised i missed now, And keep up the discussions going, cheers Petr
  13. A DMX Mode is a container holding definition of DMX channels and GDTF allows us to define multiple DMX modes for a single device withing one GDTF file. The concept of multiple DMX modes is good, because not only we can have a complete device definition in a single GDTF file, but we can also define DMX modes for different software version of the device. This allows us to provide both older and newer versions of DMX definitions if needed. For this to work in the GDTF Builder, we must first define RDM details on the Fixture tab: If you do not know the Manufacturer ID, it can be found here: https://tsp.esta.org/tsp/working_groups/CP/mfctrIDs.php . The Device Model must be retrieved from manufacturer documentation, or you can also try to find it in the OpenLighting database: http://rdm.openlighting.org/model/display?manufacturer=21075&model=263 . Do note that you fill in the hexadecimal values, not the decimal representation. With these data being filled in, you can now define DMX Model and provide the name, top level geometry (base) and the "RDM Software version + RDM Personality ID" pair for each DMX Mode: If you have for example a DMX Mode, which was added only in software version 2, you can define this pair of Software Version - Personality values in the DMX Mode definition. So in the following example, we have a DMX Mode 1 and 2 available in software versions 1 and 2. Then we have DMX Modes 3 and 4, which were only added on software version 2: Hope this helps, Petr
  14. Hi @Livecue i think it is better to report directly in VW issue tracker or their forum... the will need to know what you are exporting the MVR from... cheers Petr
  15. Thank you @Janng for the report. I am glad to see Firefox and Ubuntu referenced 🙃 cc: @pedromagalhaes
  16. 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
  17. 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
  18. 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
  19. 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 See all Robe Knowledge Sharing Articles.
  20. 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
  21. >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 ?
  22. 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).
  23. 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.
×
×
  • 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.