Ya, seems Dim is always 'on'...no control of Attribute....and the shutter setup.Rex@LEDSpot90W_GDTF@Release_Candidate_2.zip Try this copy, seems to work in v1.4. Shutter may need some adjustment, but I could control it, I also noticed no emitter setup, but am unsure about the construct and where/when needed and for exactly what purpose? 3D? Beam still appears without it.
Good luck!
...perhaps store an empty cue to an executor and insert your macro commands in the CMD entry field of the cue??
Thank you, yes...."phystime=" controls the physical movement speed of the 3D object. I hope I didn't indicate it was somewhere in the 3D window settings; that wouldn't make sense as it would be global perhaps and affect all fixtures??
I think in MA3, this may be labeled 'Real Acceleration' and 'Real Fade'[sorry no snapshot of the UI]?? of DMX Modes, right after the "Physical From" and "Physical To". I'll manually insert that assignment 'phystime=' when editing .XML files, migrating them from MA2 as my editor/IDE. It's hard to tell how many MA3 3D attributes are actually visualizing in the 3D window, currently...
Also, the 3D visualization has an entry field for 'phystime=', this controls the 3D model's movement speed across it's range of motion; this value is to be matched for what the manual states as the speed of the movement. 'Most' Headmovers take ~1.0-1.5 seconds to travel the entire length of it's PAN/TILT attributes. Scanners take less...depends upon the fixture IRL.
Try adjusting that value[phystime=""] to match the 3D model/visualization to the IRL fixture you see and compare the results.
Good luck!
Rexy
GDTF is an easy way to setup a fixture...it's a shame there is not many ways to visualize the results anywhere.
When updating an onPC 4K node from a regressed version, do you need to update the node to each and every archived build incrementally; or could I jump from a factory install[@purchase] of v1.0 to the latest[v1.4] in a single update?
Thanks!
Is there a list of what currently renders in the 3D window with respect to fixture Attributes? I'm trying to check something I just wrote in GDTF and nothing seems to be rendering...?
It's Positional Attributes and simple XYZ rotations...??
Do you speak of 'positioning' a 3D object or 'controlling' a 3D object like the MovingPath of MA2?
My guess would be to give your 3D object's fixturetype virtual DMX attributes for XYZ_X, XYZ_Y,XYZ_Z Positioning and make the Geometry[3D model] an Axis?? Should be able to use encoders and insert values for cues once it has the Attributes? Here's a GDTF profile with a 3D model that has Positional Attributes of XYZ_X, XYZ_y, XYZ_Z set to Virtual DMX parameters, should move 30 meters each direction of 0 as limits. My MA3 machine is not presently booted, so I can't quickly check it; if there isn't a dedicated MA3 'Moving Path' fixture written for MA3, this may be the approach/solution...
Are you envisioning Truss with fixtures moving? or Talent Figures for blocking?? This is a human figure. I've got Trussing profiles as well, with a bit more 'Zazz' in them, lol...
Enjoy...model is fairly heavy asset with 7K+ vertices...NB!! Copyright 2021 RexHeavyIndustries
Yes, those are the steps for generating the database file for 3D models the MA2 utilizes for 3D visualization; it does not work in MA3, which is this forum and the OP's questions about MA3 and 3D models. They are a bit of horses of different colors, lol, so to speak...MA3D + MA2[across a network] and MA3, each can do 3D visualizations, they are very different systems now between MA2 and MA3.
Here is MA2 forum...
Models need to be part of a fixture type to be rendered, I believe. Getting the 3D geometry into the engine is the first part, the Import and storing in 3D Object Pool. Next you need to create a new Fixture Type, insert Geometries and link to the imported 3D geometry to place one in the 3D window.
It does seem a bit 'klunky' to have to associate a model to a fixture type to view it, but that is the paradigm and how everything is being organized for the console/engine to digest and keep track of. There are some nice tricks you can do with fixture types and models...without resorting to the ever expanding list of fixture types.
The manual goes over the details here:
1. https://help2.malighting.com/P…sert_fixture_types/en/1.4
Ya, once I went back over the model, I saw the doors, the hinges, the handles...all unnecessary details that bloat up a file very quickly. I would probably even go as far as only having a Mesh Group per Material...it might involve many 'differing' objects becoming part of a grouping, but it will even bring the size down. Several of your Mesh Groupings has subSets of polygons with Materials, further complicating the end result. The railings seemed to be separate groups, each with it's own Material, when they don't need to be.
Good job, that's quite some optimising for the first pass...
Oh, and as a habit, once a Scene is all finished with constructions, I grab all the vertices and 'weld' them together...optimise, or whatever scheme your CAD program utilizes to eliminate duplicated/overlapping vertices...any Materials should be 'one sided' with Front being the choice...that may keep the Export process from creating faces where you won't see them...thus need them, also helps let you know in your CAD program if the faces are facing the 'correct' way...to be seen/rendered.
I believe that you are on the right track, John. I took a look at the file and that strikes me as a place to start optimizing the shape.
1. I have never found MA3D to handle texture bitmaps applied to shapes well, this is where it chugs. To that end I use no bitmap textures when creating shapes/models for MA3D. I also use as few Materials as possible, which substitute as Bitmaps just fine, the only exception would be some sort of Alpha related transparency for a special effect or visualization. Not really needed for working the lights in the software...in the Stage View. Rendering out for promotional reasons or client cultivation, sure, art it up...
2. A very fine model, brother, my compliments! I did notice quite a bit of detail that, again, is not really needed when representing the fixtures in a 'working' situation, which you are experiencing at the moment. The bolt holes in the dimmer connector panel brackets in the grid generate a TON of extra faces that are chewing away at your system...these minute details, which will never be seen by the end user, are what can cause a bottleneck in the render pipeline.
I think your performance will definitely improve if you go back over the Scene and eliminate the UV mapping to the all of the shapes that have it, not really needed if you are just applying a simple color/diffuse Material for the visualization. If you want to keep the mesh/alpha .JPG...go ahead, I only saw the single bitmap embedded in the Scene, but be prepared to shed that from the environment if things still chug.
I'm gonna try a few things here, lot's of 'free time' on my hands, ahem, to see how small I could get a good representation of the venue for programming. Again, a great looking model!
Good luck!
PS: the soft goods as well can be causing rendering issues, with the many actual 3 dimensional folds you've included...they could in be visualized as flat panels the actual width, all those shadows, sure look nice, but bogs things down in the 3D Views...
PPS: here's a quick and very dirty optimised file back...all UV's removed, will kill your .JPG textured object's visualization but the file is now 1/2 the size it was...give it a try/evaluation. There is more that probably could be done, more mesh group/material optimizing...like grouping all similar shape[all the hang pipes, etc] using a similar material, these types of steps really do help by keeping things simple for the systems to digest...I even 'crunched' the vertices from over 200,000 down to like 30K...I think that MA3D does some 'unwelding' when reading the 3DS shapes/groups, as the size tends to bloat once Imported into the system and inspected.
7Mb is a fairly hefty chunk of data for a single 3DS model[Triangle/Polygon/Vertex count?]...could you possibly provide the file to evaluate? You can message me if you're reluctant to do so for proprietary concerns.
...always happy to help out.
It won't work in Dot2[v1.9], I checked on the Keywords used in that build and Camera is NOT one of them....so, no CMD exec's....
Good luck!
I don't believe so...calling from the Commandline in Dot2 for camera control does nothing, tosses a nice juicy Error#...so I'd say "no", from Dot2[v1.5].
Now, you can commandline camera control in MA2 onPC, however....with:
[Function] Camera [ID]....so as example "Select Camera 2"- gives the result of switching from current camera to Camera 2 in the Stage View. It picks the Camera from the List in the console as it's indexed.
...so you could create a Macro with that calling and it would activate camera switching when the Macro is run. It will even respect 'string' names of Cameras in the 3D menu/Cameras. So.... Select Camera "Front" will switch the current Camera rendering in Stage View to the Camera labeled, "Front" in MA3D 3D Objects Menu.
Good luck! Probably will have to 'move' the Camera Control object Patched in Dot2 around to achieve this effect, but in a cruder/not elegant way.
Unless the latest version of Dot2 that allows Macros to be written allows for the grabbing of the keywords...not installed here as not really using Dot2 any longer and don't expect any further updating to the software. I found far more flexibility in MA2/3 and an onPC node.
No, there is no method for repatching the Attributes of a fixture in Dot2...you CAN do this in MA2, MA3 however.
You will need to edit your .XML profile outside of the Dot2 environment to fix any issues with the profile. On PC version of MA2 will do this!
It is nearly impossible to troubleshoot a file/issue, when no file has been provided...
Good luck!
@davidalmars the file linked does not seem to be constructed correctly? Throws an error for the 'extended' mode because there is no 'extended' MODE?? Seems both extended and standard modes are defined with the 'standard' Mode, just doesn't seem correct. Actually there is no 'extended' mode and this may be the bug.
Try generating another 'mode' in the DMX section[so you now have 2 modes], define your 'extended' Geometries within that 'mode' and try rendering again....
Good luck! Stay healthy! Happy New Year!!!
Seems almost like Normals got flipped by VW when it wrote the MVR...making the 'front' the 'back' and vice verse on the 3DS files...from a 3D standpoint as to why 'shadows' are not being rendered.
I've witnessed VW 'strangeness' with regards to Normals and Exporting...doubling up, etc.
Good luck!
I bought an MA3 onPC node to move forward...glad I listened to some advice as I'd thought about a Dot2 product but was told that it would be more 'flexible' if I went MA3, I agree.
You need to edit your Instance Array and this fixture should work with individual control of Pan/Tilt as you desire. When Patched, the Fixture will have 4 subFixtures, where N=fixture#101 N.2+N.3+N.4+N.5. If you select the fixture 101.2, you are selecting the first Instance Head, if you select 101.3, it's the second subFixture, and so on.... The .1 subFixture is the 'main fixture', so if you select that, you're selecting ALL of the subFixtures.
All of your 'Head' instances have no Position Values in 3D space, so they all appear as a single fixture positioned at World Origin[0,0,0]. If you give each Instance in the array some mirroring X vector values[I'd suggest X= -.5,-.25,+.25,+.5] and when you Patch a New Fixture with these values, the render across the network should visualize the separate 4 Heads spread out across that range, plus a 5th instance, which is the visualization for the Main Module.
Good luck!
