bbudzon

We are very sorry for this and realized the missing feature not long ago. I'm trying to get it bumped up on the priority list. Hopefully using MVR makes things a little easier in the short term 😉 I assure you, this is something we'd like to get resolved sooner than later as it has caused a lot of users headache!

I thought maybe I could help out by recording a video demonstrating the workflow of how to set colors on conventionals in VW and how you can send them over to Vision via ESC. When following this workflow, you do not need to worry about making changes to the plot in VW and re-sending it to Vision. So no worries there!! Untitled.mp4

An Alpha texture is like a Transparency image shader in VW. It is a black and white image where black is transparent and white is opaque. Here are a few examples from the Sponza file to give you an idea of what's going on:  Regular Image Texture Shader  Alpha Texture for the Regular Image Another example of a regular image texture/shader  Another example of a alpha texture for the regular image above I would HIGHLY recommend taking a look in the Sponza Demo file's texture folder. Some REALLY cool examples in there 😉 That file uses bump textures, specular textures, the whole 9 yards! 😎

Let me explain a few limitations of Vision 2019 and a few limitations of the Export MVR command in VW.  First and foremost, Vision 2019 does not support "transparency" as you might think of it. Things either either fully opaque (i.e. rendered) or fully transparent (i.e. not rendered at all). Things that are fully opaque cast shadows and things that are transparent do not. The best use case of this is Vision's Alpha Texture (somewhat related to VW transparency shader). Let me provide a good example...  You could model a leaf or a truss with each and every little poly modeled out. This increases quality but severely decreases performance. If you want to get clever with it, you can model out a stick of truss as a plain extrude and apply an "Alpha Texture" to get the "sticks" of truss to appear. The same can be done with foliage, as seen in our Sponsa Demo file (note: Texture Quality must be set to Very High for a lot of the advanced materials to take effect).  No Alpha Texture applied!  Alpha Texture in action! If you look closely, you can see that even the shadows are cast properly and they respect the Alpha Texture. Very cool!! 😎 I stated earlier, this Alpha Texture can be used to create very "performance friendly" sticks of truss or even a chain link fence. I've even wanted to create an example of a rectangle with an Alpha Texture applied to create a performance friendly industrial fan! Next on the list, let's discuss a bug in Vectorworks. Vectorworks currently is not exporting anything other than the Color shader in MVR. If a color is applied in the Color shader, it should come over. If an image is applied in the Color shader it should come over. It skips over the Reflectivity, Transparency, and Bump shaders. We are working to address this as soon as possible. In the meantime, any reflectivity/transparency/bump shader images that you may have in VW can be manually applied in Vision via the Properties Palette (note: Vision does not support procedurally generated textures yet, only images). We are very sorry for the inconvenience and are hoping to get this export issue resolved quickly.

Sure! Bad news first: - Vision does not support procedurally generated shaders. The only kind of textures/shaders Vision supports are in the form of images. - There also seems to be a bug in the MVR/3DS exporter in VW. Even if you do add Image Shaders to all of your various Renderworks Textures, they are not exporting into the MVR. - Vision does not support transparency. It only supports alpha masks which render parts of a mesh as fully transparent and other parts as fully opaque Good news! - We want to get procedurally generated shaders working in Vision, hopefully sooner than later. We also believe that there is a way we can back some of the procedurally generated information in the MVR at export time from VW such that Vision will pick up on at least some of those changes. - We are working towards fixing the bug in VW when Image Shaders are selected as these will work in Vision without issue. - While it may be some time before Vision gets real transparency/translucency in it's rendering engine, Alpha Masks allow you to make some REALLY cool high-quality performance-friendly meshes. The examples I always use are sticks of truss, plants/foliage, and a chain linked fence. Normally you would model these out in their entirety and they would take up hundreds of thousands of polys. But something like a chain link fence could be a simple rectangle with an alpha mask applied such that light passes through it in a chain-link-shaped fashion. Not only does our primary renderer abide by alpha masks, but are shadow map renderer does as well! This means you can use this effect to cast chain-link-shadows onto, say, a curtain. Very cool! When it comes to detailed texturing in Vision, I highly recommend everyone dig down deep into the Sponza Demo file. Look at the textures that are being applied and find those textures on your computer and open them up. Take a look at the bump map images, the normal map images, the reflectivity/specular images, and the alpha mask images. Also, play around with the "Render Normals" and "Render Specular" options in Vision and navigate a little bit around the Sponza scene. This will give you a much better idea as to how image shaders work in Vision and how you can leverage them in your workflow! (Note: I realized I made a detailed post about this with images for examples but it was in the BETA section of our forums. I'll look into posting that here as a follow up to this comment)

We're really working on flushing out the help system to please check there! Vision > Vision Basics > The Scene Window http://app-help.vectorworks.net/2019/Vision/index.htm#t=2019_Vision%2FVision%2FThe_Scene_Window.htm It will be under Saving User Views! One thing I want to clarify just to make sure it's understood, the numpad is only for switching from front/back/left/right/isometric views. The keys above 'qwerty' are the ones you'll use for saving and recalling saved views. These are the views that DMX Controlled Cameras are associated with! 😉

@zeroInf I'm so glad you got things running! You have a few options as far as increasing the quality of the beams/volumetrics. First and foremost, you can toggle the "Enhanced Volumetrics" on and off. When they are turned on, we use our new 2019 ray-tracing algorithm which looks FANTASTIC when doing audience scans. When they are turned off, we use the older Vision 4 style volumetrics which use a slicing algorithm which can look more "choppy" but less "fuzzy" at lower resolution (as we will see in my next example). Enhanced Volumetrics On Enhanced Volumetrics Off I tend to prefer the newer 2019 Enhanced Volumetrics, but the older style volumetrics can look "sharper" at lower "Resolution Quality" settings. Enhanced Volumetrics On - Low Resolution Quality Enhanced Volumetrics Off - Low Resolution Quality That being said, you have a GREAT graphics card 😄 And you can generally afford to bump those settings up as you've stated!! So here is what that same image looks like in 2019 with the Resolution Quality as high as it goes. Enhanced Volumetrics On - High Resolution Quality As you can see, there is still SOME fuzziness to them but in general they are MUCH sharper. Whether you are using the old style volumetrics or the "Enhanced Volumetrics", be sure to adjust the "Volumetric Quality" to get more slices (in the old algorithm) or less fuzz (in the new "Enhanced Volumetrics"). Also make sure you maximize Vision or go into Fullscreen mode to fully leverage your screen real estate and resolution when aiming for higher quality real-time renderings. We are also looking into additional settings for the ray-traced enhanced volumetrics for 2020 for higher end graphics cards that will reduce the "fuzz" even further 😉 Stay tuned!!

@Charlie Winter To provide a little more information, when testing the MA3 over MANet with Vision we ran into issues. When contacting MA about getting an updated .dll for MA3 support we were told this is not currently being worked on. What I'm getting ready to say is just what I was told, so take it with a grain of salt. That being said, it makes sense to me. MA, at one point in time, got into a little bit of political drama with what previsualizers they chose to support. WYSIWYG and ESP Vision were, at one point in time, the only previzualizers that supported MANet as MA supplied the companies with .dlls but did not supply the other companies with one. MA, rather than playing "favorites", wants to come up with a more universal solution to hooking up MA3 to 3rd party previsualizers. This just may take some time. I hope that sheds a little light on the matter, and I certainly don't blame them for the choices they make. It makes business sense to treat all previsualizers equal and to not waste development time making a .dll per previz (which I understand is what was done in the past). Having a more universal approach makes the code more reliable and more readily available. If you'd like to express your interest in getting the MA3 to connect to Vision over MANet, I would recommend contacting ACT.

To the best of my knowledge, GrandMA has decided that they are dropping support for non-MA3D pre-vizualizers with there MA3 console. If you want to use an MA3 with Vision (or as far as I know any other previz not created by MA), you must use Artnet or sACN. Please let us know if you run into any issues with those protocols, however! We have not had any problems here in-house, but if you experience issues we'll be glad to help!!

Are you sending Artnet or sANC out of your MA3?

Currently, Vision is working on getting better GDTF support. We support a large chunk of MVR, but GDTF support needs improvement. What happens right now for current libraries/symbols in VW is Vision maps them back to the litfile content that existed prior to GDTF/MVR. Hope this helps!

@DBLD As far as the lights go, it sounds like VW is having issues picking up the new fixtures you requested. This could be confirmed by exporting an ESC and verifying that the issue is not specific to MVR. As far as the trusses go, if you try a different brand/stick/symbol of truss does it work? I ran into some weird issues testing some trusses myself, but I thought we had gotten them all resolved before shipping VW 2019 SP3. Thanks!

It should be horizontal! Thanks for asking! I'll work with Tech Pubs on adding this to the documentation 😉

@Gaspar Potocnik Can you please give me the ticket number? I'm having trouble locating it in JIRA 😞

I'll ping tech support and QA on this again and see if we can reproduce the issue on any equipment in house. That will make it much easier to debug the code!

@Gaspar Potocnik What DMX Provider were you using before Artnet that seemed to be break the renderings unless the mouse was moving? sACN! Sorry! You are on OSX, correct? Also, can you please post your system specs?

@Jake DeGroot Thanks for trying things out! 1. All of this is on the VW side, which I am less familiar with. I'll pass this info along to @klinzey and @Moritz Staffel, however! 2. Same as 1. 3. Same as 1. 4. This seems like an issue with VW not respecting the Data Visualizer Mappings? I know ESC uses those mappings, perhaps MVR isn't? I'll pass this info along as well and try to do some testing on the Vision side. 5. Because MVR is spec'ed to millimeters, this should almost always be selected. The only reason I decided to include it was in the event a 3rd party program implemented MVR in a non-standard way (didn't want to leave everyone hanging!). Millimeters is the default and should rarely be changed, regardless of the units in your VW document. I'm glad you're finding reasons to adopt MVR into your workflow! If you haven't tried out the merge functionality, give that a shot too! Very cool 😎

Yes, unfortunately that is a known issue on the VW side of SP3. We are working to resolve the problem in SP4. Layering issues aside, did MVR fix your rendering issues with being forced to move the mouse? That will definitely help us narrow the bug down in the code!

@Brandon Any help you can provide will help us help you as well as the next customer that comes along so it's greatly appreciated! One thing I noticed was you kept using the phrase "send to vision". I just wanted to make sure you saw my post about MVR support in VW/Vision 2019 SP3. If you aren't exporting an MVR and opening that in Vision, give it a try! We weren't able to switch the "Send To Vision" command from ESC to MVR in a SP release, but it should switch to MVR most likely for 2020 😉

@Brandon We've done limited testing of external GPU's over Thunderbolt. I can't see any reason it wouldn't work if you aren't having issues with other OpenGL applications, but perhaps there is something wonky going on in the Vision 2019 code that is messing with the drivers. Do you have boot camp installed? If so, does the issue happen there as well? Would you be able to test Vision 2019 on a system that has a dedicated graphics card to verify the issue is specific to the external GPUs? Sorry for any inconveniences this has caused you! I've let the Vision team know about the problem so we can look into acquiring equipment for internal testing.

Can you please post your system specs?

I think this may be a known bug in VW; it exports everything everytime. I'll pass this along to the team and try to give you an update.

If VSync is enabled, I do not believe it should be pegging your GPU at 100%. If you select ROOT in the Scene Graph Dock and press the 'o' key, it will show an FPS meter. If this is a very large number in an empty scene, you likely have VSync disabled. I highly recommend running with VSync unless if you are testing/comparing performance of the rendering engine. Have you seen this issue in previous SP's of 2019 or previous releases of Vision such as Vision 2018?

Can you please post your Application and Document preferences? You may need to bump the texture quality up to get it to work??

It still uses ESC unfortunately. We were hesitant to change Send to Vision to use MVR as it would change up the workflow mid-release. 2020 will likely use MVR as the default format for Send to Vision. MVR will be the preferred file type moving forward. I highly recommend checking it out. For the time being, from VW simply export an MVR to your desktop or a user-created folder. From Vision, "Open" this MVR to create the initial document. Now you can go back into VW, make more changes, and export the MVR overwriting the original file. From Vision, you may now "Merge" this updated/overwritten MVR into the existing Vision document. Because we use UUIDs to track objects, only updates to existing objects and new objects will be pulled in! It truly is a HUGE improvement to the old workflow (which was plagued by special exports of selected items and other nonsense that users shouldn't have to deal with).