Jump to content

GDTF Forum

mgeasey@clearallvisualsllc.com

Members
  • Posts

    98
  • Joined

  • Last visited

  • Days Won

    5

Posts posted by mgeasey@clearallvisualsllc.com

  1. In my opinion yes, because the manufacturers are responsible for providing the correct information for their devices which should be the baseline for users and software. Now, if users decide to edit or make their own GDTF files which is perfectly fine then the software should of course be able to bring that in.

    In my opinion, the software manufacturers looking to use GDTF should not be responsible for errors on the user side if the spec is not followed correctly. This creates an area of accountability and safety for Software's and manufacturers. If the users change or alter something, this now becomes an unverified file that the software developers and manufacturers cannot be responsible for. 

    At the end of the day, these files aren't meant only for users, they're for everyone.

  2. @szapo @Enviral_Design

    As a side note to this function, please keep in mind that downloading the entire library has the potential to cause problems as users can upload their own custom GDTF files that might not be supported by the manufacturer. As you can tell right now, there are a lot of test fixtures, user tests and manufacturer tests that are not correct or fully finished. I would recommend reaching out to manufacturers who are building and uploading to the share site to tell y'all which ones are done and ready. 

  3. Hey Pyroaxel,

    Is there a reason you want to do it in MA3 and not in the builder so that if this file goes to other applications that can use GDTF file in them?

    I would use User Tests so that we know it's not a manufacturer built file. 

    image.png.0531c48103137e46333753a4c9b1d351.png

     

    Let me know if this helps!

    Cheers!

    MattG

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

  5. Hey @LJFred,

    Sorry about the delayed response. It looks like what is causing the error is the way that the geometry is built with the rules that MA2 wants. Here's a screenshot of how I adjusted it to fix it for MA2, and in theory this should be fine for MA3. From what I understand, the Converter is going through the tree and building it from the top down for the MA2 rules. 

    I hope this helps!

    image.png.8724030eeb96921d437a16fa8e5a43ae.png  image.thumb.png.cac24df3dd379cd7cdfc109eb0413970.png

     

    Cheers!

    MattG

     

  6. @lyon470 there are some bugs in Vision currently, but those are being worked out and they are known. Don't get too discouraged about the GDTF/MVR import into Vision yet. But @David "Rex" Whalen is correct with if it looks correct in the GDTF Builder and MA3, then it's a safe bet to say it's functioning as you would like it to. 

    Cheers!

    MattG

  7. I'm with Rex on everything above. Creating good looking models is all fine and dandy, but as Petr stated as more of the larger poly models get added, it is gonna hit the resources of the machine harder. There's no need to have detail that  is not neccessary to the output of the beam of the profiles, the body parts of the fixture should definitely be proportionate to each other and replicate the fixture the best it can to an extent, but unless you're doing rendering's, once the scene goes dark for programming, the need is not there. We build all of our models from scratch in C4D and have been able to severely lose poly's and vertices without degrading the "profile" of the fixtue body parts. If everything is built correctly, one should be able to handle over 1000 fixtures and a full scenic model build out without too much FPS loss pending hardware.   

    • Like 2
  8. So, since I know it's only the wheels that are affected right now, is there a way to prevent anything like this from happening in the future as more features get put in, as it get's more depth to the builder? I know we are adding in really awesome vaidation features, but over time it shouldn't really break thing's that have already been pre-defined when pushing new builds online. I would think that anything that has been predefined should be fine, I'm curious as to how we see this as an efficient ask for users who are making their own profiles as they now have to go and check all their work again and do double time once they put in the initial time. Oh well haha! Thanks for the info on this so that we know to check everything as new builds get pushed! 

    Cheers!

    MattG  

  9. Hey Y'all,

    So, I loaded a tested file that is currently in use in the field and when I went to the DMX section, there's numerous errors but all referring to Wheel assigments. From what I understand, the new builder is suppose to re-assign the information appropriately to the new areas, but it seems that's not the case with anything associated with wheels. 

    image.thumb.png.1a7e711d4374452265be30fb3683b87e.png

    This unassignment happens on every fixture I bring in that was built from the original builder, do I need to go back and update all my files?

    Cheers!

    MattG

  10. Agreed on all of the above, but, one would hope that as manufacturers build their approved files that this is done is the testing phase before being uploaded to ensure accuracy, especially when there's fixtures that "home" 90deg off axis to the base aka ayrton magic series. 

  11. Hey JWeston,

    There's different ways to notate a position tag but it really depends on if the fixture is tested in real world against the 3D model to ensure that the position tag is correct. To have a reference point, one could easily use a cube object adjust the sizing and child it under the "Base" and then the yoke Axis can then be childed under that position tag and so on and so forth for the rest of the model buildout. If users are creating 3D models and importing them, then they would just have it all in the same model I would think.

    Did this help?

    Cheers!

    MattG

  12. Hey Dan!

    Yea, however it makes sense on the dev side of things works, just some sort of way to where we don't have to make say 10x "changes" when it's globally 1x change overall applied to the same set of channels. Kind of like a "commit to others" sort to say

×
×
  • 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.