bbudzon

Currently, Vision only supports the VW Projectors that act more like a screen area. It cannot actually cast / project a video from a projector. This has been coming up more and more, recently. I think our content team even played around with trying to hack something up with our current capabilities by leveraging a video/ndi texture placed into a lighting device gobo wheel. I cannot remember how well this worked. Because this has come up on more than a few occasions in the recent past, we've already started some discussions internally about how we may go about supporting this in a future version. I am curious... Is your workflow simple enough that you just want to be able to cast projector video into the scene and that is all you're looking to accomplish? Or, is you workflow more complex and closer to something like projection mapping?

I cannot provide an estimate on this feature as it is a company wide decision that requires collecting a lot of feedback and working with various departments within Vectorworks. But, we do greatly value your workflow and suggestions and I will be sure to bring this up in our future task and enhancement discussions!

Unfortunately, Vision does not support various units of measurement and is always in inches. It is obviously possible, and often recommended, that all modeling be done in Vectorworks where meters can be specified. But, I understand this doesn't always fit the work flow. That being said, we value feedback like this from our users as it allows us to gauge and set priorities for future tasks and development!

Ahh, my apologies! I didn't realize you were aware of the RGB Meshes as a lot of users do not know they exist. Unfortunately, when it comes to casting light onto surfaces and/or having beams, Vision really only supports spotlights. What you're looking for is something more along the lines of a point light that can emit light in all directions. While we do not support this currently, it is something that has not really come up in the past. So, now that you've hit a use case we do not handle, I think we can investigate internally what it would take to handle implementing something like that. In the meantime, RGB Meshes may be your best bet.

One way you can do this is to model the cylinders in VW as plain cylinders. When you send this over to Vision, you can flag the cylinder as an RGB Emissive Mesh so that it acts as an RGB light (one that does not cast light but simply "glows" in the dark). If you set the candela high enough, it will trigger the Bloom effect in Vision giving it more of a "glow" that bleeds off of the object making it appear to emit light. Because this kind of mesh does not cast real light and merely glows, this is very friendly on performance while still providing the desired look. Don't forget that you can leverage multiple selections in Vision to assign the Emissive properties to multiple cylinders at the same time. This will drastically cut down on the amount of clicks you need to make after sending the scene from VW to Vision.

@neurain, I'll double down on @TomWhiteLight's request. I inserted all 4 variants of the Sceptron 10 1000 into a blank document in Vision and I'm able to select these lights without crashing. Perhaps, this is somehow tied to your file. If you could post it, we might be able to debug the issue further. Thanks!

Renderworks uses a complex rendering technology that does allow for things like light bounce. This is also why it can take anywhere from 10 seconds to 5+ minutes to render a single image. This style of rendering isn't very well suited for the kind of "real time" rendering that previz solutions provide, such as Vision, which often needs to be rendering 30 times per second. That being said, there may be some things you are not aware of. For starters, if your machine is beefy enough, go into the Vision Preferences (not Document Preferences) and drag the Performance/Quality slider all the way up to Quality. You can't get things like light bounce with Vision by doing this, but it will give you better looking haze, gobos, and shadows. This level on the quality slider also enables all texturing capabilities; reflectivity/specular images, bump images, and normal images. Which leads me to my next point. Check out the HQ Textures guide we posted for going from VW to Vision. It has some really useful tips for getting the most out of Vision from a quality and performance standpoint. Again, you can't get things like light bounce with Vision. If you are looking for this level of quality you might be better suited to leverage VW to the best of its ability. However, with good textures and the right settings, you can get some pretty impressive renderings in Vision even without the light bounce. Here are some random stills I had lying around that were rendered by Vision that showcase some of the higher quality textures and render settings. I hope this helps!

You may find this link helpful: https://app-help.vectorworks.net/2022/Vision/2022_Vision/Vision/Saving_the_scene_as_a_movie.htm Essentially, you should run through the show with live DMX going to Vision and record it with Vision's DMX Recorder. You can then play this recording back in Vision with the live DMX stopped to see how things are looking. Once you are happy with the DMX Recording, you can use this to render a movie out of Vision to the hard drive. Hope this helps!

Yup! Looked into it, found the problem pretty quickly, and the solution seemed fairly straight forward 😄 The fix tested well on my machine and our internal QA department verified the resolution. This problem should be fixed in Vision 2023. 😉

So, this is such a silly issue. But, the problem is actually that one of the texture resources in your VWX starts with a `*`. Particularly, `*7`. We obviously need to fix Vision so it doesn't crash in this scenario and still works as you'd expect. But, for now, I would suggest avoiding starting any texture resource in VW with a `*`. I apologize for this issue and tried to respond as soon as I had time to investigate. I hope this helps!

Hey! Vision should have no problems with symbols or nested symbols. But, you are still having issues and so there are a few things we might be able to do to "work around" this while we investigate things internally to try to reproduce this crash and hopefully find a fix. For starters, there are two main ways to get a file from VW to Vision. The first involves the Send to Vision commands which automates a lot of the work for you. It is possible that this is causing issues. So, I would recommend that while we work through this issue you stick with the second method. This method involves using the Export menu commands directly, which will save the file somewhere on disk such as the Desktop. Once the file is exported, you can then Open it with Vision or Merge it if you'd like to pull it into an existing Vision document. I'd recommend sticking with the Open command in Vision rather than Merge until we figure out what is going on with the crashing. The next thing I'd like to discuss are the two main file formats we use for sending data from Vectorworks to Vision and the variations of those file formats. By default, and our general recommendation, the MVR file format will be used. The MVR file format has 2 variants. The one we use by default and again recommend is the glTF-backed MVR. If you are having issues with this variant of MVR, I would suggest trying the older but more stable variant which leverages 3DS. To export a 3DS-backed MVR, you simply need to click the checkbox for 3DS during the MVR export. If you are having issues with both glTF and 3DS backed MVRs, there is one other file format we can try in order to get you on the ground running. This file format is very old and limited in its feature set. But, it is the first and original file format used to transfer data from VW to Vision. That is ESC. There are not really any options for ESC exports. It just sort of happens 😛 And ESC was created before GDTF. So, it will not work with those types of fixtures if you are using them. That being said, ESC takes a radically different path through the code base in both VW and Vision and so we might "luck out" by getting your file to import this way. Hopefully that all makes sense! We'll take a look at the file you've posted in-house and see if we can reproduce any issues. From there, we'll investigate things and try to report back our findings! Thank you for your patience and hopefully one of the above suggestions works for you.

After looking into the code history, it appears that this somehow regressed when merging in a feature branch for a SP. The code seems to now always fail thinking that it is not connected to the internet when indeed it is. We're investigating things internally and trying to determine the best path moving forward.

@marveln22 Just to reiterate what @klinzey said, if this is a question about Vectorworks we should move this into a more appropriate forum for you to get help. If this question is about Vision, I may be able to help. It is true that Vision doesn't quite support true mirror surfaces. But, I think people are often surprised by what can be achieved with Vision when you leverage all of its features. For example, I was able to whip this up in just a few minutes. One example is much choppier water. The other is a little less "wavy" and you can better see the environment reflections of the mountain in the background. If you remove the normal map entirely such that the water is "perfectly flat", it kind of stops looking like water. But, the environment reflections become more evident this way.

This is definitely quite odd and a new one for me! Haven't seen this before. My only hope is that restoring document and application defaults will magically fix this issue. Perhaps, these somehow got messed up. Once you have your file loaded, open the Document Preferences dialog and in the Settings dropdown, select <Default>. Click Ok. Then, open the Vision Preferences dialog. This dialog has a slider in the top right corner for performance and quality. Again, in the Settings dropdown, select <Default>. Click Ok. Make sure you've recalled default settings for both document and application settings and then adjust the Ambient Intensity to 100 again. Hopefully this works. One other thing that might be interesting to see is setting a background color. If somehow all of your geometry is coming over "jet black", then having a background color will make this more obvious. The background color can be set in the document preferences dialog. Once a background color is set, adjusting the ambient intensity and seeing how the background color responds may give us a clue as to what is happening. Lastly, we might need to work on reproducing the issue here at the office to determine how best to proceed. It would be helpful to know if this is an issue with all files (VSN/V3S/ESC/MVR), only MVR files, or perhaps even just this one specific MVR file if other MVR files ambient lighting works just fine. The more information you might be able to provide on how to recreate this scenario the better. Also, if you don't mind, posting your VWX and MVR that is causing you issues might help us figure out what is going on. Sorry you're experiencing this issue! Hopefully, we'll be able to get it resolved.

I forgot to post an update 😛 Vision 2022 SP3.1 should have a fix for rendering stills so that you do not need to disable PSN to get it to work 😄

What version of VW was this MVR exported from? What version of Vision was this imported into? If you are running VW 2022 SP3, you should ensure you are also running Vision 2022 SP3. If you are running these releases and still having issues, you may consider checking the 3DS checkbox at MVR export time in VW. This should use the 3DS backend, rather than the new default glTF backend for MVR.

Thank you for your kindness 🙂 And I'm glad disabling PSN worked! Now, if I can just figure out why 😛 Most of the PSN code has very little relation to realtime rendering code, let alone rendering stills. At least we've narrowed it down to a single change. So, there is much less code now to investigate. I'll try to keep this thread updated as I discover more information.

Sorry all, I had an emergency and was out all of last week visiting family. I do think I've narrowed down what change caused the issue, but it is still not clear why. I hope my continued investigations will turn something up. I do have one suggestion though that seemed to work for me in my tests. If anyone experiencing this render still issue could try this workaround and report their results that would be great. The possible workaround involves disabling PSN. To do this, open the Vision Application Preferences dialog, go to the Session tab, and uncheck the Enable PSN checkbox. Click OK on the dialog and you should be good to go. I did not need to restart Vision or reload the file to get the Render Still to work properly.

Due to technical limitations, GDTF devices will not appear in the patch window. Only Vision's native content will appear in this window. GDTFs should be patched on the VW side, and then you can leverage the MVR "update existing objects" mechanism to pull this new patch in.

Essentially, yes! You pretty much hit the nail on the head with "stitching together". I think another easy way to explain it (as there are so many VW users) is the little squares you get when rendering with Final Quality Renderworks. I'm not sure what the proper terminology is here, but I like to think of each "little square" as a bucket. Once all of the buckets are full, you can "stitch them together" to create your final image. We support this "bucketing feature" with rendered movies as well, although all of my testing so far has been focused on stills. One thing that is somewhat misunderstood is the viewport resolution. This is really more of a "capped resolution" rather than the resolution we render at. So, for example, if your viewport is only occupying 600x500 pixels on your monitor, then there is no need to render 1280x720 pixels (unless you want supersampling/multisampling); doing so would just waste performance. If, however, your viewport is occupying 2000x1500 pixels on your monitor, then we use the 1280x720 as a "cap" of sorts to avoid having a negative impact on performance by rendering the viewport at a higher resolution than was requested. The reason I bring all of this up is because I am trying some odd things in my own tests: - changing the viewport size on my monitor by resizing the windows/palettes; tall/skinny, short/fat, square, etc - forcing the viewport size to match my monitor resolution by entering fullscreen - changing the Resolution Quality setting in Vision's application preferences - changing the image output resolution setting in Vision's render still dialog - changing the image output settings to use various Render Buffers Sizes The reason I believe this may not be tied to bucketing but rather resolution somehow (the truth is the two kind of go hand in hand) is that you can essentially "disable" bucketing by ensuring there is exactly one bucket. My monitor is 1920x1200. So, if I set my Resolution Quality to 1920x1200, enter fullscreen, render a still with "<Active Settings>" and an output resolution of 1920x1200, then only one "bucket" is needed. So, there is no "stitching" in this case. Yet, I still end up with broken stills. In fact, more geometry was missing in this case than in other tests where only the top left corner of the render was missing. It's like the first bucket always fails maybe but all subsequent ones succeed or something? This is odd because when stitching does not occur, this is the simplest case and generally speaking it should always succeed as it's basically just pasting the viewport into an image file on disk... Just to reiterate, even when playing around with all of these settings/configurations, I cannot seem to get 2022 SP0 to "break". It always renders the still as I'd expect. So, I can confirm your report. While I can sometimes get 2022 SP3 to "work", it is very finicky and difficult to reproduce. It seems more often than not, the rendered still is broken and I can't find a rhyme or reason as to what is causing it just yet. We'll continue to investigate this and see what we can determine. Because it has been so finicky and it is hard to determine from testing what might be causing this, we might be best suited to look at every change to the code between SP2 and SP3 and try to find/fix the bug that way. I'll try to provide an update here once we have something definitive to report. Thanks for catching this issue and my apologies for the inconvenience!

I'm trying to dig deeper into this issue. I happened to have an SP0 and SP3 build on my machine and so I've been testing with those. I can reproduce this issue in SP3 but not SP0; which is odd because as far as I'm aware none of this render still code changed with SP3. One thing that does seem to have an effect on this is resolution (viewport and/or still resolution). I thought it may be related to the "bucketing" feature of stills, but I'm no longer confident that is the case. I'm investigating and hope we can turn something up.

Hey! Sorry for the late response. So, there's a few things going on here. In my own tests, almost everything is working properly and I think there are just some misunderstandings. There was one bug I found when running through the MVR texture workflow, which can be worked around. I will cover the bug at the end. The 3DS file format supports bump images. The glTF format does not; instead preferring normal map images. The 3DS file format also supports independent alpha images. The glTF format does not; instead preferring the alpha be "baked" into the primary color image's alpha channel. One thing to note for anyone else reading this who is not aware, both 3DS and glTF may require higher Texture Quality settings in Vision to render all textures properly. Lower Texture Quality settings may ignore certain texture images in order to gain better performance. The easier case to talk about in regards to this post is the Bump Shader. When VW performs an export of a Renderworks Texture whose Bump Shader is set to Image, VW converts this bump image to a normal map programmatically. So, when importing a glTF or a glTF-backed MVR into Vision, you should see a Normal Texture instead of a Bump Texture. This is different than 3DS, by glTF/Khronos Group design. But, the result and functionality should be nearly identical and performance may increase as normal maps generally are more performant than bump/parallax/displacement maps. If/When glTF adds support for bump/parallax/displacement images, we can investigate adding this support to our glTF code in VW and Vision. In regards to the Transparency Shader, there is something I want to reinforce as we taught "bad practices" in the past. If you read the "Preparing High-Quality Textures in Vectorworks for Export to Vision 2021" forum post/guide linked at the end of this comment, you will notice that on July 8th of 2021 we edited the guide. This was to correct an error with our suggestion for Transparency Shaders. It used to suggest that you use Image for this shader, but this is bad for performance and rendering quality in VW. What should really be used is Image Mask. The guide was updated a little while ago to demonstrate this. While 3DS will technically export either Image or Image Mask, glTF will now only export Image Mask. This was a requirement of the glTF exporter for technical reasons, mostly involving the number of channels allowed in an image. With that caveat out of the way, when VW performs an export of a Renderworks Texture whose Transparency Shader is set to Image Mask, VW "bakes" this grayscale image into the alpha channel of the primary color image. We tried to do this in an intelligent way such that if the Color Shader is set to Plain, it will still generate a proper glTF image at export time. When importing a glTF or a glTF-backed MVR into Vision, you will no longer see an Alpha Texture as this will always be baked into the main/primary color texture. This is different than 3DS, by glTF/Khronos Group design. But, the result and functionality should be completely identical and also may result in better performance by reducing the total number of images required for rendering. If/When glTF adds support for independent alpha images, we can investigate adding this support to our glTF code in VW and Vision. Now, I said there was one bug I found when testing all of this earlier. The bug is that Vision, for some reason, is not automatically checking the "Use Alpha Channel" checkbox for meshes when importing glTF and glTF-backed MVR files. This is causing the alpha mask effect to not render properly even though all of the necessary data is present. The workaround is fairly simple; select all meshes necessary, using multiple selection if needed, and check the Use Alpha Channel checkbox. This will save into the VSN and should only need to be performed after the import. We are investigating the cause of this issue and hope to have a fix sooner than later. I apologize for this inconvenience.

My apologies as it appears this is a bug with the way GDTF's are read/written to VSN/V3S. I was able to reproduce this issue, which is good as it means we can investigate it easily in-house. I'll open a ticket internally and hand things over to our GDTF engineer so they can determine the cause. In the meantime, if we do happen to have a Vision-native litfile for this device you may consider using that instead as the Force Emissive flag does seem to be working for non-GDTF devices.

Not sure how much help I'll be, but I can try to clarify some things at least and try to get you going in the right direction! So, the Qt version that we are using (as you point out) is Qt 5.12.10. When you look at a Windows build of VW/Vision, you will notice that the Qt header files are not included. This is mostly because they are not necessary at runtime and no additional work needs to be done to avoid including these headers. So, in order to build against the appropriate Qt version on Windows, you can follow the same steps we do internally. Simply download Qt 5.12.10 for Windows off of the Qt website and install this. The installation will provide you with both the libraries and header files necessary to compile/link. Since Windows is always Intel-only, there is no reason we cannot use the packages shipped directly by Qt. You also do not have to worry about some of the pathing stuff I will discuss below at runtime as all DLLs are assumed by windows to be "next to the exe". When you look at a MacOS build of VW/Vision, you will notice that the Qt frameworks are included in their entirety. On MacOS, a framework includes not only the library but the header files as well. This works out really well for you as a lot of work was put into preparing MacOS Qt Frameworks for Intel and M1. I haven't tested this. So, I could be wrong. But, I'd think that on MacOS you would be able to simply compile and link against the Qt frameworks we ship with VW/Vision. These frameworks include the headers which are necessary for compilation and the libraries which are necessary for linking. I can't see any reason why this wouldn't work, in theory. In practice is another story!! There is one last "requirement". But, this is a runtime requirement; not a compile-time / link-time requirement. MacOS must be able to locate all library dependencies at runtime so that they can be preloaded when launching the application. If you inspect the SpotlightVision plugin with otool, you will notice its runtime pathing is setup for Qt as "@executable_path/../../../Frameworks/Vision/QtCore.framework/Versions/5/QtCore" (for example). If you do not have this pathing setup correctly, then the plugin will fail to load at runtime due to missing dependencies. Again, none of this pathing would affect compilation or linking; only runtime. I hope this clarifies some things for you and I hope you get up and running without too many more issues!! I'll try to answer any questions you might have when I can find time.

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!