Jump to content

GDTF Forum

All Activity

This stream auto-updates

  1. Last week
  2. Hi all ! I have this: Build: GDTF GDTF: OK MA3D: OK Vision 2023: NOPE it just flickers Vertices: 208 Total Number of Vertices: 972 Does anyone had the same problem? Vertex Video.mp4 Litecraft@PowerBar_X15@Powerbar_x15_all_modes.gdtf
  3. when i copy too many channels, mostly shutter, and i try to save the fixture i get a processing window that never ends. at the same time trying to enter the builder on the phone from the gsm network (not local wifi) and it is not possible. the ability to enter the builder appears only after I turn off the window with the processing of the record and wait about 10 seconds sometimes much time
  4. Earlier
  5. I misunderstood your comment, sorry. I'll give a try manually with the xml, but that's a lot to do by hand. Anyway thanks for the help, hopefully the tool will be more friendly in the future. R, iLevac
  6. Manufacturers have the same tool you have - the Builder, here. GDTF is just a zipped folder, you can open it and edit the description.xml by hand or by custom tools...
  7. I would happily do the GDTF fixture profile and then share it online with both the manufacturer and the community. I feel like asking the manufacturer will take a very long time, but I will give a try. That's unfortunate that manufacturer have better tool than user to create those fixture profile. I do usually start with a profile that do exist and edit it, but with the online GDTF builder, it's quite limited, I cannot import the DMX profile only or download, edit via a txt or xml file and them upload it back to GDTF. That would be so much more easy if there was a way to edit via text since with the webui that will take forever. Thanks for the info iLevac
  8. As for the Beams definition, i will have it to be checked, some of the data seems not correct, thank you. The Min/Max... values are related to DMX Profiles, that is curves defining relation between linear DMX and (nonlinear) behavior of the physical element. This is not physical from/to, that is in the PhysicalFrom/To. The (Minimum Physical Value that will be used for the DMX Profile. Default: Value from PhysicalFrom). As for the LuminousFlux value in the beam, this is just an indication of the output of the device to have some reference, then there is more precise data, such are the Emitters/Filters sections. As far as spectral power distribution of emitters, all of Robe color measurements are consistent, taken at a consistent distance, taking square root law into consideration and so on, to ensure that spot/wash/linear devices come with measurement that are possible to be used. For more detailed beam description, LDT or IES (or the new TM 30-18 description) will need to be used, which is planned for GDTF for the future. The description of the beam is (say LDT) is still providing an information about one particular setting (for example zoom).
  9. I don't consider a pigtail to be a basic 3D shape, GDTF Builder considers it to be a cube, while MA-3D appears to consider it to be something closer to a shpere, personally, I expect pigtails to be more cylindrical and it's cylinders that I see most often when manufacturers include then in the CAD symbols. Cubes, spheres and cylinders on their own may be considered basc shapes but I don't think there is any agreement on pigtails always being one of those distinct shapes. I think our thoughts on the various aspects of the 3D side are very different and I doubt we'll find common ground on this. Getting back on the topic of reporting anything that seems problematic, looking at the GDTF file for the Spiider, there are some things that seem wrong to me or don't make much sense, a few that I can recall specifics on are: 1. All beams are defined as having a beam radius of 50mm, I don't have access to a physical fixture to check but I would think this must be in the region of around twice the size of the physical lens? 2. All beam are defined as having a CRI of 100, this seems optimistic? 3. All Min/Max attribute values are 0 and 1 respectively, consider for example the Pan attribute definition: <ChannelFunction Attribute="Pan" CustomName="" DMXFrom="0/2" Default="32768/2" Max="1.000000" Min="0.000000" Name="Pan" OriginalAttribute="" PhysicalFrom="-270.000000" PhysicalTo="270.000000" RealAcceleration="0.433300" RealFade="2.300000"> If a consumer considers and implements the Min and Max values as defined then the operator would experience a total range of movement on pan of just 1 degree? 4. Is the method of measuring a beam's LuminousFlux documented anywhere? I see wildly different values being used in GDTF files for different fixtures from different manufacturers but with the same LED emitters, I'm sure optics plays some part in it but I'm seeing differences of as much as 800%, I have to assume that these fgures are being determined with different methods.
  10. Hello and welcome, i would suggest that you contact the device manufacturer and ask for GDTF from them. What GDTF provides them is a tool do create the file, distribution platform, documentation about the format, documentation about files creation and so on. You could make the files yourself, but then the device manufacturer never knows that there is a need for GDTFs. As far as converting MA2 to a basic GDTF structure, i am not aware of such tool. Given product similarities, i would think it might be more interesting to start from and existing GDTF file for a device from the same manufacturer + product category and modify it for the required device. As for the 3D, convert it to glb, rather then 3DS. Hope this helps Petr
  11. Hi, It's my first time playing with GDTF. I'm doing a show with an MA3 and I would like to have the best fixture profile and have a working 3D as well. The solution is simple; use GDTF fixture profile. However, most of the fixture type I'm using don't have a profile in the library yet. I'm trying to built the profile, but it's gonna take forever to do it by hand. I was wondering if there is a way to import the fixture profile from an MA2, to have at least the dmx part done? For the 3D, most of the manufacturer give a DWG, but I assume converting to 3DS isn't a big deal. As of photometric information, is there a way to import this data from common photometric files (IES, LDT)? Regards, iLevac
  12. GDTF does specify the following primitive types: “Undefined”, “Cube”, “Cylinder”, “Sphere”, “Base”, “Yoke”, “Head”, “Scanner”, “Conventional”, “Pigtail”, "Base1_1", "Scanner1_1", "Conventional1_1"; and it also provides models for these primitive types (here) with the exception of the basic 3D shapes like cube, cylinder, sphere and pigtail, which (pigtail), in the default implementation by the GDTF Builder, is being provided by a cube. Again, some internal implementation by specific software will vary slightly as i mentioned, this is why it is better to talk to the vendor directly if needed, as for example getting a precise vertex count depends on the software library you choose to use.
  13. There is no mechanism for an operator to set a vertex limit directly, the limit is a product of the render settings, I determined what the vertex limit is for the default settings by taking a model that was being visualised as boxes and reducing the vertex count of the model until the actual model geometry was visualised. My understanding of the GDTF standard is that the total vertex count for a model includes the vertices of all geometry, in the case of the Spiider this would include the pigtail primitive and any and all geometry references, not just the vertices from the model files as you were/are counting them. From some basic testing with MA-3D, that application certainly considers vertices from primitives and references as counting towards the total vertex count for a model, this is inline with my expectations and I consider it to be correct behaviour. I feel that this highlights an issue, how is it possible to create a model to a limited vertex count while that model contains objects of unknown vertex counts (i.e. pigtail primitives)? As the GDTF standard does not detail the construction of the primitives and places no limitations on the vertex counts of these primitives it seems that platforms and applications can construct these primitives however they wish with as many or as little vertices as they like. The pigtail primitive is not added to the GDTF file at the time it is created, it is provided by the platform/application that subsequently loads the GDTF file. Your builder may consider the pigtail primitive as a simple cube of (presumably) 8 vertices, but there is no guarantee that all platforms will provide a simple cube. I took the Spiider model and moved the base to get a clearer view of what MA-3D is providing as the pigtail primitive, here is a screenshot of the pigtail primitive, As you can see, it's slightly more complex than a simple cube and certainly consists of considerably more vertices than that of a simple cube. Can you point me to the section of the GDTF specification that covers this detail? All I can see is a single line stating, There is no mention of this only being applicable to some types of fixtures and no mention of what if any limits apply to other types of fixtures/devices.
  14. I presume you mean the Resource Manager in VectorWorks? Let me add @klinzey here, maybe he has an idea, or knows if this is planned for the future. Cheers P.
  15. Is there a way to link all my fixtures with GTDF data in my file within my Resource Manager Favorites list? That way I do not have to import GTDF and link every fixture every time in a new file. I want it so that when I select my fixtures from my favorites list they automatically import the GTDF as well.
  16. FYI, we have cut some parts of the model and decimated the model slightly more, to get under the MA limit to get their default 3D view with our custom meshes. You can see the result on the Share. Have a good weekend 🙂
  17. Interesting... I cannot see where i can set the limit to be below/above 1200 vertices in MA, i only can see Standard/High/... settings, including in their documentation, where can you see this? As per your and mine calculations, the total vertex count of what we provide for the Spiider is still below the recommended 1200 limit, considering the pigtail should be a generic cube, which is what we add when we create the file. On the side note, the GDTF recommended 1200 limit is for a traditional moving head with base, yoke, head and one beam, rather then for a fixture with 19 beams. It is a good conversation, but as this is about specific software behavior, i would suggest that you discuss this behavior of the MA software with MA as i have no inner knowledge of their system...
  18. The Spiider only comes up if I allow MA-3D to visualise models with vertex counts >1200, this should not be a requirement to visualise GDTF models as the total vertex count for any one model should not exceed 1200. As such I don't consider it correct to say it comes up "OK". I prodded the system a little more on this and have determined that the pigtail primitive generated by the current version of MA3 onPC consists of 190 vertices. Adding this 190 to the total vertex count of the Spiider models (1126 including geometry references) results in the Spiider having a total vertex count of 1316 which explains why MA-3D (with default settings) visualises the Spiider as a collection of simple primitives.
  19. Thank you for confirming that the Spiider comes up OK for you. At the end of the day, we don't control software defaults and even if we try to micro-optimize the Spiider, if you for example add Tarrantula you will have the same issue, so LOD setting will be needed anyways. As far as details of the multiplixel multilayer based devices, this is work in progress for better visualization. You will have to ask MA about the details of their software. Petr
  20. I don't believe this vertex count to be correct, as I don't believe that reusing model files and/or geometry referencing comes for free, does it? pixel3.glb may contain 20 vertices but it's referenced 12 times in the geometry so I don't believe that it adds just 20 to the vertex count, my testing would suggest that it adds 12 x 20 (240). Similarly, pixel2.glb is referenced 6 times so it adds 6 x 10 (60) to the vertex count and pixel1.glb twice so adds 24 to the vertex count. The actual vertex count from the model files is: models/gltf/yoke.glb 202 models/gltf/head.glb 302 models/gltf/pixel3.glb 20 x 12 (240) models/gltf/base.glb 298 models/gltf/pixel2.glb 10 x 6 (60) models/gltf/pixel1.glb 12 x 2 (24) total vertex count: 1126 However, this total does not take into account vertices from any additional geometry, the "Pigtail" for example, this also does not come for free with regards the vertex count. I haven't seen anything within the standard that details what the max vertex count should be for any of the internally or auto generated primitives, it seems entirely arbitrary and down to the individual consumers to use as simple or complex objects as they see fit. For sure I'm very much at beginner/entry level when it comes to all things MA and I could be wrong, however, I don't believe that is the issue in this case. My testing suggests that the MA-3D window with "out of the box" default render settings will visualise models with a vertex count just over 1200 (if my test count is correct, 1210 seems to be the max), anything over that then the model is visualised as simple primitives ("packing boxes" as you term it). I can reliably trigger the "packing box" look by doing nothing more than increasing the vertex count which leads me to conclude that changing (upping) the level of detail for rendering does not, as far as I can tell, enable visualisation of external model files but rather enables visualisation of models with higher vertex counts. I took the Spiider GDTF file and removed the Pigtail from the geometry and then the model files are visualised with the default render settings which leads me to conclude that the internally generated pigtail primitive adds a significant amount of vertices to any geometry that includes it and, in the case of the Spiider model, tips the vertex count over the max count defined by the GDTF standard for default resolution of 3D models. Either that or there is some issue with the Pigtail definition that's giving MA-3D a hard time but I didn't see anything untoward from a casual glance. See below for a screenshot of MA-3D with default settings, your Spiider model above, my Spiider model below. My Spiider model files accumulate to a total vertex count of 1186. If my conclusion is correct that the "packing box" look is triggered by vertex count then it makes no sense that a model with a total vertex count of 1186 is visualised correctly while model files that you say total 844 vertices are being visualised as simple primitives, if I'm incorrect in my conclusion I would like to know what exactly does trigger the packing box look. Does anyone know if there is there any logfile that MA3 produces that might provide some details on this?
  21. > not being too familiar with GDTF or MA3 it's unclear to me Thank you for your feedback, much appreciated. The GDTF provided limit is more then enough for us to provide nice models and also the lens shapes. And if we needed more, there are now three levels of details in GDTF itself to provide really high quality meshes. The Spiider uses less then 900 vertices: models/gltf/yoke.glb 202 models/gltf/head.glb 302 models/gltf/pixel3.glb 20 models/gltf/base.glb 298 models/gltf/pixel2.glb 10 models/gltf/pixel1.glb 12 total vertex count: 844 As for MA, you need to get at least a bit familiar with how to use the software you want to use for the testing. MA requires you to change level of detail for rendering, as sometimes they change the models to look like packing boxes. Once the setting is done, what you will see is this: When at full, they look like this: Hope this helps, Petr
  22. The current version of the Robin Spiider is being visualised as primitive types only on the current version (v1.8.8.2) of MA3 onPC (see attached). Also note thatonly the center pixel is being visualised, not being too familiar with GDTF or MA3 it's unclear to me if that is simply the result of the visualised primitive types or a separate issue. According to the share, the 3D model has been tested, how is this being tested? I do wonder about the benefits of creating fixture specific models, it seems that most are very low quality significantly lacking definition of the details to such an extent the model is barely (and in some cases, totally) unrecognisable. I understand the main purpose of the default res of the model is for use by visualisers and as such super detailed models are not required, but, the max 1200 vertex restriction is too limiting in many cases.
  23. All currently available Robe GDTF files have been converted to use the glTF mesh format, in the form of glb files. You can read more about it here https://gdtf-share.com/user-page?name=Robe+Lighting+s.r.o.&page=home . This change has happened already in October/November, together with many other improvements and changes like converting the Connectors into Wiring Objects, adding 2D and also including the above mentioned more streamlined linking of channels to particular geometries. Let us know in case of any issues.
  24. Hey all I need an Fixture for the Varytec Hero Spot 230. I can`t handle the builder. Can you help me an build the Fixture for me?
  25. I have the password stored in a password manager and used the same password to log into share and the forum. After changing the password to a shorter one with no extended characters, it seemed to work. Do you know if the builder app has different restrictions on password size or special characters?
  26. Signing into the builder seems to work OK here. I would presume that you have forgotten your password, you can reset it on the https://gdtf-share.com/forgot-password link. Hope this helps Petr
  1. Load more activity
×
×
  • 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.