Jump to content

bbudzon

Vectorworks, Inc Employee
  • Posts

    521
  • Joined

  • Last visited

Reputation

143 Spectacular

4 Followers

Personal Information

  • Location
    United States

Recent Profile Visitors

1,993 profile views
  1. Thanks! This will ensure that not only will you be able to use this device as a native piece of litfile content, but also that future customers will be able to as well 🙂 I, unfortunately, do not. Given that the break is coming up, I will message them and give them a link to this topic to see what they can do priority wise. I apologize for the inconvenience and hope that we can get everything resolved for you quickly!
  2. So, I just received confirmation that framing/shaping/shutters are not currently implemented for GDTF devices in Vision. They are implemented for Vision's native litfile devices. We are working with our GDTF developer to work on getting this feature added to Vision's GDTF implementation. I will do my best to post updates here as they arise. The only "workaround" I can think of here is to issue a Vision Fixture Request for the Martin MAC Ultra. This will be added to our content teams queue of devices that need to be created, but will allow for you to use this device as a litfile rather than a GDTF where framing/shaping/shutters should work properly.
  3. I'm glad that information has helped 🙂 I also noticed you were on Vision 2021. I thought it might be worth mentioning a pretty cool new feature in Vision 2022, which is a Performance & Quality Slider in the Vision Application Preference dialog. This makes adjusting settings super easy, while still allowing an "advanced mode" that lets you tweak the settings to your individual needs. Lastly, we recently found some performance differences between Vision's native "litfile" devices and GDTF. We are hoping to resolve those GDTF issues which should help the performance of GDTF in Vision even further without degrading performance 😉 I hope you have a good rest of your day!
  4. So, it took me a while to figure out why you were running into issues with the file you DM'd me. At first, I could still not reproduce your issue. However, after revisiting your screenshots above, I realized this can only be reproduced when Dynamic Shadows Vision Application Preference is set to Objects & Fixtures. So, I can indeed reproduce the problem. And you are correct. It appears the fixture's own geometry is blocking part of the light. In theory, moving the light emitter in the GDTF Fixture Builder should've solved the problem. I will need to get the appropriate content creators and engineers to investigate this more closely. However, I would like to discuss Vision's Dynamic Shadows setting in a little more detail. It is probably the least understood setting in Vision and its effect on performance (and therefore quality) can be massive when shadows are enabled. If you truly need the Dynamic Shadows set to Objects & Fixtures in Vision, there may be nothing more to do than to continue playing around with the GDTF until it works. I do not think this is a bug in the rendering code as I believe other GDTFs work properly in this regard. I believe this bug is in the content (GDTF) itself. The file you DM'd me was quite detailed! It looks great! There are also a good number of lights in that file. I'd like to ensure you're getting the best performance and quality out of the product and that requires a bit of a balancing act. Increasing quality and enabling certain features has a negative impact on performance. And often increasing performance requires disabling features or lowering the quality. Setting Dynamic Shadows to Objects and not Objects & Fixtures will still allow your lights to interact with your set design; which seems to be your ultimate goal in having shadows enabled. All stage elements, curtains, character models, floors, walls, etc etc will cast shadows properly. So, unless you are really needing/using lighting devices as set pieces, I doubt that lighting devices casting shadows will be necessary. In my experience, most lamps won't cast light onto other lighting devices in any significant way, but there are exceptions (which is why the Objects & Fixtures option exists). The only drawback to using Objects and not Objects & Fixtures is that while objects will cast shadows, fixtures will not. One advantage of using Objects and not Objects & Fixtures is you will not run into issues with lights "blocking" their own light. But, I want to discuss the ramifications of Objects & Fixtures in a little more detail as well as I noticed that your Shadow Quality was set to Low. This was likely necessary because when you use Objects & Fixtures, any time a single lighting device pans or tilts, all shadows for all devices must be updated. This is incredibly expensive. So, using Shadow Quality Low would almost be required as you would be updating shadows so often that you'd need to do everything possible to make those updates "as fast as possible". When using Objects and not Objects & Fixtures, a single lighting device panning or tilting has no effect on shadows of other devices and so only that single lighting device needs a shadow update. By using Objects and not Objects & Fixtures, you could likely increase the Shadow Quality to Medium (or even higher) getting a better "look" and most likely better performance at the same time. And this will sidestep the issue of lights blocking themselves. It's honestly a win win win. Better quality, better performance, and a workaround to your issue. I hope this information helps. More often than not, setting Dynamic Shadows to Objects will get the job done and using Objects & Fixtures is not necessary as it has little to no difference in the final rendering. I'd highly recommend giving it a shot. In the event that you do need fixture shadows in the final rendering, you can try playing around with the GDTF more while we try to do the same internally. If I have any updates on that front, I will do my best to follow up and post them here!
  5. Ahh, I will work with the forum admins to see if we can add GDTF and VSN to the allowed uploadable formats 🙂 I ran the following test with your GDTFs and shadows off. Perhaps, this is why it is working for me and not for you. I tried enabling shadows, but ran into some bugs that I believe are specific to GDTF and not Vision's native litfiles. We generally recommend running with shadows off anyway, as this drastically improves performance. Public GDTF.mov Perhaps, you could upload your MVR file to the forums since that format is allowed? I might be able to better and more easily reproduce your issue if I have your precise MVR document.
  6. We have done a lot of internal testing running various offline editors with Vision on an M1 machine. Note that Vision 2022 SP2 was just released and has added support for running natively on M1. This is the release we did the most testing with. While various offline editors were used, it is my understanding that the GrandMA3 Offline Editor with the VizKey does not yet work on Monterey. So, please keep that in mind.
  7. That is an odd looking movie!! Not what I'd expect for sure 😛 Can you post the GDTF and/or the MVR file so I can take a look? I wonder if this is an issue with the fixture, the fixture's geometry, or the scene's geometry.
  8. @DBLD, In Vision 2021, there was an issue where a fixture using a "lightmap" in the backend would ignore the Color Temperature field even though it was editable. After further investigation, there were also some fixtures that didn't use a "lightmap" but would still ignore the Color Temperature field even though it was editable. In Vision 2022 SP0, I wrote a "quick fix" that disabled the Color Temperature field in some cases so it could not be edited. This made the UI a little more intuitive while I tried to work on a more proper fix for Vision 2022 SP2 as the changes were larger and riskier than I initially expected. With Vision 2022 SP2 now tested internally and released to the public, I wanted to share some updates. Vision 2022 SP2 reverts the "quick fix" that was shipped with Vision 2022 SP0; meaning the Color Temperature fields that were editable in Vision 2021 are now editable again in Vision 2022 SP2. I've updated the rendering code to account for the Color Temperature field being edited in all of the cases I could find or account for. So, editing this field should now work regardless of whether or not a "lightmap" is being used in the backend, whether or not "Force Emissive" is checked, and whether or not the fixture is an "emissive" fixture by default. In short, if the Color Temperature field is editable it should now always have an effect on the rendering when it is changed; including undo/redo/cut/copy/paste/drag'n'drop. If there are any cases where a device seems to completely ignore edits to the Color Temperature field, please post them here so we can work to resolve them. Note that if a device changes color when the Color Temperature field is edited, but the result is not what you expect, then this may be a different and independent issue from the one being discussed here. While this was a pretty concentrated fix regarding the Color Temperature field being completely ignored, I hope this still improves the experience and workflow in our product. Other issues related to "Color Temperature" but unrelated to "ignoring Color Temperature field edits" are still being investigated and we are working on definitive steps to reproduce as this is the first objective when debugging and sharing issues.
  9. Thanks for testing all of this out! It does seem like the scaling is causing issues and Qt (Vision's UI Framework) has been known to have issues with HighDPI in the past. I can't believe I didn't think of this myself, so shout out to Kevin 😛 All of your testing results make perfect sense. Most of us also run dual monitors at the VW office, so it being tied more to the DPI scaling is logical. I think the next step for us is working on reproducing this on a machine internally and then getting setup with a development environment where we can debug and try to fix the issue in code. Either way, based on your findings and my experience with HighDPI bugs in Vision in the past, I'm hopeful that we can get this resolved. Historically, Qt has some methods that don't take HighDPI into account. When there are alternative methods provided that do take HighDPI into account, we try to move towards those. But, in the event an alternative is not available they provide a "getter" that gives us the scaling percentage/ratio. So, often times, it's just a matter of doing some extra math in UI/dialogs/pixel related code. It's hard to say if we find a fix when it will ship, especially as SP2 is right around the corner. But, given the details in your report we should be able to bump this up in testing/coding priority 😉 I'll start working with the various departments to get a dual monitor HighDPI setup where we can debug the code and hopefully it will be a quick/easy fix!
  10. @ajemutt, @TomWhiteLight is correct that you can always assign these video inputs Vision-side if you would like. You should also know that if you are going to be using the LED Screen (or any other kind of screen/projector) in VW you can use the Edit Array Image (or Edit Screen Image) dialog to Select Vision Video Source. Once inside of the Select Vision Video Source dialog, you can select a Capture Device. The Capture Source Name is not really sent to Vision. It is mostly used VW side for organizational purposes. But, the Capture Source Number will identify the source uniquely in Vision. So, if 2 screens have Capture Source Number 1 and another screen has Capture Source Number 2, then when this file is sent to Vision you will be prompted for 2 sources; a source for Capture Source Number 1 and Capture Source Number 2. Capture Source Number 1 will be displayed on the first two screens in this example and Capture Source Number 2 will be displayed on the last screen in this example. Similarly, if you are just going to be using extrudes or any other custom geometry in VW, you can attach a special record to this geometry through the "Spotlight>Visualization>Select Vision Video Source>" as you have discovered. Simply select the Capture Device radio button and assign a Capture Source Number. Again, the Capture Source Name is not really sent to Vision. It is mostly used VW side for organizational purposes. But, the Capture Source Number will identify the source uniquely in Vision.
  11. Thank you for sharing this!! I'll start working with some of our teams internally to see if we can figure out what might be going on. Please provide us updates if/when you have them and I will try to do the same!
  12. Most of your ROOT/Global Document settings seem good! So, I don't think that is the issue. Digging deeper, I decided to run some more tests. In this test, all I did was open your V3S, select the S4 36deg group, and assign them a gel of 0, 0, 255 for full blue. This was the result: So, that seems correct and what I would expect! Perhaps, you can try this test and at least make sure this works. I started looking around in your document more and noticed a few lights that look like this: This screenshot has that "steel blue or medium lavender" color to it that you had in your original screenshot. Upon further investigation, it became evident that the colors assigned to these fixtures are the cause: I'm not sure if you just entered these RGB values incorrectly or if our stock content is incorrect. But, either way, adjusting some of these values should hopefully fix your issue. I'll work with our content teams to determine if our stock content has the correct RGB values.
  13. Hmm, that is odd! A quick test on my end and I cannot reproduce. It may be tied to some of the document settings. Perhaps, you can try recalling the defaults? If you can post your VSN that may be helpful as well.
  14. @DBLD, I thought I had responded to your initial post. I just reached out to our content guys to see if I should open a ticket, but one was already opened and lo and behold, I've been informed that the issue is resolved! I think we are still working on verifying the fix, but if you run a Library Update in Vision to pull down the latest litfiles and content, that should hopefully take care of your issues!
  15. It is my understanding that dpi only has an effect when printing the image. So, you should be good to make the image whatever dpi you'd like. To the best of my knowledge, only the resolution will have an impact on the renderer.
×
×
  • Create New...