Inconsistencies in Vision...

[Charlie Hegelheimer]

Hey guys! 

 

 

I have a few questions here today. 

 

1.  I have not used Vision too much but have watched most the videos in the university to optimize and understand the settings to increase performance. My goal was to complete some time coded shows to use as a demo for some artists I am working with. I have exported my stage design as an MVR and then saved the scene and settings as a v3s file.  The other day I was able to use the software fairly smoothly to get a bulk of the time code done but have since tried to launch Vision multiple other times with the performance just being abysmal.  I did not change any settings but now I can barley use the software.  I have shadows off and texture quality at Med. I am running an RTX 3090 and the graphics card seems to only be running around 40% yet the software seems like it just cant do what its supposed too.  Other than MA2 there is nothing else running on the machine and have been on fresh boots every time I launch Vision. It just seems like Vision runs very inconstantly.  Additionally when it was running very "choppy" I would try and lower texture quality from Med to Low/very low and it almost takes an hour to relaunch the file. While its running it doesn't seem like the CPU or GPU are being utilized. When the file finally re launches after adjusting texture quality its almost worse performance.  Granted I have built a stage that would be considered very large at a 600 Fixture count (bulk of the fixtures are non moving LED) but have set most of the fixtures to "Force Emissive"  Being that Vision is part of Vectorworks and essentially the industry standard for drafting designs I would really like to think that Vision should be up to the task of handling stages of this magnitude. 

 

When things were working well the other day my setting were 

1920x1080 

HD Haze

No Shadows 

Med Texture quality

 

Since, I have lowered everything and its performance is worse and essentially unusable. 

 

Any insight on how/why there would be such inconsistency and how I can fix this?

 

Second question is in regards to fixtures...

 

In my stage I have :

Martin Mac Axioms 

VL4000 Beam Wash

Martin Mac Quantum Wash

Elation Chorus Line 

JDC-1

 

-The VL4000s gobos are not displaying in vision.  When I select the asset/fixture in Vision on the right side I can see that it has the gobo images for each wheel but they just don't show up in the visualizer.

 

-The Chorus Lines do not light up at all.  Even when I select them manually they do not  "Highlight" like fixtures usually do in Vision. 

 

I imported the MVR file and used the "Vision" Fixture when opening the MVR.

 

If there is anything I can provide please let me know.

 

Thanks in advance!

 

Charlie

 

Edited August 23, 2021 by Charlie Hegelheimer

[bbudzon]

It sounds like you've done a lot and have learned quickly! Very impressed!

 

It's hard for me to say why the performance of your file is subpar. Your settings seem pretty sane for a file with 600 lighting devices and you've already discovered the Force Emissive feature which can help with fixture count drastically. You also mentioned that this file has performed well in the past and that only recently have you run into performance issues. So, I am hopeful we can get you back to that enjoyable performance.

 

If I had to guess... I'd say that your biggest hit to performance is one of the few you have not yet mentioned; Haze Texture Intensity. I'm not sure why this would have changed, but if this document setting for haze is set to anything between 1-100%, then Haze Texturing will be Enabled. This is the 4D portion of the haze, if you've seen that in the UI. By setting Haze Texture Intensity to 0%, it will disable the 4D algorithm which provides an even wash of haze for beams of light and saves significant amounts of time in the rendering engine. If this does not help, maybe we can exchange files and screenshots to see what may be going on. Tweaking Vision settings is definitely something I am most familiar with 😛

 

In regards to the time to change Texture Quality, there is a lot of different things going on here that most users aren't aware of. For starters, any Texture Quality that is Medium or above uses a concept we call a Dynamic Cache. Any Texture Quality that is Low or Very Low uses a concept we call Static Cache. If you switch from any Texture Quality that is Medium or above to Low or Very Low, we must essentially reload the file clearing out the dynamic cache and building the static cache. This is true in the reverse direction as well. Changing Texture Quality from Low to Very Low or Medium to High would not trigger this "full rebuild" of the static and dynamic caches.

 

My guess is that the some odd hour you are waiting when changing to Low or Very Low is spent on a progress bar for rebuilding the static cache. If the static cache is taking this long, it tends to imply that there are many many vertices in the scene; ie a very high poly count. Vision leverages a technique called Deferred Rendering which generally nullifies any performance hit from high vertex counts. This was important for Vision as it's main "input" is meshes from VW. And VW being as detailed as it is, often includes meshes that are not truly designed for realtime rendering. But, even with this deferred rendering technique, there is a limit and certainly you will always get better performance when the vertex count is lowered. The biggest offender of high vertex counts is the geometry that VW uses for truss. One way to determine what is causing the static cache rebuild to take a long time is to only send over bits and pieces from VW to Vision, checking as you go. One other fairly quick test that helps check rendering performance (but not load time / rebuild performance), is simply unchecking the Visible flag for an entire layer. This obviously will not decrease load times or make the static cache rebuild any faster. But, if making a layer that contains a bunch of trussing invisible drastically improves render speeds, it is likely the case that this layer contains more vertices than is necessary.

 

In regards to your fixture questions, I may need to call a content person to this topic 😂  My best guess is that for the VL4000, the wrong profile/personality is being used on the light console or in Vision. Try to make sure the right modes are selected for the device and that the DMX Footprint (or Num Channels) matches. For the Chorus Lines, make sure that the broken behavior is not tied to the Force Emissive flag. In truth, the Force Emissive flag was a hack written by engineering in an attempt to lighten the content teams workload. Normally in Vision, if a fixture causes performance issues, the content team would create two versions of the fixture; the real version that emits light and beams and an "emissive" version that only the lens will glow. Engineering found a way to automate this for most fixtures via the Force Emissive flag; so that the content team only needs to create the "real" version. If the Chorus Lines are broken for other reasons, we may need to correct content files or engineering source code in order to address the issue.

 

Hopefully some of this information helps. Please provide updates and let me know how things are going. Me, being a software engineer, can mostly help with things like performance / quality tweaking settings and workflow related things like how multiple selections work, faster patching, RGB meshes, and such. Tackling problems like gobos not working or Vision not seeing DMX can be much more difficult and may require getting IT, Content, and/or various other departments involved.

[Charlie Hegelheimer]

Thank you for your Thorough response on this. 

 

Regarding overall performance, I re-exported the MVR file to remove truss and also the crowd/entourage as non of that is really needed to create the time code and will just use the full file when I record everything.   This has helped a bit, not as much as I'd like but at least its usable.

 

The Elation Chorus Line fixtures did not automatically have a profile in VWX but I was able to manually find the correct one and the fixtures are working now.

 

The VL 4000 do have the correct channel numbers in the fixture profile and are working as expected minus showing the gobos.  Again this is very odd as I can see all the gobo images in Vision under the Properties window so it must be something in the profile or programming.  I can see in MA the DMX output sending values for the gobo wheels its just does not seem to be translating to vision.  I am going to spend some more time with them and see if I can get them to work. 

 

Overall I really hope to see the performance increase in Vision.  I am not a software engineer so I am out of my element here but it really doesn't seem like it runs very smoothly when trying to run large designs.  I get countless crashes and it seems like inconsistent performance.  This may very well be me/user error or even my machine but I am excited to see this software grow/improve as I am pretty highly invested in it now. 🙂

[bbudzon]

14 hours ago, Charlie Hegelheimer said:

Thank you for your Thorough response on this.

Not a problem at all!

 

14 hours ago, Charlie Hegelheimer said:

Regarding overall performance, I re-exported the MVR file to remove truss and also the crowd/entourage as non of that is really needed to create the time code and will just use the full file when I record everything.   This has helped a bit, not as much as I'd like but at least its usable.

These are items that notoriously increase vertex count and unnecessary amount. Some users will just not send them over. Some users will use a single large box extrude to emulate a truss. Some users make custom symbols for trussing that are low poly count and "realtime render" friendly. So, it does make sense that not sending truss (and crowds) to Vision helped. But again, Vision tries to be very good about large vertex scenes via it's deferred rendering technique. So, I'm also not surprised it didn't make a huge difference. It makes the largest impact when shadows are enabled, but most only run with shadows for rendered movies/stills.

 

14 hours ago, Charlie Hegelheimer said:

The Elation Chorus Line fixtures did not automatically have a profile in VWX but I was able to manually find the correct one and the fixtures are working now.

Great!

 

14 hours ago, Charlie Hegelheimer said:

The VL 4000 do have the correct channel numbers in the fixture profile and are working as expected minus showing the gobos.  Again this is very odd as I can see all the gobo images in Vision under the Properties window so it must be something in the profile or programming.  I can see in MA the DMX output sending values for the gobo wheels its just does not seem to be translating to vision.  I am going to spend some more time with them and see if I can get them to work.

As a test, I inserted a Varilite VL4000 Spot 16bit and a Martin Mac III Performance Basic into a vision scene. It took me a while to figure out how to control these from the light board, but I once I figured it out I had no problem getting gobos to render in either fixture. One thing you may need to keep in mind for the VL4000 is the "16-bit linear control of edge functions". This 16-bit value straddles channels 6 and 7 (6 is high byte, 7 is low byte). When I have the edge control set properly, I get the following rendering:

If I leave the edge control set to 0% on channels 6 and 7, it results in a very "fuzzy" gobo that is almost indecipherable from an open slot:

So, please make sure you are controlling the edge function properly.

 

15 hours ago, Charlie Hegelheimer said:

Overall I really hope to see the performance increase in Vision.

You never said whether or not you tried setting Haze Texture Intensity to 0% or not. When this value is between 1-100%, it enables "4D Haze" which can cause performance issues and is generally reserved for render movies stills.

 

15 hours ago, Charlie Hegelheimer said:

This may very well be me/user error or even my machine but I am excited to see this software grow/improve as I am pretty highly invested in it now. 🙂

We are always working to improve the application and have some really neat things that will ship with 2022 that will make it easier to get the performance/quality that Vision is capable of. One issue we've seen over the years is that many times the issues are user error. However, we take responsibility for this as our settings are not intuitive. Keep your eyes peeled with Vision 2022 😉