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.

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 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!

I would venture to say that it's with the way in which the 3rd party software[Vision] reads the format. MA International is one of the leaders in this format development and I would lean towards what they are rendering as a way to validate the GDTF file you're using. If it visualizes in the web builder, if it visualizes in MA3, but doesn't visualize correctly in Vision....? H'mmmm...wonder who is odd man out? Good luck!

Visualization models for fixtures in the GDTF format need to be broken down into functioning parts for the system to digest how the fixture is constructed and functions with the Attributes as an object. This means that most 'movingHead' type fixtures will be comprised of at least 3 mesh groupings/objects. In the wiki, there are visual examples of this segmentation and how to construct a model for the system. https://gdtf-share.com/wiki/GDTF_File_Description is a rather long description of what a GDTF object is...and how to describe it to the machines; let's hope they don't self realize and revolt on us, dang you Skynet! is the image of the segmented model and Model Collect is the appropriate index for the tables. https://gdtf-share.com/wiki/GDTF_File_Description#Model_Collect Enjoy and good modeling! Rex

Worked great now, clean, no audio. Too bad about the pipeline--OBJ--3DS, 2 programs, reorient...ugh. C4D is fairly inexpensive for what it can deliver.... When I develop 3D fixtures; I usually have C4D open, an IDE for the .XML scripting open, and MA2 onPC/MA3D open....that's enough[4 open programs] on my desktop! Cheers! Rex

C4D has the Polygon Reduction tool....great set of Axis Tools as well, when you combine with Snap, FTW! I've already seen bloated models in the Share sites, the format does specify a max count on 3D objects...which you can adhere to and still maintain a respectable shape/model. To me, it's more the correct scale of parts in relation to each other that provide the detail, not gobs of polys/verts. I'm seeing some peddled on the interWeb that demonstrate that very shortcoming; poly bloat for the return in the render/visualizer.

Seems a database of ALL fixture's Home positions/vectors would be helpful[Carallon?? I know their data in MA sometimes is wonky]...was so much easier in the days of only 2 Moving Head fixture manufacturers, lol...I worked for both, lucky I was in my youth. Now, there are so many developers of 'moving' fixtures/devices; it's time consuming to keep all the possibilities updated--obtain manuals--shop loaner fixtures--etc... There doesn't seem to be too many ways to orientate a "base"[whip/arrow/REFERENCEpoint] in relation to the Yoke's vector of travel, if the yokes all must be instantiated in the X+ vector as a default for the rendering/visualization/assembly. I appreciate that type of standardization. I will check the full DMX travel range to input value as well. Some fixtures, with no data applied, Home to DMX0...then I apply DMX from 0-FULL and notate the directions of travel, again, not many options; either/or. I just wish all of this data actually came from the Manufacturers and was exposed in the manuals...

I would inquire at the MA3 site about rendering of attributes in their newest software...and 3D visualizing. Again, I have some doubts if all attributes currently visualize in MA3, yet.

Dependant upon visualizer...using MA3 in 3D window?? I have found it to not yet visualize some attributes...Iris may be another.

...or at least restrict in some way, the actual 'brands' of fixture files as opposed to a GENERIC heading or the more appropriate, USERonly moniker. In that way, only actual manufacturers can upload content for their brand names and everyone else can, if they choose, to dump into separate servers/locations?? Just a quick thought on the schema of things, looking a few steps ahead to avoid mis-steps/information, ...

I agree. Proprietary content was why I began deleting versions of things I had uploaded; especially[& immediately] when I found that assets I had created were being used in similar profiles not uploaded by myself, without permission. That must end...in my opinion. This had me wondering about the concept's current/intended protocol. I believe the intent was to have the actual manufacturers provide the stewardship of profiles for their proprietary equipment; yet in current phase and practice, this leads to anyone to be able to upload a branded device's profile for the entire webiSphere to manipulate. Cheers!

Magic...it's simply magic. All is fine today. After 3 days of attempting to pop the dialogs and getting nothing; all things are back to normal. I just opened the F12 Developer window at your suggestion and both DL and Open in Fixture Builder functioned as before. Thanks for the help! Love it when things that worked, don't...and then do work again after something, something....lol.

Yea....still no go, not a game breaker....just chalking it up to Win7 and Chrome and the need to update things...worked fine since inception and up to just a short time ago... Thanks! I appreciate the info, even allowing all popups[yikes!] doesn't allow the dialogs to pop-up. Of course did not do a full reboot after changing the preference.... All works fine in Win10 for me...

Must be Win7 and Chrome not supporting Flash[is the builder FLASH based?] anymore...in this machine[Win7 desktop] the buttons simply do nothing--click all you like; no dialogs appear on either Download button or the Open File in Fixture Builder. Rebooting fresh this morning did nothing to fix the issue with the web page buttons. Odd, because I can directly open the Fixture Builder page and it all works...go figure and note to Devs. I have control in another setup I own; Win10 laptop which works just fine. Leads me to believe it's time to rebuild this desktop machine to Win10 and a better graphix card...it's worked great for 5 years now, tad beyond it's 'expected' lifespan for a modern computing device. The video card crapped out just recently and that was a gentle nudge to git movin'...lol. Got it up and rendering[black screen of NOTHINGNESS is spooky] in no time with a substitute card, but...not the most modern, just got it up to GTX 1060. Thanks!

Ya...checked on the Win10 laptop and all works; loads the fixture builder from Share site and database of fixtures. Win7 lost already...oh, no!

Perhaps it's my OS[Win7] and browser; at the moment, I cannot get the Fixture Builder to link to the GDTF-Share library of fixtures?? The only browser that I use is Chrome, namely because I can't get any of the others to render the pages correctly.... I browse the database of fixtures and try to open them with the Fixture Builder button, but no go, nothing happens. Can't seem to download any files either?? I can go to the actual builder web page and view files there... Firefox comes closest to rendering any GDTF page but won't populate the database page with fixture files, 'No Files Found!' prompt there..[Flash based viewer??], IE does the worst at any of the web pages associated with GDTF[and others, lol]. Did WIn7 crap out that fast after support ending...?!! I know Flash isn't supported by Chrome any further.

@petrvanek ...and it is taken for schema that any/every Yoke should be positioned along the X axis and thus orientate your Pigtail position[on the Base] according in regards to realWorld fixture default behavior. Is that correct, petrvanek, as per the format requirements?

There is a Model 'type' that defines a fixture's 'whip'/power input cord.....called "Pigtail", under Geometry--Primitives--Pigtail. That should be enough? I doubt that there will be an Attribute for that however[Fixture Orientation??]...I could be wrong?!? Build your 3D models to real world fixture behavior, some Yokes are 90 degrees offset from 'Pigtail' position, some aren't. I know I always ask the Programmer how they prefer the fixtures positioned.

For me, the video stops at 5:22..?!?

re-defineArray(); re-defineMatrix(); re-definePatch(); ...something, something, lol.

Don't ColorForce series of fixtures have a Left--Right or Right--Left internal mode to 'swap' the 'patch' of the fixtures? Would that be an example of such a request?

For things to parent 'correctly' inside MA2 and render correctly, you may need some specific Geometry Helpers in your base model for things to offset in a visually correct way. Perhaps if you build the GDTF fixture as you do a MA2 fixture needing parenting, you'll get a more visual result/solution...haven't tried it yet; but it's something I've been postulating inside the ole 'hardhat',;), if you know what I mean...as I consider what renders in MA2/MA3 and how fixtures are constructed with regards to 'helpers'. GDTF would seemingly make strange modeling constructs unnecessary moving forward in how we describe 'fixtures' when they render... If your target is MA2, I'd write the file in 1.5 FixtureBuilder or in a MA2 emulation/onPC...beat the Christmas rush, as it were and I often say. 'Conversion' most often does not parse 100%. Until all console manufacturers get in line with the evolving GDTF; it's a matter of keeping the 2 things separate, as we did when using custom models and Multi-Instance fixtures between v3.1.2.5 and 3.2+ and adjust accordingly. M'eh, what ya gonna do?

I don't believe the MA2 reads the GDTF format so you could not use that '3D' symbol[lost on what you mean by that]; I could be wrong, I didn't install v3.8 of MA2. MA3[which I have loaded onto a machine], will read MA2 fixture profile files but I believe they need to be exported to MA3 format, not 100% certain of that. I do know that there is a new file type of the .XML we used to have in MA2, pxml. it is now...proprietary xml perhaps? Used to be XMLP, lol.... The same 3DS model representing the fixture; yes those do not change and it does follow along inside a nested folder within the GDTF file, but not for MA2 consumption. The models are the same; 3DS files, it's in how the MA engine reads them as a profile, that is how it will or won't render or load as a fixture. MA2 needs to read 3D assets out of it's proprietary gmamedia database format....still a 3DS model, but nested inside the database for MA2 to read and render.

I'd say, "NO", you cannot move the Root Object/Top Level Object away from World Origin. Give that Geometry/Model a Size of 0,0,0--Quick and dirty 'Gaming Hack' to have something needed within the Scene, without it rendering....placeholder for a 'Parent'....as long as it works; Rex doesn't care about semantics....or utilize the "Body"/Normal Geometry as a starting point. Alter the Size BEFORE you Parent the objects together[in Model Tab], ahem, or you may make the entire object non-rendering, Child/Leaf objects tend to follow their parent object in Scale,Position,Rotation...typical 3D 'math'...LOL, once they're parented/nested. Seems you'll always need a Root 'placeholder' Normal Geometry model/object to avoid the "Can not move/rotate Base object" prompt, as it's from which all the other dimensions are derived. Makes sense; need some sort of Zero Reference Point/COM.....to start things going.

DMX value choice always seems to jump back to Percentage? While trying to setup ChannelSets and FunctionSets for a GoboWheel, the ChannelSet DMX From/To columns always seem to default to % when you page away, always finding myself with jumping values, at %50 is hard to achieve with 8 bit 0-255 value range; I put 127, the UI switches to 49%. The value reverts back to %, even if I want to use straight 0-255 range. I enter a value in the columns to find it going Red, because of the range...I'm constantly 'out of range'/red with the switching value, either Percentage or 8-bit. Even the Channel set value range seems to jump to %, even though I want 8-Bit range[0-255]. This sometimes causes Slot 1 of a wheel FunctionSet to go Red because it hates the integer of "0"....does not compute to a valid % range.....takes filling out the entire set of Functions....and still stays red if I switch to 8-Bit readout.