Jump to content

GDTF Forum

ROBE Lighting GDTF files

Petr Vanek - Robe

Recommended Posts

On 1/13/2023 at 1:11 PM, Petr Vanek said:

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

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.

On 1/13/2023 at 1:11 PM, Petr Vanek said:

the total vertex count of what we provide for the Spiider is still below the recommended 1200 limit

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.

On 1/13/2023 at 1:11 PM, Petr Vanek said:

considering the pigtail should be a generic cube, which is what we add when we create the file.

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.

On 1/13/2023 at 1:11 PM, Petr Vanek said:

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.

Can you point me to the section of the GDTF specification that covers this detail? All I can see is a single line stating,


All models of a device combined should not exceed a maximum vertices count of 1200 for the default mesh level of detail.

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.

Link to comment
Share on other sites

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.







Link to comment
Share on other sites

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.


Link to comment
Share on other sites

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).

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in

Sign In Now
  • 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.