Jump to content


Vectorworks, Inc Employee
  • Posts

  • Joined

  • Last visited


137 Spectacular


Personal Information

  • Location
    United States

Recent Profile Visitors

1,685 profile views
  1. So, just an update on this: Just a few lighting devices in Vision leverage a concept called a Lightmap. This is something entirely in the backend and something that is not seen or editable by the end user. Anytime that a Lightmap is present, Vision ignores the Color Temperature field and uses the Lightmap image instead. Part of the issue being reported is that Vision was not making it clear to the end user that this was the case. The Color Temperature was filled out with a value that didn't really make sense and it was editable when it should not have been. The solution is in Vision's code base we need to handle populating the Color Temperature field as read-only when a Lightmap is present. This way, it is clear the field cannot be modified as it will have no effect. So, @DBLD, the solution to your problem is to use a different fixture / fixture mode. If one does not exist that does the Color Temperature stuff you need, you can request it through the Fixture Request form for Vision. I'd have to check with our content team, but in theory, we could provide a molefay that does not use a lightmap and therefore would have an editable Color Temperature field that would allow you to set it to whatever you want.
  2. Note: I made a small change to the guide. In the past, I suggested that Image be selected for Transparency shader if you want to send this to Vision. This did work with Vision well, but it caused issues in VW. Now, you should use Image Mask for the Transparency shader. This allows both VW and Vision to render properly.
  3. A new "cut" of Vision 2021 SP4 was just released. This includes the hotfix for the MA3Net error.
  4. Ahhh, I just heard back and this is indeed a known reproducible issue with SP4. We are working on getting a fix out ASAP. For the time being, use another DMX Provider or if you can fall back to SP3. It's always hard to predict how quickly/easily something can be fixed, but I'm hopefully that this will be resolved sooner than later 😉
  5. I'm not aware of any significant changes to the MA3Net stuff in the SP4 release. Did this work for you in SP3? Either way, this is the first report I'm hearing of this and I will make sure that the MA3Net developer gets this report. Seems like this should be an easy one to reproduce!
  6. DM me the file just in case it is something obvious. What we have found is that this issue is very difficult to reproduce and has been very difficult to find in code as a result. Steps to reproduce, while difficult, are usually the silver bullet for getting problems solved quickly.
  7. If you have access to JIRA, you should file it there. The advantage of having this access (which is restricted to BETA users I believe) is you kind of get updates on the report and will see when it has been resolved and at what build number. Otherwise, I'll make a note to open a report in JIRA myself; one that references this forum post. It's not clear to me yet whether or not this is an issue in code or in content. Content issues can be fixed "mid-release". Code issues require a Service Pack. We'll try to take a look sooner than later!
  8. FYI, if you have a LOT of fixtures, sometimes turning Render Fixtures to Off instead of Black can help performance (it reduces vert / poly count in the scene essentially by "skipping" fixture geometry). Also, if you have the time to render a movie out with pre-recorded DMX, setting Render Fixtures to On can give a much more realistic look (one where one fixture can hit another fixture with light and that fixture will reflect like properly instead of just rendering black). Food for thought! Glad you found the setting you needed to adjust 😉
  9. I'll let the team know. It seems to usually be tied to those "dual monitor" setups. Quick question, what resolution are your two monitors running at? Are both monitors "horizontal" or have you physically rotated one to be "tall"? Do you know if these monitors are HighDPI or not? If so, do you know what scale is being used (usually 0.5, 1.0, 2.0)? Thanks!
  10. There was a bug introduced into MVR export at some point. Anytime Transparency shader had an image or image mask, it would use that as the main color image. This was evidenced by the images that got exported, as you've discovered! Very detailed report, much appreciated! This bug was fixed in VW2021 SP4. It should be available now! See if that takes care of things for you 😉
  11. I had seen this post and am not 💯 certain what is going on. There is a lot involved in your workflow, but you did a fantastic job detailing all of it and it appears as though you did a fantastic job of ensuring that everything was accurate down to the pixel. I did have some comments I was "holding on to" because I didn't want it to appear as though I was simply not addressing the issue. I was hoping to be able to find time to investigate with the entire VW Vision team and come back with something definitive. One comment was related to the text above. If you are scaling the image in VW in such a way that Vision does not pick up on the change, then we should try to find a different way to scale the image. One such way is by editing the Renderworks Texture directly. There are probably many other ways. We will need to investigate this more as ideally everything would work regardless of "how" you scale an image. Another comment was that "Capture Source Name" is entirely ignored at export time. This is why you don't notice it in Vision. I believe this was put/kept here mainly to leave yourself notes in the VWX document. However, the "Capture Source Number" will come over to Vision as "1.cap", "2.cap", "13.cap", "52342.cap"; whatever number you put in there will be used as a unique integer identifier in Vision for "Video Inputs" (which can be NDI or UVC). One of my last comments was related to 1920x1080 vs 640x360 NDI Streams. In our research, most users are not cropping NDI Streams and most NDI Streams are not so highly detailed and so large in the scene (as viewed on your desktop/laptop monitor) so as to require 1920x1080. NDI supports high and low bandwidth modes and for a realtime vizualizer low bandwidth is preferable for performance reasons. This is why low bandwidth is the default and likely why you are ending up with a 1920x1080 source stream ending up in Vision as 640x360. If you would prefer the source resolution to appear in Vision, simply select the High Bandwidth radio button underneath the NDI live preview. Because you are cropping and doing other very detailed things, I think this is a perfect example of where High Bandwidth is indeed acceptable. Again, in most cases, you should use Low Bandwidth if you can. I've not had issues with sending multiple NDI streams to Vision. However, it may not be as evident that only Vision Unlimited license allows for more than a single NDI stream. All in all, I'm not sure that any of this will resolve your issue. Users may find it informative at the very least. My hope is that this is merely us not having accounted for some workflow and that another workflow/workaround would allow things to proceed. But it is very possible there is just some issue/deficit in the core code when handling these kinds of things. It might take some time, but I am hoping we will be able to figure this out in the long run and ensure that we support this workflow moving forward.
  12. That is unfortunate. If we could find the steps to reproduce the issue in-house, we may be able to more easily find the issue in code. 😂 Yea... I believe that on OSX a force quit will always trigger the safe mode dialog on next start. However, WIndows Task Manager and End Task does not seem to accomplish quite the same thing. There is not. However, I think we are getting to a point where it makes sense to expose a "force safe mode on next boot" button in the Vision Application Preferences. Depending on how things end up working out in code, this may be able to be a "clear all user settings" button (more similar to VW). Any information you can provide for reproduction would be ideal. I'll see if I can get QA to take a look. In the meantime, I can at the very least start proposing that we expose safe mode / clearing user settings in a more user friendly fashion 😉
  13. So, after digging in the code, it appears that this issue was introduced in Vectorworks 2021 SP0 (or maybe SP1). The issue is specific to 3DS Exports (which MVR Exports leverage) and is not specific to image props. I could reproduce the issue with extrudes just the same. I'm making a push to get this fix submitted to Vectorworks 2021 SP4. This will allow Image and Image Mask Transparency Shaders to be exported to 3DS/MVR properly; and it will not "step on" the main color image. Again, my apologies for the regression. I hope we can resolve it quickly so you can get back to sending Full HQ Textures out of VW and into MVR!
  14. @ajpen, I'm glad this guide has helped! I do apologize, however, as it appears you have found a regression of which I cannot find an easy workaround. I'm going to dig down into the 3DS exporter in Vectorworks and see if I can figure out what is going on. Hopefully, I can find a solution quickly and we can try and get the resolution out in a Service Pack. Thank you for your thorough report and diagnosis. If you have any other questions related to how to leverage textures in VW for export to programs like Vision, please let us know! It seems you've already come up with the idea of using a bump on an image prop, which I had never considered. Cool idea! Cuts down drastically on vertex counts and keeps a decent level of realism. FWIW, the only true workaround I could find was to simply not use transparency (or remove it before export, which would be a pain). Once the MVR is opened in Vision, you could then apply the transparency masks there. Huge pain, but it does work. Again, my apologies and we'll work to resolve this quickly.
  15. If the UI is allowing you to change the UI, then it should take effect. There may be a bug in either detecting whether or not the color temp field should be "editable". There may be a bug in the handling of color temperature. My suggestion would be to play around with a fixture whose color temperature is clearly working; such as a S4 19deg. I posted somewhere in these forums recently about color temperatures. Some users seem to think there isn't enough difference between, say, 3200K and 6000K; other users think the difference is not enough. If you can find some time to play around with a known working fixture (in regards to color temp) you should see that 6000K is fairly "white" and 3200K is more "amber". Vision does not yet have a white balance setting. If the S4 19deg is working as you expect, I'd go back and test the molefay one more time. If you still believe there is a bug or issue with the content, report back and kick off tickets to the appropriate parties.
  • Create New...