Shapers, Blades, SoftBlade and Keystone physical layout and order is undefined

[RichardTea]

Is your feature request related to a problem? Please describe.
The physical arrangement of beam shaper elements such as framing shutter blades and barndoors is not defined anywhere within GDTF.

This means GDTF files will be created using a variety of different conventions - different blade numbering, A/B pushrods, rotation and depth conventions.

Describe the solution you'd like
The physical ordering of framing blades 1 thru 4, A/B, blade and blade assembly rotation must be defined in relation to the Beam geometry affected by said framing. The same applies to other forms of beam shaping, such as ovoid/silk-style lensing/filters (where is the zero'd long axis?)

The units of blade depth must be defined. On Eos 100% framing blade depth means exactly halfway across the beam. What is the GDTF convention?

This will require a diagram, preferably of a moving head with Tilt at +90 degrees casting a beam onto a wall, similar to those provided in Robe fixture manuals.

For 'CW/CCW Pushrod' (common on HES fixtures), this needs to unambiguously show which side of each blade is A and which is B.

For 'Insert+Angle' (common on Robe fixtures), this needs to indicate the nominal zero and positive/negative rotation angle directions for each blade, and whether Blade*(n)A or Blade*(n)B is to be used for insertion.

For all types of assembly, the 'global' framing blade assembly rotation nominal zero and positive/negative assembly rotation angles must be defined.

[RichardTea]

The Eos shutter convention is currently documented here:
https://support.etcconnect.com/ETC/Consoles/Augment3d/The_Complete_Guide_to_Shutters_in_Augment3d

GDTF requires similar documentation.

[petrvanekrobe]

This is a good point. We are currently working on extended explanation for all attributes, the idea is to have textual description (in the "explanation" field) as well as images/diagrams and/or videos (in the "visual" field):

https://github.com/mvrdevelopment/spec/blob/Attribute-with-extended-explanation/function_matrix/attributes.json

https://github.com/mvrdevelopment/spec/blob/Attribute-with-extended-explanation/function_matrix/attributes.json#L2886

Later, we can fold this into official Spec as well.

[petrvanekrobe]

I have done some of the images, hope this make it clear for the Blades(n)A. If yes, i will make more.
The physical value of the blade itself is that: 0 is the blade fully out, 1 blade is fully covering the beam.

[RichardTea]

Couple of things missing:

• Needs to show the Beam XYZ orientation axes - primarily for static fixtures (which don't have P&T) and of course multibeam fixtures.
  I don't think there are any multibeam fixtures that have framing shutters yet, but no doubt someone's already thinking about it!

• For the common case of a moving head, state the physical angles of Pan and Tilt for the diagram.

• The Rotate ones need arrows showing the positive and negative directions. The title alone is unclear.

[moritzstaffel]

In the builder we have updated the images that show this with the GDTF like definition. There are nice videos that show this.

But we need to add more info in the help section, so that is is more clear.

[RichardTea]

I recently examined a selection of fixtures from the GDTF Share.

I found that at least three different shutter blade order conventions had been used. Some fixtures by the same author have even used multiple different conventions!
The two most common conventions were "in DMX order" (ignoring reality entirely) and the Eos convention. The only fixture I found that used the convention described by Petr was the Robe Robin T2 Profile dated 2024-01-08.

The gdtf_attributes_with_description.json only states top/left/bottom/right of the projected image, it does not specify the beam orientation involved.

There are a lot of parameters that rely on the orientation of their beam, and this still remains entirely unspecified in GDTF.

[petrvanekrobe]

We have about 170 DMX modes in over 40 fixtures in the GDTF Share which work correctly against the implementation in gMA3, if you want some files for testing Richard. We will take the description from the json, rewrite it from l/r/u/d to x/y/z and add it to the attributes specified in the DIN SPEC.

[petrvanekrobe]

Resolved in #270