After some trial and error, I found my “bug”: For some reason, the physical values in the Iris channel were flipped (or maybe the way that they are computed have changed?) from my initial build. I inverted them and now everything works again. …bit of an oversight on my part… Thanks for the help anyways

Hello, I’m running into an issue where, for some reason, I can’t get MA3D to render a beam in Gobo (and upwards) render mode in the MA3 v1.4 for some of the GDTF-Fixtures I built. However, you can still see the "lens" light up and change colour and in line and simple render modes a beam is still produced. Weirdly, the same GDTF-Profiles have worked in previous MA-Software versions. Only the fixtures with Gobos/Animations Wheels seem to be affected. Simple wash-fixtures still work fine. The Robe fixtures also seem to work fine (I’ve tried the Mega Pointe, and Pointe in this instance). Which makes me think is probably an error on my part. As a test, I tried to open an old fixture of mine (ClayPaky Axcor 900 in this case) in the GDTF-Builder and rebuilding the Gobo Channels, the Gobo-wheel and also removing all the “new” errors in the new builder and re-exporting it - without success. I have compared it to the Mega Pointe in both the Builder as well as in the MA3 software, but I can’t see any differences. I could imagine that it is an issue with the png’s. However, I cannot find any information on how the png needs to be, apart from max size. When I initially built the fixture, I tried to replicate the way the gobo.png’s are built in the mega point: 1024x1024, black and white with an alpha channel around the edges, and as I said, this worked fine previously. I’m probably missing something obvious to make it work. Thank you, best regards

Not that many, all models together, so Base, Yoke, Head and Lenses, are right around 1000 verts give or take few. Due to the very spherical and round nature of the fixture it was a bit tricky getting the vert count down to that number without it looking like garbage. But then again, that could just be me. I'm only getting into the 3D-Modelling aspect of things. To clarify, the builder, as well as MA3 3D, rendered prior itterations of the models fine, just the "total number of vertexes" indicator in the properties sidebar in the geometries window showed values above 1200 and turned red. I have the same "issue" now when i add a second geometry tree - the vert number doubles. I assume that the limit is the maximum reasonable number of verts, so even lower power machines and visualisers can render the model - even with a high fixture count. With the the line from the wiki i also interpret it in the way that creating as many geometry trees as one likes is fine as long as you reuse the same models. However, together with how the fixture builder currently displays the vert count, i still think it isnt exactly crystal clear as to how the vert-limit applies.

That helps! I'll try that approach! I stayed away from this approach, because the fixture builder started to complain about reaching the vertices limit. Am I right in the understanding that the vertices limit is defined per geometry tree rather than the file as a whole? If so, the vertices count indication in the fixture builder is currently very misleading, because as far as i can tell, it counts the vertices of the whole file rather then the individual trees, resulting in misleadingly reaching the vertices limit as soon as you add a second geometry tree, which should probably be changed. Thanks for the help!

Indeed i am! Thanks for the help!

Hello all, I am trying to create a GDTF File for the JB Lighting Sparx 7, which includes both the full multicell Pixelmapping mode as well the “Pattern Control” and Basic/single-instance Mode. The way the pattern control is handled by this fixture is by having 3 “virtual zones” which affect the single cells differently depending on how the mapping control channels are set (similar to the robe spider I think, just slightly more convoluted). I’ve created a base, yoke and head geometry as well as beam geometries for each of the 3 virtual zones, with 2 of the virtual zones being beam type “none” (similar to how it’s done with the Martin MacAura XB to represent the Aura) and only the “Main” virtual zone being a wash beam type, as these channels would be what would give the fixture its colour in real live, if no mapping is active. Additionally, I added a pixelengine geometry as a head-geometry-child, alongside the beam geometries, referencing the individual cells. Both the “Pattern Control” and the pixel DMX-mode have these virtual zones. All modes have 1 Master Dimmer. The Problem I am running into is this: If I assign the Master Dimmer DMX-Channel to the Head Geometry, all child geometries “inherit” the value, even the ones which don’t have any DMX-Channels assigned to them, causing them to be visualised(in GrandMA3 3D at least) without having control over them. For Example, in the Pattern Mode(which doesn’t require/have the individual Pixels), the pixelengine would also be visualised in white or rather the individual beams of the cells, despite not having any DMX-Channels assigned to corresponding geometries. The virtual dimmers for the virtual zones as well as the colour channels and beam visualisation work as expected. Additionally, only the light beams of the cells are rendered without showing the cell models themselves (also when only assigning functions to the “pixelengine” parent for the basic mode), but this is probably something for a different thread. The easiest way to fix this, in my head, would be a function of sorts or a relation similar to a virtual dimmer that blocks or overwrites this inheritance behaviour. Another way would be to just ignore all child geometries without DMX-channels assigned to them all together in a visualizer. That way, you would have all modes in one model and GDTF File. However, it feels like I am probably just missing something obvious. Thank you in advance. Best Regards