bbudzon

I believe the ability to store the crop for every screen was added when NDI support was initially released for Vision. I just ran some quick tests against Vision 2021 SP1 and it seems to be behaving as I'd expect. I opened a test file I had lying around. Set one screen to the entire NDI stream (no crop). I set the other screen to a crop of the same NDI stream. I then positioned the camera such that both screens were easily viewable and saved the V3S. This is what my screen looked like before the save: As my NDI server was still sending NDI data, reopening the V3S in Vision resulted in the following dialog: Clicking Ok, the rendering was as I'd expect and the screens "automagically" picked up what video input they should be displaying: FWIW, if for any reason a video input cannot be found when opening a V3S, the following dialog should display: I got this dialog to spawn by closing my NDI server and loading the same V3S from above. As you can see, Vision has spawned a dialog stating that it is trying to connect to the video inputs mentioned (and it will keep trying to find them "automagically" until you click cancel). If I decide to not work with NDI/Crops for now, I can click cancel. Otherwise, starting my NDI server allows Vision to find the proper NDI stream and it's associated crop. This "search" is performed live and no action is needed on your part other than starting the server that sends the output. These video inputs are then applied to the proper meshes in the scene the get the renderings I've shown above. I hope this helps!

correct the builder is currently PC only Just to be clear, the GDTF Fixture Builder is available at https://fixturebuilder.gdtf-share.com/ for both OSX and PC. Accessing the fixture builder from inside of Vision does, indeed, only work from PC, however. EDIT: at the moment the MVR format doesn't support Spotlight focus points or focus information Also, focus points should work with MVR when going from VW to Vision so long as the version of Vision is 2020 SP2 or newer. There was a bug introduced in Vision 2019 SP3, that we were able to ship a fix for in 2020 SP2 😉

I've found the issue and the code and am working on getting it resolved. I'll try to post here when we are able to get the fix into a public release.

Any data assigned to the Gobo/Color/Animation Wheels tabs VW-side I would consider to be "custom data". This data only works with ESC, not MVR. If using GDTF with MVR, you can customize the GDTF using the GDTF Fixture Builder. Simply insert fixtures in VW using the insertion tool, assign ETC Source4 19 deg Fixture Mode, click Edit, click Color Wheels, assign a custom color, export ESC, open ESC in Vision, select Fixture, verify custom colors appear in Vision Properties Palette under Color Wheels section. I think you have the current workflow figured out. I thought that multiple selections worked with Gobo/Color/Animation Wheels, however I'd have to verify this as I vaguely remember this deficit being pointed out before.

So, in my tests, I was able to send an ESC to Vision and the colors came over as expected. I was, however, able to confirm that it seems like custom colors are not properly saving to V3S. Hopefully, we can get ESC's working for you and you can manage with those until we can investigate/fix the V3S issue. My apologies for the issues you're experiencing and my delay in response! Untitled.esc Untitled.vwx

Yes, my apologies. If no camera is present, Vision will not "violate" any privacy. However, when a camera is present, Vision must be given access to the camera. If it is not, Mac OS will see it does not have permission but is requesting it anyway. Mac sees this as a privacy concern and forces Vision to close. Glad you seemed to have gotten things up and running 😉

MVR, unfortunately, does not yet support transferring of custom gobo/color/animation data; whether using Vision's native fixture content (litfiles) or GDTF. If you want custom data in a GDTF, the GDTF Fixture Builder should be used to generate a new GDTF. However, I think you were on the right track with the use of ESC as the workflow is a little simpler. Let me just start by saying, I don't think you're doing anything wrong. It seems you're filling out the Fixture Mode properly, which allows you to properly assign custom colors Vectorworks-side as you have done. If this is not working, it seems like it is a bug and I can start to investigate. Similarly, it is odd that the focus is saving for your conventionals in Vision but not the colors. Using the V3S format is even harder to "screw up" from an end user standpoint, and should always "just work". It seems like this may also be a bug. I will look to reproduce and start investigations. We made some rounds of major reworkings for performance improvements with 2021. So, it may be that this is somehow a result of that. There may be a (fairly elaborate) workaround, if needed. But, my hope is that we can find out what is going on and either resolve things in the code or relay some information that should help resolve the issue. My apologies and I hope to be able to provide an update sooner than later!

Would you mind creating a DMX Recording in Vision 2020 where it works? If you attach that DMX Recording and the V3S to this topic, I might be able to look into it a little deeper 😉

As we've looked into it more and more, it seems SLI is going to be a thing of the past for nVidia. They are dropping support on almost all of their newer cards and the ones that do support it require code to handle it (whereas before the card handled SLI for the code). I have not yet heard back from our technology department on whether or not we have equipment to test. The last test we performed in house was on 2x1080Ti's, but one has died since. So, while I still cannot help much in regards to SLI, based on your post above you may find this helpful. Here is a list (in rough order) of application/document settings that impact performance in a significant way in 2021: Enable Shadows (shut this off for a big leap in performance) If you MUST have shadows on, consider turning them off globally by unchecking Enable Shadows and consider turning them on at a per mesh/layer level. Haze Texture Intensity; not to be confused with Haze Intensity (set this to 0% to disable 4D haze and get a big leap in performance) Haze Style (HQ 4D is usually best, but make sure you’re at half resolution and not full) Resolution Quality (esp when you are fullscreening Vision, setting this to something reasonable like 720p is ideal; the lowest value you can put up with is usually the sweet spot; I run 768x576) Haze Quality (the lowest value you can stand the better; I run 0.01 or 1%) High Precision (I recommend turning this OFF) Render Fixtures (I recommend setting this to OFF or Black)

It is my understanding that most applications do not need to concern themselves with if there is one or two graphics cards. This was evidenced by our tests back with Vision 2019, although I understand SLI and the way that it works may have changed in the last few years. So, I am hopeful that we can get Vision to leverage both of your graphics cards as this worked for us (without code changes) in the past. This is similar to how software need not concern itself with whether or not the hard drive for your system is a spinning disk drive or a solid state drive; the OS handles that for the application. Monitors are another good example of the OS handling things "for the application". I'm sorry that I don't have more information for you right now. I will work with our internal employees on trying to get a machine set up with 2 GPUs so we can figure out what is going on. Would you mind posting things like: - The full version of Windows you are running - The full version of the nVidia driver - The full version of the nVidia software - The full version of Vision Hopefully, with this information, we can try to reproduce your exact setup 😉 Edit: Sorry, was going back through the post and saw this, "nVidia driver version 452.06 and am on Windows 10". The other information would still be helpful 😄 Edit2: So, after some further research, SLI has changed quite a bit over the last few years. Some newer cards do not support SLI and some cards support SLI but only when the application is designed to handle it. From what I can tell, a GTX 1070 should support "auto-sli" without the application needing to handle it. But, we are still investigating and working on shuffling equipment around the company so we can run in-house tests.

Thanks for the detailed feedback! I think we may need to look into some things on our end. But, I did have one thing I wanted you to try / be aware of. I noticed that, based on your framerate, you are likely running with VSync on. VSync gives you the best quality renderings by avoiding things like screen tearing, which is only evident if the GPU updates and monitor updates are not "in sync". Generally, you should ALWAYS have VSync on. However, in this specific case, we are trying to profile and compare performance metrics. In this case, you need to "fully unlock" the Vision renderer by unchecking the "Enable VSync" checkbox in the Application Settings (Note: Vision must be restarted for this setting to take effect). What you should see, after this has been disabled, is framerates that are able to go above (in your case) 60fps. So, I do think SLI may have changed some since we last tested and we need to find a way to run these tests internally while working remotely in these times. And I thank you VERY MUCH for your detailed reporting. Odds are, if you are having this issue, someone else is as well! Hopefully, we can get this figured out 🙂 I'd definitely be interested in seeing your Vision screenshots again with Enable VSync unchecked, but I'm not sure how much it's going to help. FWIW, FurMark has VSync disabled by default as it's only purpose is to test performance (quality issues such as screen tearing are not a concern here).

Vision 2020 does have an FPS counter, but it may be going away soon. If you ensure that the "focus" of the application is in the Scene Graph Dock, you can press the 'o' key to get the FPS to popup. Note: If you press 'o' twice, you will get very detailed reports. This report is for debugging only and actually hurts performance. FWIW, my recommendation is to never trust any built-in FPS counter. How do you know it is being reported properly? What if there is a small mathematical bug? 😛 Anyway, reason I bring this up is I try to ALWAYS use a third party program to count FPS. Since you are on windows, I'd recommend FRAPS. There may be other alternatives, but FRAPS has worked well for me on PC in the past 😉

We'll have to check internally how this works again as it may have changed since we tried last. When I first ran my SLI test, I started with just one GPU in the machine. I ran FurMark and wrote down the FPS. I then ran Vision and wrote down the FPS. I then installed the second GPU and the SLI bridge. IIRC, SLI did have to be enabled on a per application basis inside of the nVidia Control Panel. I reran FurMark and it clearly was using SLI as the FPS was nearly double. This was also true of Vision. At the time, I do not remember seeing an SLI rendering mode or a Force alternate frame rendering option. Would you mind posting you nVidia driver version and what version of Windows you are on?

Sorry it took me so long to respond to this. I was able to reproduce the issue and I believe the problem is at export time in VW. I confirmed this by opening a blank document in VW and importing the MVR. The hang positions were still at the origin. I've opened a ticket in our reporting system. Hopefully we'll have something fixed soon!

Please make sure you are running the latest version. Rendering out 4K movies is not supported. The backend video codec we use does not support this and we did not realize it when we added the 4K option. This option should be removed in newer versions. We are working toward moving towards a video codec that will allow for higher resolution renderings. Please try rendering out a 1080p video and see if that is any better 😉

Good catch. I thought these were just extrudes! Very good catch again! Thanks very much for pointing this out as it is very important and I left it out of my comment. @mhersland Good luck and let us know if you have further questions! Texture/UV mapping is quite a large topic, but once you see it in action it all starts to make sense 😉

In your VW document, you have a color bar texture. You can see that it doesn't fill your mesh; rather it is being tiled. What you want to do is use the Attribute Mapping tool to "stretch" the color bar texture on each mesh such that no tiling is visible (ie; the textures align perfectly to the corners of the mesh). Vision will take your NDI frame and "pretend like it is the color bars in VW". So, this is why you are seeing the NDI frame tiled in Vision; because the color bars are tiled in VW. (Just to be clear, tiling is not the issue. The issue is that your texture does not properly "fill" the mesh the way it does in MadMapper.) I hope this helps!

From what I'm seeing, it appears the content for this fixture in Vision does not support this functionality. It shouldn't be too difficult to add to the content. And one benefit of content updates versus code updates is that content updates can be shipped at anytime (where as code updates must ship as a Service Pack). Perhaps, @Mark Eli can chime in.

Hey! Sorry I didn't respond to this sooner. When we render stills/movies, we perform "bucketing" to reduce VRAM use and allow for higher quality renderings. This is probably why you're seeing what you are seeing 😛 That being said, it is possible the movie rendering quality is still set too high. What settings are you using for your Rendered Movie? What settings are you using for your Real Time Render? Do still images export properly? Does a movie export work better if less lights are on?

I'm not sure I've heard this reported before. Perhaps, you could include a VWX that replicates the issue? This worked in Vision 2020 SP2, but a regression was introduced as a part of Vision 2020 SP3. Unfortunately, the developer was not able to get a fix shipped for SP4.

I find MVR to be the ideal workflow 😉 If you are new to Vision, you may not be familiar with the woes of the .ESC file format. However, I still think you might find this article helpful: That article may explain benefits of the MVR workflow you are not familiar with. But, there is always more to learn! If you are trying to eek out the best quality renderings in both VW and Vision, you may find this useful as well: I will note that this HQ Materials guide applies to Vision 2020, but will be receiving an update for the Vision 2021 release.

I'm glad you figured it out! I hadn't had time to look into the original post yet, but you've already solved it! A little explanation: The MVR specification/standard mandates that when writing an MVR all units of measure should be in millimeters. It is for this reason that millimeters is the default option at import time; this option should rarely be changed. To be frank, the only reason this option is still around is in the event some company starts writing MVR files "against the spec". We, as a company, did not want to have to tell customers, "Well... I guess you need to wait until Company X fixes their MVR Export before you can pull this into Vision." We felt it was much better to provide you this option at import time in the event that an MVR file was written out with incorrect units of measurement; as this would allow to read a file that you would not be able to otherwise. So, I apologize for the confusion! That Units in File import setting (specifically for MVR) should almost always be millimeters. The only reason the option is even present is for a "dooms day"-like scenario 😛

Well, I hope we can start figuring this stuff out! Maybe between the issues you're seeing in VW and the issues you're seeing in Vision we can nail it down.

60 fps is pretty darn good and what I expected in a blank document. Odds are, VSync is capping you at 60fps (VSync is actually really good to leave on). The point being, 60fps is MORE than fast enough to avoid "blocking" the UI. So, it seems the issue you are having with tools is unrelated to renderer performance (because again, 60fps is more than enough to avoid lagging or blocking the UI). I haven't seen your VW post, mind linking it?? FWIW, I do not think this is specific to OSX Catalina which you've confirmed with your other machine. I'd hate to have you wipe it, but if other programs are giving you issues as well it may be necessary.

The FPS thing can be tricky but I just confirmed and it is definitely in the 2020 release: Furthermore, you're still getting the preference dialogs confused. Let me try to clarify. The following two menu commands on OSX are both application preferences: If you want access to the dialog for document preferences, you must click this menu command: