Jump to content


Vectorworks, Inc Employee
  • Posts

  • Joined

  • Last visited


147 Spectacular


Personal Information

  • Location
    United States

Recent Profile Visitors

2,195 profile views
  1. @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.
  2. 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.
  3. 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 😄
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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!
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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!
  14. 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.
  15. 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!
  • Create New...