bbudzon

That is unfortunate... let's try gathering some more information. Can you launch Vision to an empty file, click into the Scene Graph Dock and press the 'o' key once. This will spawn an FPS counter. I'd like a screenshot of this. I believe if you press 'o' one more time, you will get even more detailed diagnostics. A screenshot of this as well would be nice. I'm just curious as to how well your machine is performing in an empty file as it should be pretty darn fast. If we can confirm that, perhaps the UI is "lagging" for some other reason?

No worries at all! Maybe once we get through some of this stuff we can discuss NDI in more detail (or possibly in a new thread). Not a problem at all. Thank you so much for uploading a video showing what it is you are seeing!

This is interesting! One of the big changes in 2020 that had a larger impact on performance than we realized was the new 4D Haze. What most don't know (and what isn't very well documented) is that you can disable 4D Haze by setting Haze Texture Intensity to 0%. This will drastically increase performance, in my experience, and therefore should "speed up" the UI. Can you confirm if you still experience these issues with Haze Texture Intensity set to 0%? What about when you are simply in a blank file? Do the tools activate properly then?

What was the last version of Vision that made it possible for you to use Vision? What are your system specs? There has been a fairly long standing issue with Vision in that the UI slows down when the renderer slows down. In theory, opening smaller files or adjusting Document/Application settings should ease use. Perhaps you're just having trouble locating the two different menu commands? One menu command (Vision Preferences) will spawn the Application Preferences dialog. Another menu command (Document Preferences) will spawn the Document Preferences dialog. It's possible that catalina is causing some issues with NDI. It did cause us issues with UVC devices (ie; webcam). We'll work on trying to reproduce this in house and see what we come up with. Somewhat related to NDI... what license do you currently own for running Vision? And is this a serial number or a dongle?

Even in this occasion, the meshes/geometry will be of a higher quality when using MVR for "meshes only". Doing this "split MVR/ESC" workflow is far from ideal. So, I understand that in this occasion you may use entirely ESC. Just wanted you to be aware that exporting everything but conventionals in MVR to Vision and merging in conventials via ESC results in the best renderings (until we fix this bug then MVR will be the preferred workflow 😛). Here is a link to a post I made a while ago that showcases the improved renderings in regards to meshes in MVR:

Just realized one last thing I didn't mention... Falling back to Vision 2020 SP2 isn't completely necessary to "get this to work". Although, this is probably the easiest "workflow". An alternative would be to export all conventional fixtures via ESC and export all other information via MVR (such as meshes/geometry/moving heads). I would recommend when using this workflow that you always open the MVR first and merge in the ESC. This will result in better "document settings" (primarily, Use Normals will be enabled).

Ofc, anytime! No worries! I'm going through our bug reporting system now trying to see if this has potentially already been reported/fixed. If not, we'll get this in the hands of the right developer and hopefully have a fix soon!

ESC is a proprietary Vision file format. It is highly unlikely that they could read this file format as it requires other proprietary backend data to read properly (primarily, fixture content/resources). My apologies! Somehow this regression seemed to have gone "un-caught". As I stated above, you may consider falling back to Vision 2020 SP2 where the reading of Focus Point information out of MVR seemed to be working (at least in my tests). We will work hard to ship a fix for this as soon as possible.

There are some things I'm going to talk about. So, I want to make sure we're all on the same page and using terminology that we can all understand 😛 In my eyes, rotation information and focus information are two different things. - Rotation information would be something like hung vs floor mounted. Similarly, if a truss was at a 45deg angle, the fixture would need to be rotated to be mounted properly. - Focus information would be something like pan/tilt angles of the fixture. It could also be an X, Y, Z position in the scene. So, in this instance, it seems like the rotational information is correct but the focus information is not. The "Send to Vision" menu command uses the proprietary ESC file format. While this file format does take focus points into account, so should MVR. I just ran some tests and it seems like there was a regression introduced between Vision 2020 SP2 and Vision 2020 SP3. If you do not need the features/bug fixes in SP3, you may consider falling back. This scenario isn't quite tested as often as you're usually going out of VW into some other program (not back into VW). That being said, I would consider this a bug and can pass the information along. This does not appear to be an issue with VW export of MVR. I confirmed this by opening an MVR with focus points in Vision 2020 SP2. The fact that you are having issues with Vision 2020 SP3 and issues reading an MVR back into VW are both bugs/regressions. This is not a flaw in the MVR file format as it does take focus into account. This is most likely because Depence2 has not yet implemented the parsing of focus point data out of MVR. Focus points in MVR are associated to fixtures via a UUID. The focus point contains an X, Y, Z position that the associated fixture should "focus at". You can contact Depence2 and see if they are willing to implement Focus Points and how long that might take to ship to the end user. You can also use Vision 2020 SP2. We will be shipping a fix for Focus Points in MVR with Vision hopefully sooner than later. 🙂 Thanks, you too!! 🙂

Would you mind posting your .v3s file that is experiencing this issue? In theory, we can take a look and at least determine if this is happening at read time or write time. I tried reproducing this issue on my local machine and was unable to reproduce. Any additional steps you may be able to provide will be helpful!

Unfortunately, Vision is primarily a pre-programming tool. Thus, in order to control the color of these fixtures you must send them DMX. We work with Artnet, sACN, HogNet, and MANet. Do note, that HogNet and MANet are only available on PC. Also, note that MANet requires a dongle and will not work with a serial number.

I want to point out that only the ESC file format (which is what Send To Vision uses) supports sending shutter cut and color information to Vision. Can you ensure that the Fixture Modes are set properly on all fixtures? When exporting an ESC, all lights should come over as lights and not meshes. This is odd. I'm hoping it will correct itself as we work on fixing other issues with the export. Please ensure you are on the latest releases of VW and Vision as we recently fixed some bugs related to conventionals and their color/gobo wheels. The issue I see more often here, however, is that the wrong "color" was set. By this I mean, VW has two different locations the color can be set for a fixture. There is the color that most people are used to using (the one that effects Renderworks/VGM). But there is a new Color Wheel tab in the properties for a Lighting Device that corresponds to Vision's Color Wheel (in conventionals, we use color wheels to simulate gels). Please ensure that you are changing the Open slot of the Source 4 Color Wheel in VW to be sent to Vision. This is by design currently. We are working on getting VW to export shutter cuts, gobos, and colors into MVR so that Vision can read this data. Hopefully this helps and we can work out the kinks! You too!!

9 times out of 10 this is a result of the Fixture Mode being set to "None" instead of the appropriate Vision fixture for the device.

How are you exporting from VW? Send to Vision? ESC? MVR? I haven't noticed any issues with things being piled up at the origin. Could you please attach your VWX or PM it to me?

It was just brought to my attention that the Vision 2020 SP3 release introduced a regression with loading focus points via MVR. It appears ESC still loads properly. If you can use it or don't mind, this may be a valid work around. If you need to use MVR for focus point information, please fall back to 2020 SP2 until further notice. (Note: Just to be thorough and clear, only conventional lights can be focused in Vision via focus point. All moving head fixtures only accept dmx and do not understand focus points.)

Not sure how much I'll be able to help as I'm not the best with light boards. BUT, I did notice one thing that I found interesting. It appears as though you are trying to use sACN by your screenshot? The thing I noticed is that there is no `*` next to it. In Vision's DMX Provider dialog, whatever DMX Provider in the dropdown has the `*` is the current DMX Provider. Make sure that you select sACN in that dialog, click OK, but I'd go back and open it up again to make sure it "took" 😉

This is actually a known bug in Vision. I'm not sure when it broke, but we have a fix ready to ship for Vision 2020 SP3. Keep your eyes peeled!

As it stands currently, there is no way to do this. If this is a conventional fixture, it can be zoomed in Vision via the Software Console Palette. If this is a moving light, you will need to use DMX to change the zoom of the fixture.

Sorry you're running into issues! You may have better luck posting this in the VW portion of the forums though as this subforum is specific to Vision previsualization.

Leveraging High Quality materials in MVR for VW2020->Vision2020 How to start Ensure that no procedural shaders are in use. Correct Incorrect Ensure that all image-based shaders are of a sufficient quality (72x72 is insufficient). Correct Incorrect All non-generic materials should use a reflectivity image and an appropriate blurriness setting. Brighter images will reflect more light. Low blurriness will create a sharper specular highlight. (Vision's default material resembles cloth or plastic with a slight shine. If you skip this step, your mesh will resemble slightly shiny cloth or plastic). Reflectivity Instead of using vertices to add detail to a mesh, consider using a transparency image or bump image. For example, apply transparency image shaders to a simple low-poly extrude to create a chain link fence. Or, apply a bump image shader to a simple low-poly extrude to create a brick wall. To give cloth a "textured" look, try using darker, noisy images as the basis of a bump shader. Transparency Bump General Tips Color shaders can use color. Color Reflectivity shaders should be grayscale (exception for metal whose reflectivity is the same color as its base color). Brighter images result in stronger highlights. Non Metal Reflectivity Image Metal Color Image Metal Reflectivity Image Blurriness values for reflectivity shaders should match the material in the real world. Metal is not blurry at all, but carpet is very blurry. Non Metal Reflectivity Image Metal Reflectivity Image Transparency shaders should always be black and white, (no gray). White will be rendered, black will not. Transparency Bump shaders should be grayscale. This shader should be mostly dark with some lighter shades for indentations. (If, instead, you use a mostly white shader with some darker gray areas to indicate bumps, then 90% of the mesh will be "indented". This looks odd when navigating around the scene. So, stick with darker bump images.) Bump Debugging Start by exporting MVR, changing extension to zip, and extracting. Examine all exported images. In Vectorworks, replace low quality or "broken" ones (typically resulting from a procedural shader or bad content). Extract MVR Find Low Resolution Textures Next, import the MVR in Vision. Navigate the scene with Ambient turned up and verify things look correct. Fix any issues. Correct Incorrect Next, use Render Specular to check reflectivity materials in Vision. Verify that all specular images are correct and display as expected. Fix any issues. Correct Incorrect Then, use Render Normals to check bump/normals in Vision. Verify that the bump detail looks right, and the expected colors are being rendered. Fix any issues. Correct Incorrect Finally, ensure that all materials have the proper specular power. 0% blurriness (i.e. shiny metal) =~ 1024.0 specular power. 100% blurriness (i.e. cloth) =~ 1.0 specular power. Metal Cloth

I love this idea! We have always generally focused on prettier looking scenes with lower light counts as these same files were used for marketing material. But focusing on a performance friendly scene with many many lights is a fantastic idea. Let's coordinate on this. Just an FYI, I think the priority here would be large show file then medium then small. I like your, "Go big or go home" idea above 😉 If you can provide all three, that would be great. I'll look into seeing which ones we can get approved. 🤣 I think it's somewhat of a personal preference for me. I prefer the mobility of a laptop over a desktop. And don't get me wrong, my laptop is beefy. But a laptop will almost never outperform a decent desktop. And even though I do my primary development on a MBP, I have a Windows PC that is a desktop and it's card is nicer (but could still probably use an upgrade; tbh, I never thought to request one as I use it so infrequently). So, maybe saying minimal hardware wasn't completely accurate. I simply meant that your 2x2080Ti in SLI Thread Ripper is going to demolish my primary machine that I use for development 😂 I think anytime I need more power than my MBP or Windows PC can handle, I just borrow the TechSupport/Marketing machine which is at least 2x1080Ti in SLI. No thread ripper though 😛 No you are completely right! My example was poorly formed when talking about passwords as neither of those examples represented how software scales. So getting right to the point as Vision itself is a good example: (Note: I haven't tested this, strictly speaking. But this is pulling from my general experiences and memory.) If you ran Vision 2018 on an old machine and ran it on a new machine, you may get a 50% increase in performance. I feel this is being generous, but perhaps I'm wrong. If you ran Vision 2019 on an old machine and ran it on a new machine, you may get up to a 200% increase in performance. I expect given the right circumstances it could be much more (given how we leverage the number of textures the GPU supports). One last thing to point out is that Vision 2019 gave you the ability to control the way performance scales. So, in Vision 2018 you were stuck with the 50% increase when you upgrade your machine. With Vision 2019+, you are given many options to control the quality vs performance. This can be used to offset the poor performance of the old machine to bring it more "inline" with the newer machine. So all this being said, have things improved since 2018? Of course 😄 I don't think anyone is denying that. But to your point, that next leap in performance sure would be nice 🙂 What makes this tough is performing analysis on current code, and then properly executing a new design without breaking existing functionality. I still truly believe from what I've seen, the renderer is running very well. We never truly optimized the physics engine and I believe it is to blame. It will be a major overhaul to get it to be more performant, but I think as we investigate more we will find this is the right course of action.

We do not have any, but this has been discussed in the past. I think one issue we kept running into was users wanting their files kept private. A lot of the files we get from users are on NDA and cannot be shared with other users, but are used for internal testing. Most of our developers run on fairly minimal machines. Tech Support and Marketing have access to one "beast" machine that we often take to tradeshows. This machine was a beast when we built it, but it is now becoming dated. I'm not sure the CPU/RAM that it has, but we had 2x1080Ti's in SLI in it at one point. No, but I like this idea a lot! I'm not sure how we'd go about approaching it, but that's neither here nor there 😛 Those limiting factors are not time and money. I know this is an extreme example, but passwords are very well encrypted. So much so that the fastest computer in the world would take years/lifetimes to crack it. The "issue" here isn't necessarily the hardware. It is the algorithm that is used to crack this password. For example, a dictionary attack may be faster than brute forcing. This is all on the same hardware, but the software imposes an upper limit on "how quickly the password can be cracked". Taking this conversation to Vision, look at Vision 2018 vs Vision 2019. It did not matter how much time/money/hardware you threw at Vision 2018, it just ran like garbage compared to the same machine with Vision 2019. So, while it may seem like the limiting factors of performance are time/money, this is only true to a certain extent. Eventually, you will hit an upper limit of the algorithm itself, and the issue is no longer hardware but the software design. One thing to keep in mind as well as that it was somewhat intended for these features to be shut off for real time renderings. The main reason we keep these features around is for "High Quality Render Movie/Still". Lastly, I do not disagree that Vision performance for real-time renderings needs to be improved. There are a few areas we can look at, but the one I've got my eye on is the physics engine (which is what handles panning/tilting fixtures, moving meshes related to DMX XForms, etc etc). I'd love to get some files from you guys that you wouldn't mind shipping as a demo file for Vision 2021. We usually record some DMX with it so a user without a light board can easily playback a showfile to see what Vision is capable of. The only other thing is finding a way to document hardware performance as well as driver performance. This will need lots of testing. Perhaps, the best thing to do here is come up with a "workflow" or "benchmark" for testing. For example: Load the sponza demo file Ensure all app/doc settings are set to default Playback recorded DMX Write down FPS at 0:30, 1:00, 1:30, and 2:00 (or something like that) The most important thing when doing these kinds of tests is ensuring that everyone is testing the same way. Having other programs like VW running in the background would affect these tests. So, we'll have to take it on good faith that no shenanigans like that are happening.

I don't think this portion of the original post settled in for me until just now. tldr; Try applying a rotation in the Property Window to different items/parents/children in the Scene Graph to get different results. One of the items/rotations may be exactly the anchor point you need. One thing that is important, especially with MVR, is that you are working with the right item in the Scene Graph. There are various levels to an MVR object; an it isn't necessarily intuitive the way it is displayed in the UI right now. It may be that no matter what you rotate in the Scene Graph, it is not giving the desired anchor point. In this case, following @jweston's post/advice is sound! But let's look at some examples, because to be honest, I was surprised by the results! I thought that in order to get a truss to rotate around its center, a new layer would have to be created for the anchor point. But, after playing around with it more, I realize that at least for some truss this is possible without a new anchor layer! Look at what happens when I rotate on the various layers/geometries of a truss. Pay particular attention to the item selected in the Scene Graph, the rotation value in the Properties Window, and the result of that rotation in the viewport. Also, notice the MVR UUID in the Properties Window. A non-null uuid signifies the "root" of the MVR object: Let's also quickly show that same example with a sphere: Hopefully between this explanation and the various comments from our users about how they've solved this problem, it helps you out!

I'm glad you're getting slightly improved performance! Tweaking the scene/fixture/geometry/render settings is always an interesting balancing act. I'm curious as to how much Haze Quality impacts the rendering speed. (And generally, run in realtime with shadows OFF. Only enable shadows for rendered movies/stills. This is the default behavior.) One last "power user tip" that a lot of people aren't aware of; there is a Force Emissive flag for fixtures that prevents beams and surfaces lights from rendering. When this option is enabled, all that is rendered is the lens and the bloom effect for that lens. Fixtures that have multiple light emitters can really kill performance depending on how many emitters there are and how many of these fixtures are in the scene. So while the Force Emissive flag isn't very helpful when the light is being used to, say, wash a stage, it can be very helpful in certain instances (such as generic blinders). We often use this flag internally for Nexus 4x4's and the like 😉

I like the 2020 haze too 🙂 It may just be that you turn it on for your final renderings but don't use it for real-time preprogramming. FWIW, you should get much more than 9/10FPS given you use the same default settings I used in my tests. My machine is OOOLLLLD. Like, going on 5 years old 😛 I have an AMD Radeon R9 M370X with only 2GB of memory. Your 1070Ti should destroy my graphics card 🤣 One thing I would do is ensure you are running with settings similar to my own. All I did was open your v3s, then launch the application and document preference dialogs. In each, I selected <Default> from the saved sets dropdown. This will get us "on the same page". But again, your 1070Ti should well outperform my M370X. If this is still not getting you the performance you want, I would suggest tweaking the default application/document settings to get the performance you need. This was a big improvement to Vision, as in the past you had no ability to adjust settings to tweak performance/quality. As we've already discussed, setting Haze Texture Intensity to 0% helps substantially. Adjusting Haze Quality will make a big difference as well. Think about playing with things like Resolution Quality, Render Shadows, and Shadow Quality as well. My only suggestion here is to be forgiving of quality in real-time. Vision can get the HQ renderings in a rendered movie/still. As far as purchasing of more powerful hardware: It's hard to say if upgrading to a 2080 will result in enough performance gains to be worth the cost. We've had some customers really ball out on a machine, only to find that there are limitations in Vision's code holding back the hardware. This probably seems obvious, but in general, no software can scale infinitely to leverage all hardware. There is always an upper bound on the code design itself. We generally find that Vision leverages as much hardware as you can throw at it (ie; 2x1080Ti's in SLI performed almost twice as fast as a single 1080Ti). But again, there is always an upper limit as to how much hardware software can use.