bbudzon

DM me the file just in case it is something obvious. What we have found is that this issue is very difficult to reproduce and has been very difficult to find in code as a result. Steps to reproduce, while difficult, are usually the silver bullet for getting problems solved quickly.

If you have access to JIRA, you should file it there. The advantage of having this access (which is restricted to BETA users I believe) is you kind of get updates on the report and will see when it has been resolved and at what build number. Otherwise, I'll make a note to open a report in JIRA myself; one that references this forum post. It's not clear to me yet whether or not this is an issue in code or in content. Content issues can be fixed "mid-release". Code issues require a Service Pack. We'll try to take a look sooner than later!

FYI, if you have a LOT of fixtures, sometimes turning Render Fixtures to Off instead of Black can help performance (it reduces vert / poly count in the scene essentially by "skipping" fixture geometry). Also, if you have the time to render a movie out with pre-recorded DMX, setting Render Fixtures to On can give a much more realistic look (one where one fixture can hit another fixture with light and that fixture will reflect like properly instead of just rendering black). Food for thought! Glad you found the setting you needed to adjust 😉

I'll let the team know. It seems to usually be tied to those "dual monitor" setups. Quick question, what resolution are your two monitors running at? Are both monitors "horizontal" or have you physically rotated one to be "tall"? Do you know if these monitors are HighDPI or not? If so, do you know what scale is being used (usually 0.5, 1.0, 2.0)? Thanks!

There was a bug introduced into MVR export at some point. Anytime Transparency shader had an image or image mask, it would use that as the main color image. This was evidenced by the images that got exported, as you've discovered! Very detailed report, much appreciated! This bug was fixed in VW2021 SP4. It should be available now! See if that takes care of things for you 😉

I had seen this post and am not 💯 certain what is going on. There is a lot involved in your workflow, but you did a fantastic job detailing all of it and it appears as though you did a fantastic job of ensuring that everything was accurate down to the pixel. I did have some comments I was "holding on to" because I didn't want it to appear as though I was simply not addressing the issue. I was hoping to be able to find time to investigate with the entire VW Vision team and come back with something definitive. One comment was related to the text above. If you are scaling the image in VW in such a way that Vision does not pick up on the change, then we should try to find a different way to scale the image. One such way is by editing the Renderworks Texture directly. There are probably many other ways. We will need to investigate this more as ideally everything would work regardless of "how" you scale an image. Another comment was that "Capture Source Name" is entirely ignored at export time. This is why you don't notice it in Vision. I believe this was put/kept here mainly to leave yourself notes in the VWX document. However, the "Capture Source Number" will come over to Vision as "1.cap", "2.cap", "13.cap", "52342.cap"; whatever number you put in there will be used as a unique integer identifier in Vision for "Video Inputs" (which can be NDI or UVC). One of my last comments was related to 1920x1080 vs 640x360 NDI Streams. In our research, most users are not cropping NDI Streams and most NDI Streams are not so highly detailed and so large in the scene (as viewed on your desktop/laptop monitor) so as to require 1920x1080. NDI supports high and low bandwidth modes and for a realtime vizualizer low bandwidth is preferable for performance reasons. This is why low bandwidth is the default and likely why you are ending up with a 1920x1080 source stream ending up in Vision as 640x360. If you would prefer the source resolution to appear in Vision, simply select the High Bandwidth radio button underneath the NDI live preview. Because you are cropping and doing other very detailed things, I think this is a perfect example of where High Bandwidth is indeed acceptable. Again, in most cases, you should use Low Bandwidth if you can. I've not had issues with sending multiple NDI streams to Vision. However, it may not be as evident that only Vision Unlimited license allows for more than a single NDI stream. All in all, I'm not sure that any of this will resolve your issue. Users may find it informative at the very least. My hope is that this is merely us not having accounted for some workflow and that another workflow/workaround would allow things to proceed. But it is very possible there is just some issue/deficit in the core code when handling these kinds of things. It might take some time, but I am hoping we will be able to figure this out in the long run and ensure that we support this workflow moving forward.

That is unfortunate. If we could find the steps to reproduce the issue in-house, we may be able to more easily find the issue in code. 😂 Yea... I believe that on OSX a force quit will always trigger the safe mode dialog on next start. However, WIndows Task Manager and End Task does not seem to accomplish quite the same thing. There is not. However, I think we are getting to a point where it makes sense to expose a "force safe mode on next boot" button in the Vision Application Preferences. Depending on how things end up working out in code, this may be able to be a "clear all user settings" button (more similar to VW). Any information you can provide for reproduction would be ideal. I'll see if I can get QA to take a look. In the meantime, I can at the very least start proposing that we expose safe mode / clearing user settings in a more user friendly fashion 😉

So, after digging in the code, it appears that this issue was introduced in Vectorworks 2021 SP0 (or maybe SP1). The issue is specific to 3DS Exports (which MVR Exports leverage) and is not specific to image props. I could reproduce the issue with extrudes just the same. I'm making a push to get this fix submitted to Vectorworks 2021 SP4. This will allow Image and Image Mask Transparency Shaders to be exported to 3DS/MVR properly; and it will not "step on" the main color image. Again, my apologies for the regression. I hope we can resolve it quickly so you can get back to sending Full HQ Textures out of VW and into MVR!

@ajpen, I'm glad this guide has helped! I do apologize, however, as it appears you have found a regression of which I cannot find an easy workaround. I'm going to dig down into the 3DS exporter in Vectorworks and see if I can figure out what is going on. Hopefully, I can find a solution quickly and we can try and get the resolution out in a Service Pack. Thank you for your thorough report and diagnosis. If you have any other questions related to how to leverage textures in VW for export to programs like Vision, please let us know! It seems you've already come up with the idea of using a bump on an image prop, which I had never considered. Cool idea! Cuts down drastically on vertex counts and keeps a decent level of realism. FWIW, the only true workaround I could find was to simply not use transparency (or remove it before export, which would be a pain). Once the MVR is opened in Vision, you could then apply the transparency masks there. Huge pain, but it does work. Again, my apologies and we'll work to resolve this quickly.

If the UI is allowing you to change the UI, then it should take effect. There may be a bug in either detecting whether or not the color temp field should be "editable". There may be a bug in the handling of color temperature. My suggestion would be to play around with a fixture whose color temperature is clearly working; such as a S4 19deg. I posted somewhere in these forums recently about color temperatures. Some users seem to think there isn't enough difference between, say, 3200K and 6000K; other users think the difference is too much. If you can find some time to play around with a known working fixture (in regards to color temp) you should see that 6000K is fairly "white" and 3200K is more "amber". Vision does not yet have a white balance setting. If the S4 19deg is working as you expect, I'd go back and test the molefay one more time. If you still believe there is a bug or issue with the content, report back and kick off tickets to the appropriate parties.

Vision does make an attempt at "remembering" the last location/size/position of the DMX Recorder dialog. If this has somehow gotten corrupted on your system and you cannot locate the dialog to fix the issue, the only thing I am aware of that you could do is boot into Safe Mode. This is not easily accessible and typically Vision will only ask after a crash. However, booting into Safe Mode should clear all users settings (without removing licensing / saved presets). This will clear the last known position of the DMX Recorder dialog such that it should spawn the first time to its default location (which will depend upon monitor resolution, number of monitors, and the monitor Vision is on when the DMX Recorder is spawned). I hope this helps!

I'd have to test, but I think this may be a regression if it is reproducible. I swore all of that information worked in the past. I didn't think we'd changed much in that area so I didn't expect anything to break. I'll try to take a look and see what is going on. What fixture(s) are you testing? Might be best for me to try the same ones JIC. I assume you are using litfiles and not GDTF?

I've never seen an issue where it doesn't spawn. However, we have had issues in the past with the dialog being hidden behind other windows/dialogs. Take a look and make sure it's not being sneaky. One other odd ball thing that could be an issue, I think we had problems at one point where if a dialog was put onto an additional monitor and either while Vision is running or not that monitor is removed, then there may be a bug where it tries to spawn onto that non-existent monitor.

This is something new to me but I imagine you could end up in certain situations where this might make the difference! In particular, it is easy to inadvertently change some preference and not realize it. It is also possible that if you've used previous versions of the software for long enough, there are conflicts occuring that we have not prepared for in code. Safe Mode resetting everything could clean things up. I do exactly the same thing. I rarely leverage safe mode unless I have to. Safe Mode essentially is an attempt to rescue the application from a crash. There are many things that can cause Vision to crash, but one of the possible offenders is insufficient GPU for the given settings. Say you are playing with render settings and you adjust one too high, it crashes. Now this setting is saved in your application... how are we going to change the setting if we cannot get it to boot? If you end up in this case, we need a way to floor the settings (a special "mode"), just so that you can boot into the application and "fix" your settings (ie; match them to your hardware so it no longer crashes on boot). So, it is not something you turn on or off. Behind the scenes, it clears all user data (including preferences) but not licensing/reporting. We also do not delete any files on your hard drive. So, things like application and document presets will persist. NOTE: Be careful using these as these may be what caused the issue to begin with! The easiest way to get out of safe mode is to shut down Vision cleanly (ie; without crashing) and start it again. If you must get out of safe mode without restarting Vision, you can open the Application Preference dialog, select the <Default> preset, and click ok. (In theory, any change to the application settings should trigger the application to leave safe mode. I simply suggest using our defaults and they are generally sane.) I'd have to have some internal discussions to state anything definitive here. My understanding is that the advantage of converting to a mesh or generic solid in VW before export is that it bypasses any decimation / mesh simplification when exporting to MVR. In particular, large objects with curves often look bad when overly simplified and converting to a mesh before export avoids this issue. A hack was introduced at one point where if an object is beyond a certain threshold in size, we would not decimate it during the MVR export as it may result in bad quality. If you are using parametric objects, NURBS, and various other non-mesh non-generic-solid types, then I do believe that these will be decimated during the MVR export. This will happen behind the scenes and not affect your VW document. This also is only true (I believe) if the object is under the size threshold mentioned above. There are currently no user controls for decimation in MVR exports. I think that is something we should investigate. Ideally, at least in my opinion, decimation could be controlled at both a global and a per object level with overrides. So, in regards to streamlining workflow, and to the best of my knowledge, there is no need/benefit to converting objects to a mesh or simplified geometry unless that object looks broken (ie; low quality) when imported into other programs. This saves you time not having to convert things, but also should (in theory) result in better performance as objects that were not being decimated before now are; the total poly count should end up reduced. I hope this answers your questions. There is certainly room for improvement in both VW and Vision in regards to optimizing scenes for realtime and dynamic lighting. It is very hard to compare the two products side by side as they serve two fundamentally different purposes. While this does apply to rendering, it also applies to things like file formats and what an application considers to be important.

There are many many reasons why this is the case. Some of them are limitations in Vision. Some of them are rooted in raw differences between how VW and Vision represent objects (more generically, the difference between realtime and non-realtime rendering software). Vision does not have a concept of symbol definitions or symbol instances. You can imagine how bad VW would perform at save time if you were not able to use symbols. This is a significant problem affecting many aspects of Vision; file size, load time, write time, rendering performance, and more. This is an item that is high on our priority list but something that obviously is going to take a lot of effort but in code and in UI/UX/workflow. Beyond the lack of symbol support in Vision, there are some things that Vision does which are arguably "better" than VW. This is obviously a matter of opinion and what features / functionalities are valued most. One item in particular is in how file formats are handled and their versioning. You may have noticed that Vision does not require exports to open in previous versions. This is largely due to how the scene is processed when being written to disk. Where VW may take a simpler/faster approach to writing to disk, this often forces users to perform exports due to limitations of this file format design. With Vision, we are striving to avoid exports unless they are necessary for technical reasons. In a perfect world, the end user would never have to concern themselves with file versions or exports and Vision has largely achieved that. This does come at an expense and that expense is increased write times. All of this being said, there is always room for improvement and even with the extra work Vision is doing at write time, we should be able to profile likely speed the code up. The other major difference between VW and Vision is in how models are represented. In general, when in VW, it is often preferred to use tools like extrudes, poly lines, NURBS, and more when modeling. Because these tools are optimized for VW, their geometry performs best there. It is my understanding that it is generally not recommended to model in VW with only triangles (more of a mesh representation). This is because, generally speaking, meshes take up much more memory and require much more processing that something like NURBS which is optimized for certain scenarios. So, while VW is performing fairly well for you and Vision is performing poor, this is because they are not using the same scenes; one is made of models optimized for BIM (VW) and the other is made of triangles/meshes optimized for realtime rendering (Vision). I do apologize for any issues you are having. I hope that you understand we are taking this request seriously and it is something we can investigate in more detail. We are always looking for feedback and take it into consideration when planning out our internal road maps.

Selecting the lights in the Scene Graph Dock should also force the lights to full intensity. Do they get any brighter when selected this way?

You hit the nail on the head here 😛 It seems this has been an issue for quite some time. But, we've always had issues reproducing the problem and fixing the root cause of the issue. Do you happen to have a file were it seems to happen more often I might be able to share with developers internally? Thanks!

I had gotten a report from an end user not too long ago reporting something similar. I've seen (what seems to be) random crashes with Render Still. One thing that seems to help reduce the number of crashes is ensuring that your Rendered Still uses "<Active Settings>". If you want the still to be higher quality, you may try adjusting your realtime render settings such that "<Active Settings>" for Render Still uses higher quality settings. I hope this helps and we are investigating the issue in more detail internally.

Vision doesn't officially support "backlit" objects currently. That being said, due to occasional import issues, we've provided a context menu in the Scene Graph Dock for "Inverting Normals". Give this a shot and see if it gets you any closer to your desired effect. It will not be perfect and may not work for your use case at all. But, it is my best recommendation 😂

Ahhh! I do think that is WAD. However, it may be worth investigating the design a little further given this feedback!

Are you using MVR or ESC? (Note: The Send To Vision menu command uses ESC in the backend)

Please make sure you are running the most recent versions of VW and Visions. A bug was introduced in 2020 SP3 that broke focus points for conventional litfiles. This bug should be fixed in 2021 SP2 (any 2021 build after # 567823 should work). Please note that Vision has never supported focus points for GDTF conventionals. This is on our roadmap.

I may be wrong, but at a quick glance this does seem to be the case. In order to get an alpha mask in VW, I believe the transparency shader must be used. I just didn't see any options for the primary image that allowed for masking with the alpha channel. FWIW, the main reason this was originally added was for NDI Streams actually 😛 A customer was in a situation where they had to separate their single RGBA stream into an RGB stream and a separate stream for the alpha. When adding this new feature, not only was this easier for them to use a single RGBA stream but performance in Vision was better as well as we were not handling as many NDI input streams. It kind of "just so happened" that this also worked with the alpha channel from the image assigned to Texture 😂

It is a little confusing... when Use Alpha Channel is not checked, then Vision will use the Alpha Texture (if one is present). If Use Alpha Channel is checked, then Vision will use the A from the RGBA image (ie; the alpha channel) instead. This was mainly a hold over from older versions of Vision which did not support using the A from the RGBA image; in older versions the only option was Alpha Texture. This post has brought up some interesting topics and talking points, though! I think I can bring some of these ideas to my next meeting. Thanks again for your feedback @Jesse Cogswell 🙂

It might be a pain, but maybe if you select the broken fixture(s) in the Scene Graph, right click it, and select Replace Selected Fixtures... you could select the exact same make/model to get it to "recreate" the fixture in place? You may even be able to get away with deleting the broken fixture and then undoing it 😛 No guarantees any of this will work, but some odd ball ideas from the code itself 🤣