bbudzon

One last thing! It always sucks when merging an MVR into an existing document in Vision wipes out certain changes you've made inside of Vision. I highly recommend once you start applying changes in Vision that you save to v3s so they aren't lost! But more importantly, that you only export items from VW into MVR that need updated moving forward. This means that only those items will get recreated in Vision when you merge the MVR. This should hopefully reduce the amount of "crap, merge mvr wiped my xforms" comments 😛 Edit: Also, as many may not know this, if you ever perform an MVR merge and it breaks something, just hit Undo once! It should undo everything the merge did and get you back to a good state 😉

So, reporting back as after discussing with our engineers, I realized I provided some incorrect information in the post above. Haze Style None does NOT EQUAL 2019 style haze. Rather, it is closer to the 2018 style haze that used slices. Haze Style High-Quality 4D Haze - Half Resolution with Haze Texture Intensity set to 0% is roughly equivalent to 2019 style haze. After running a proper apples to apples comparison between 2019 and 2020, both are getting similar framerates as I expected. 2019 is getting roughly 10FPS. 2020 is getting roughly 9FPS. If you have any questions about Haze Style or Haze Texture Intensity, please let me know! I will do my best to answer.

This is actually an issue that has been coming up a lot recently, but one that takes a lot more work to implement in both VW/Vision than I'd have imagined. What we'd like to do, is get some UI/UX in VW such that you can set everything up there and send it over to Vision via MVR. Now, I'm not saying it wouldn't be nice to have this same UI/UX in Vision! I think that is a requirement as well as you very well may need to make adjustments in Vision once things are moving around. I digress; due to the way Vision is designed, and due to the way VW is exporting MVR, there is a workaround but it is not simple nor straight forward. But, it works. Essentially, you want to make a new layer in the Scene Graph. This layer, by default, has an origin of (0,0,0). You can then drag'n'drop a group of items that move together (say a truss and all the fixtures on it, or even multiple stage elements that happen to move together) into this newly created layer. Once this is done, you will need to reposition all of the children inside of this layer, and you will need to reposition the layer itself. The last step is applying the DMX Rotation to the layer you created as opposed to the moving elements themselves. Since this will rotate all of the layers children, this should accomplish what you need. The hard part about this workflow is the positioning of the layer and the children inside of it, and getting that just right so that the elements rotate around the desired anchor point as you've described. Either way, hopefully this helps and this is definitely something we're trying to solve sooner than later!

(Posting here instead of PM so other users can benefit from this information) Ahh, one thing I forgot about that was an enhancement request implemented in 2020 is textured haze. From the looks of it, the majority if your performance issues are caused by haze as opposed to shadows/surface lights/etc. So let me break this down a little bit so you can understand how to get better performance in 2020 (and potentially even better performance in 2019). It does appear that there is still a regression somewhere that we need to track down. But, I want to help you out as much as possible in the meantime. So, in 2019, you could use the older 2018 legacy style "sliced haze" (called Low Quality Haze Texture in 2020) or the new 2019 style haze (called Enhanced Volumetrics in 2019). The 2019 style haze was software ray traced, but did not allow for any texturing. In 2020, we added 4D texturing to the 2019 style haze (we also unlocked a "full resolution" mode, which should generally only be used for rendered movies). I think this could be at least part of the performance issues you are seeing. But we need to investigate further. When I run your file with default document and application preferences on my old old MBP in Vision 2019, I get roughly 10FPS just selecting the sunstrips in the Scene Graph. When I run your file with default document and application preferences on my old old MBP in Vision 2020, I get roughly 1FPS. This is because the default document preference for Haze Style is the new 4D textured haze (the texturing aspect is controlled via the Haze Texture Intensity field). In order to do a better apples to apples comparison, we should try this same 2020 test with Haze Style set to None (as this is the equivalent of the 2019 style haze). In order to do a better apples to apples comparison, we should try this same 2020 test with Haze Style set to High-Quality 4D Haze - Half Resolution with a Haze Texture Intensity set to 0% (as this is roughly the equivalent of the 2019 style haze). When I adjusted the 2020 Haze Style to None my FPS bumped up to 5FPS (a 500% increase in performance from 1FPS! hahahh). This is still not the 10FPS I am seeing in 2019, but substantially better than the 1FPS we are seeing in 2020 with default settings everywhere. This is the thing I want to investigate further as in theory 2019 and 2020 should perform nearly identical in this case. When I adjusted the 2020 Haze Style to High-Quality 4D Haze - Half Resolution with a Haze Texture Intensity of 0%, my FPS bumped up to 9FPS (a 900% increase in performance from 1FPS! hahahh). This is still not the 10FPS I am seeing in 2019, but it is so close that I believe this is working as designed. Lastly, I used a Haze Quality setting of 30% in all of these tests above. Generally, during my development and due to me having an older machine, I run with this set to 1% instead. Adjustments to the Haze Quality can make a big difference in render times. Since I noticed that the majority of your performance issues are caused by haze, I thought I should mention the Haze Quality application setting. So, lowering this setting in 2020 (or even in 2019) should result in better performance. I will try to report back with any new information we find!

I find this part particularly interesting, as in theory not much in the backend rendering has changed between 2019 and 2020. Would you mind posting what versions of each you are using? ie; 2019 SP4 and 2020 SP2? Lastly, if you could post your Vision file that would be great! We can play around with it internally to see where things are breaking down.

I could be wrong, but I think @BrandonSPP told me about this at one point and I looked into it. I'm not entirely sure that we have control over the code that spawns this dialog. I'm not sure why it spawns, but @BrandonSPP mentioned way back when that despite this dialog, MANet always seems to work just fine? I'll double check and see if a ticket is opened up against this. At the very least, we should have this documented in our bug system so we have a more definitive answer when this question pops up. Either way, hopefully everything is working for you now!

Please follow up! I like being in the loop on these things so next time someone asks I know the answer 🤣

Interesting.... I would've expected that to work!! Good attempt 😄 The dll for MANet should be the same between 2019 and 2020. In fact, if it were to break my best guess is that it would've broken going from 2018 to 2019. So, it sounds odd but the fact that 2019 is working for you is really good! That is the release in which we dropped 32bit support entirely. I'm going to ping @klinzey, @BrandonSPP, @BSeigel, and @Mark Eli in hopes that one of them may know what it going on! You may also considering calling in to Technical Support and seeing if they can work through the problem with you over the phone 🙂

I would try adjust the Texture Scale/Offset H/Offset V in Vision to start. If this gets you even remotely close to the desired look then it seems like the texture coordinates coming into Vision are off. These texture coordinates come from the modeling program, in this case VW. If the texture coordinates are off in VW, it would be interesting to know what you are applying the texture to. Is this a parametric television or blended screen? Or is this a simple extrude with the texture attribute mapping tool being used to apply the texture to the mesh?

Inside of your Vision installation folder, there should be a DMX Providers directory with some dll's in it. If you are missing the MANet.dll in this folder, try repairing/reinstalling Vision to "bring it back" 😉

I've had users report this in the past, but I was never quite able to reproduce the issue or figure out what is going on. Would you mind attaching your vwx/mvr/esc/v3s? I'll see what I can figure out 😉 It sounds like it may be that our content doesn't support gobos in these fixtures? Perhaps, @Mark Eli can chime in.

You should be able to rotate this fixtures via the Vision Properties Window. A new feature was added for Vision 2020 that should be familiar to VW users; the Rotate 3D Menu Command! Perhaps, give this a shot and see how it works for you 😉 Sometimes with Vision (in regards to conventionals), you have to assign the Gobo to the second slot instead of the first. If you continue running into issues, try launching the Software Console window with one of your fixtures selected. Tweak some of these sliders, and hopefully you'll get to your desired look!

Perfect!! I had no idea 😛 (sorry, I'm just a lowly programmer 🤣) Glad you found everything you needed to get up and running. If you have any questions, feel free to search the forums or create a new thread!

As of Vision 2019, serial numbers are supported. HOWEVER, Vision requires a dongle in order to use MANet. (This was a restriction placed on Vision by GrandMA). I'm not sure how easy it would be to switch you over, but I'd either call in or see if someone jumps in here 😉

I'm glad it's getting more stable for you! I opened an enhancement in JIRA with some suggestions as to how we could solve this. I linked to this forum post, so feel free to leave additional notes/comments here!

I'm not sure if a ticket has been opened or not, but we can certainly look into it. I'm guessing most Vision users are just used to the old workflow or aren't reaching the right people to get things resolved.

I'm not sure I can help much with the VW side of things with plot and model views and what not. Maybe @klinzey or @BrandonSPP can chime in. But as far as your last point was concerned, I wanted to make sure the crash wasn't something I could reproduce and fix. Unfortunately, I could not reproduce this issue. My concern is your forum signature 😧 Looks like you have an nvidia card which is not compatible with the Mac Operating System on Vision 2019+. The hardware is okay; if you have bootcamp installed and boot windows on the same machine the nvidia card will work fine. See the tech bulletin below:

I think it is just that when Vision was originally implemented way back when, they treated gels the same way as they treated gobos and that's carried forward; they are essentially interchangeable from a rendering standpoint. I could be wrong, but I think the original crew through some extra wheels in the content just in case; you can safely ignore them if you do not need them 😉

Have you tried assigning a fixture mode, going into the Edit dialog, going to the Color Wheels tab, and assign gels there?

Of course! If you are using 2020 SP2 VW and Vision, we just got renderworks transparency images coming over via MVR. So, simply assign an image shader to the renderworks texture transparency. Export an MVR and open with Vision. Alternatively, this can be done inside of Vision. Each mesh has a Material grouping in the Properties Window. Under Materials is all of the different image textures; one of which is Alpha Texture (this aligns with VW's transparency image shader). For a good example of this, please load up the Sponza Demo file and inspect the chain links and the foliage 😉 EDIT: I realize the above statement is somewhat confusing or misleading. As of the time of this edit, Vision does not support actual transparency or translucency. We support alpha masking, which is a technique often used to reduce polygon counts. Artistically, alpha masks can be used in unconventional ways to sometimes achieve the desired look. But other times, for example glass, there is no workaround.

Unfortunately, there is currently no way of doing this. Meshes are either visible or they are not. Vision 2018 had transparency, but it was never quite implemented correctly (although it kind of worked for simpler meshes). If you happen to have a dongle for Vision, you can fall back to the older release if necessary. (Serial numbers were not implemented in 2018.) Vision 2019 introduced a new rendering technique to drastically improve performance. The cost of this was not having transparency. It can still be done with quite a bit of elbow grease, but it has fallen down the priority list. If you need part of an object to be invisible but not the entire thing, transparency/alpha masks can be used. This is helpful for things like plants, chain links, and other odd ball things; using them for truss is an interesting use case. I'll make sure to bring this thread up in our meetings and let the team know transparency is catching on!

For starters, I want to make sure that you understand that as of 2020 SP2, Vision does not support reading gels out of GDTF. This means that in order to get custom gels over to Vision you must use ESC (for these specific fixtures at a minimum; I'd still suggest exporting geometry via MVR as the quality is far superior). I also apologize, as this workflow is a little bizarre (and seems to be a result of the ESP Studios acquisition). In VW, Lighting Devices have two different sets of color/gobo data; one for VGM/Renderworks and one for MVR/Vision. If you are filling out your color/gobo data in the OIP or if you are filling out color/gobo data in the Instrument Properties or Light Information tabs of the Edit dialog, then you are filling out only the VW side of things. The data you want to look into setting is first and foremost the Fixture Mode. This allows you to select a Vision fixture resource inside of VW. These resources are much more intelligent that VW in that Vision knows how many channels a fixture is in a given mode; as well as how many gels/gobos a fixture supports. (Note: Sometimes we add extra gels/gobos for flexibility in our content.) Once this is performed, then the Edit dialog's Gobo/Color/Animation Wheels tabs should be populated with Vision information. Once you fill out the Vision portion of the fixture, exporting via ESC (or Send to Vision as 2020 SP2 Send to Vision still uses ESC file format) should work well for you! Also a heads up, we are investigating better GDTF support for Vision such that this "ESC workaround" is no longer necessary. ESC is a dying format, and we want to make the full switch over to GDTF/MVR. However, we need to keep ESC around for cases GDTF doesn't yet cover.

Just found another interesting work around. If you edit the texture you are using for the screen (in this case the 16x9 color bars), simply ensure that no procedural shaders exist. In my tests, the 16x9 color bars have a "glow" reflectivity shader. Setting this to None should result in a better image coming over to Vision. This is what I would recommend for getting static images from VW to Vision for screens. Unfortunately, if you are trying to get a Vision Video Source from VW to Vision, the Video Source must be applied by hand in Vision. We have determined this is an issue on the exporting side of VW. I've opened a ticket and we hope to get it resolved soon.

Hmmm, it seems like there may be an issue with the update we made to improve texture exports in 3DS/MVR files. Luckily, the UV coordinates seem to still be good in my tests. It's just that VW is now sending this screen over with a thumbnail texture instead of the texture we really want! So, if you assign a different texture to the mesh associated with the screen, it should look normal. This texture could be an image or video file from disk. Or, this texture could be a Video Input via Capture Card or NDI. Alternatively, you may use the older ESC Exporter. The downside to this is that updates cannot be "merged in" like they can for MVR. Also, the quality of MVR exports is generally of a higher quality than that of ESC (especially when it comes to normals). When using ESC, you should ensure that "Use Normals" is NOT checked. I am investigating what is going on in the code to see how we can get this resolved. Thank you for your patience!

We are actually working on a fix now that we hope will ship for 2020 SP3. The issue is on the VW side at export time. EDIT: I should've provided a work around for the meantime! My suggestion would be to export just that rounded stage as a 3DS file at the highest quality. Everything else should be exported via MVR. You can continue to merge in MVR updates as you normally would.