Jump to content

GDTF Forum

Value inheritance without assigned DMX-Channels


GreenManProductions

Recommended Posts

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

 

 

 

Link to comment
Share on other sites

Sounds good! I would explore looking at different Geometry trees for different modes when neccessary. For example single cell mode vs. 3x cell mode in this case I believe. For users, it doesn't make sense to have a reference or instance pending control platform for a simple single output device. So in this case I would just have a normal tree, Base > Yoke > Head > Lens., etc etc. But in the 3x cell mode I would make another tree that makes it easier to control and define for users using the same models in the file, Base > Yoke > Head > Ref 1, Ref 2, Ref 3 etc etc.

In regards to: 

Quote

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.

This is pretty easy to fix with doing the above. You can have as many geometry trees as needed in the file and then have the different modes reference the appropriate tree. Example of one would be the Colorforce II 72 that I made that has 180 modes, and I have about 30x different Geometry trees in it, but it's still a single file that isn't very big as the models are all the same. 

Using different tree's will allow you to define the relatonships between Master dimmers and virtual dimmers and any other relationships much easier as well as having them be more friendly in visuzlization softwares utilizing this information.

Does this help?

Cheers!

MattG

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

I agree, it's somewhat misleading if you're getting that error?!? How many Verts were you trying to stuff into the entire 'fixture'?  You can get away with some really simple geometry to represent most anything.  I've seen 'fixtures' with obscene amounts of geometry data[vertices/polys] in GDTF files and not seen the builder complain that badly...

 

From the format description: Model Collect

Quote

When preparing 3ds resource files, consider the following: All models from a device combined should have a maximum vertices count of 900 to 1200.

To these eyes, this reads as the total amount of vertices to be  no more than a maximum of 1200 for an entire 'fixture'.  That's a fairly generous amount to get a decent rendering of a moving head fixture, even with a separate Mode or 2.  I've seen environment models with close to 15,000 vertices and I didn't see the builder complain when I just now did some tidy work on some random fixture at the Share site I saw uploaded but not really rendering as a 'fixture' and the Scale was totally wrong when viewed in the builder with it's penchant for only seeing models in millimeters when exported.  MA3 can deal with a model that is exported in meters...

It would be great to get a clarification on this, as to what constitutes the 'total' within the collection...almost seems as if it's per/model though.

Good luck!

Link to comment
Share on other sites

It makes sense to me...the Parent is the container for all sub objects...so I do think the description may mean, per model.  Even with super high vert counts on models, the objects still render in the builder.  I think they start to visually bork out at like ~65,000 verts[256x256,:)]...truncate groupings, etc.

Link to comment
Share on other sites

57 minutes ago, David "Rex" Whalen said:

How many Verts were you trying to stuff into the entire 'fixture'?

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.

 

8 minutes ago, David "Rex" Whalen said:

Even with super high vert counts on models, the objects still render in the builder.  I think they start to visually bork out at like ~65,000 verts[256x256,:)]...truncate groupings, etc.

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.

Link to comment
Share on other sites

  • 2 weeks later...
On 4/27/2020 at 4:32 PM, mgeasey@clearallvisualsllc.com said:

From what I've seen, I believe there is an issue when selecting the parent of geometry trees in that it is adding everytime and not only showing what that tree's total vert count is.....(red number). I'm waiting to get some clarificaton on this though so its just a hunch!

 

Thank you, issue reported.

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.