Strange, but true...that the same file was read in different ways?!? I went ahead then and constructed the entire fixture in MA3, and it all rendered out well--using the same 3DS files that came in with the GDTF Import. I like the ChannelSet range entries in MA3, you only need to input the beginning of the range, the end is automagically configured. Although, it takes about 5 times longer to construct a fixture within the console--scrolling with a tab and mouse is...ugh. And if some entry fields are not edited, the console doesn't calculate the DMX and give the fixture a DMX footprint an

@petrvanek Glad to hear of an update! I'm curious, as MattG states above with regards to visualizations; what environment for visualizing do/are you utilizing? I ask because with the latest version of the builder...I'm using MA3 as a checker/visualizer since it is, without VW I believe, the only renderer of .GDTF files. I'm not suggesting that a visual upgrade is needed to the assembler[it's great!], I'm just wondering how these things are checked as the iterations roll out. The TakeAway from this: I took a newly generated GDTF file and Imported it into the current release of MA3 v1

I just checked; this is very easy to get visualizing...Patch 2 MovingPath Fixtures, then use MA3D to bring into the Scene/StageView your 'screen' model and your 'moving riser' model; you can use the Plane and Box Primitives as models from the MA3D database. In MA3D, simply DragNDrop your models onto each corresponding Moving Path fixture, easy-Mcpeasy. These MP fixtures are under now control of the desk/DMX...so can be written into lighting cues, etc. Are these moving objects on the stage actual automation under control of an operator/desk/console, or being manipulated by stagehands?

@helendeneb in MA2, what you describe is a MovingPath fixtureType. To get it visualizing as you describe[rotating screen-transforming box]; you'll need to do some editing to the profile...and perhaps some custom models as well, to get things really looking right.

Saying you used 'default' visualizations...then. Well...again, I would have to venture a guess that it is the end user platform[Visualizer--VW--you don't diagram your control config] not correctly reading how the file is structured....and it then becomes a question to those parties...Vectorworks, Vision, etc... I am working under this axiom: This site and the share site are being produced and maintained by those parties involved with pioneering the formats and thus; if things are visualizing here and not in the end of your workflow chain...well, the problems are lying somewher

When you constructed the fixture in the webBuilder...and when you Imported your 3DS files[if custom], did you see the model rendering in the builder? Did you use default fixture models? I'm gonna speculate that it's Vision and/or VW reading the MVR file incorrectly. The web builder references the 3DS files and packs them up in the MVR/suitcase/container, so, if you extract or unpack the MVR file you'll find the 3DS in a nested folder...seemingly just fine. I think Vision and/or VW is not finding the nested asset...within the MVR structure. Just my guess, though....since it is n

My solution: model and export in MM....only thing I've gotten to work in the Builder to compensate for this.

Currently, uploading is the only way to generate a copy of the GDTF file, it dupes the file, one for public Sharing...one for your 'desktop' or other location of storage. Upload to generate the file, then go to public Share site and delete your upload...heavy handed but the only way at the moment to get a 'hardcopy' of your work in the proper format. Good luck! NB: deleting in this manner 'should' keep your work somewhat proprietary and under your control. Once it's at 'Share', for any period of time...it's exposed to the General Public on the interWeb. Anyone can tak

Yes, I have observed the same thing in how the builder does not respect the Export's Size or Dimension. You need to build/EXPORT your 3DS files in MM instead of Meters[at least in my personal experience].....the builder seems to default to MM when bringing in a file, no matter how you check the boxes. I utilize Cinema4D for all my 3D modeling work. Doesn't matter how I 'freeze' the Transforms, the web builder has a mind of it's own with respect to Units used. Good luck! NB: I have done lot's of Conversion work before....drop me a PM and we'll chat about terms?!?

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 mo

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 a

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.