Mac Performance shutters Augment3d vs real life.

There seems to be quite a discrepancy. As far as I'm aware I've got reasonably accurate locations for the movers in the 3D space.


  • Would you be willing to share your show file (feel free to private message me if you don't want to post it publicly) and details about the channels pictured?

  • Sorry for the delay, I've sent the show file and details in a PM. Thanks.


  • Hi,

    I managed to do some more digging and I've discovered a number of issues. First positive/clockwise rotations of the shutters and the frame in real life appear as negative/anti-clockwise rotations in Augment3d. The range of movement of the shutters appears to ±30° IRL, but the visualiser maps to ±45° (in the wrong direction). In the parameter controls overlay that shows an image of the gate the same ±30° of travel in the real world is shown as ±100° (instead perhaps of %), and again in the wrong direction. 

    BTW, what is the name of the lower part of the display in this image? I can only seem to get it in Nomad, but I would think it would be useful on a live desk sometimes too.


  • Most of the issues displayed in the recent screenshot likely have to do with Augment3d not taking into account the shutter order. This is on the list for future improvement.

    One thing to check for the range of movement is what is defined in the fixture library profile for the fixture.

    The lower part of the display in this image is called the Encoder Controls Display (See:Encoder Controls Display)

  • Let's try and set this out more clearly:

    For me the frame order (A,B,C,D) agrees between real life and Augment3d, however positive movement of frame angle and frame assembly is clockwise in real life, but anti-clockwise in Augment3d.

    The movement range of the shutter with these units is +/-30° which should be represented in the desk as either a +/-30° range (c.f Zoom), or be mapped onto the default range of +/-100%, which is how it is in this case. In Augment3d the % value is treated as an angle, rather than a proportion of max. travel. In the visualizer the effective range becomes +/-45° for reasons unknown.

    In the Encoder Controls Display the range of movement of the shutter becomes +/-100°, disagreeing with both the visualiser and real life.

    And finally a shot showing how the frame has moved in the opposite direction in the real world. The overall result is that the visualiser is not going to produce a representative beam shape when the frame and/or assembly angles are non-zero.


  • Giving this some more thought, if Augment3d maps the real world range -30° to +30° as +100% to -100% in the visualiser then using a correction factor of -0.3 for the frame angles (and -1 for the frame assembly) should produce a better approximation. Here is what I get after bashing the numbers into a spreadsheet, applying the correction factors, and putting the results into Nomad. Much closer to real life. 


  • Augment3d always uses the real-world "user" values as specified in the fixture personality.

    • If a parameter is moving in the opposite direction to the 'real world', swap the User Min and User Max values over.
    • If the range isn't quite right, adjust those User Min and User Max to be the actual range the fixture actually does.

    Frame Angle is in degrees, so you can measure this directly - though make sure the beam is perpendicular.
    Frame Thrust and Frame a/b "100%" is exactly halfway across, with 200% being all the way to the other side.

    We're reliant on fixture manufacturers publishing the data, and a lot of fixture manufacturers either don't say at all or round off the published numbers to a "nice" figure. IIRC we guess at +/- 30deg if not specified as that seemed 'common', but is clearly not truly correct.
    Sadly many of them don't even specify the actual shutter order.

    Thanks for doing these measurements, we'd like to update the fixture library, can you can send us your corrected personalities?

  • Hi Richard,

    Thanks for this. I've tried updating the user ranges and while it does make Augment3d render more realistically I can see some issues. For example the max. thrust for the frames is approximately 93% estimated by putting opposite shutters to max, and comparing the remaining width to the full beam. But if I put that user range in the fixture then I see a full shutter at 93% rather than the 100% (DMX 255) value that I would expect. 

    Measured angles on the shutters is a mere +/- 26° rather than my earlier estimate. And if swap user min and max around and set the range to +26 > 0 > -26 it looks sensible in Augment3d with the existing data, but it feels weird to have the min. value clearly larger that the max. I've only tested on Nomad, but I suspect using the encoder wheels would feel wrong too. Before making any changes clockwise on an encoder wheel matches with clockwise in the real world. I'm pretty sure that if I loaded the updated fixture profiles into the live desk that would no longer be the case. I suspect there would be a workaround flipping the DMX ranges instead, but that would likely break an existing show so I'm not going to be testing that.



  • The general idea is that all fixtures should behave "the same" regardless of type (within their limits).
    - If you hang a Robe, Martin and ETC fixture side-by-side, insert the A shutter to 50% and rotate it to +20deg, they should all do the same thing.
    In theory, at least!

    Same as for Pan and Tilt - some fixtures physically rotate in the opposite direction to each other, Eos tries to hide that difference so all moving heads move 'the same' way.

    Of course, if you've got used to the 'wrong direction' for the fixtures you commonly use, then correcting that will feel weird!

    The "Shutter Order" tool is intended to let you alter how the encoders and CIA shutter tool behave so that it 'feels right' given your preferences and how each individual fixture is physically hung - same as "Invert Pan" et al.
    Sadly, as Kirk mentioned, this currently breaks A3D visualisation.

  • Thanks again. I think this still needs some work so Augment3d can be corrected without adversely affecting what is already working elsewhere.