bbudzon

Historically, Vision has had separate licenses for 1, 2, 4, and unlimited universes. But, I think they did away with some of these. IIRC, it's now just 4 and unlimited. But, I'd have to check with someone who knows the licensing better to confirm. Could you take a screenshot of the About Vision dialog and post it here? That will have some of the license information which I can pass along and try to get you a response as to how many universes you have unlocked.

How many universes are you trying to use? Is it possible that the 1/3 that is working is all located in, say, Universe 1 and the other 2/3s is in a different universe?

Yea, this is a tough situation. The only control you really have over the perceived brightness in this case is the Bloom Lens Strength and Exposure. But, these effect all lighting devices, not just the ACME Pixel Lines. The only code solution I can think of that doesn't run into technical limitations is exposing a Bloom Lens Strength value for each lighting device as well. Then, you could turn up just the bloom effect on these particular lights to get a brighter appearance. I also had never considered the "highlight" case you talk about. It shouldn't, in theory, be too tough to implement an application preference for that. Lastly, I'd like to investigate this file or this fixture in more detail when I can find some time. It also fully locked my machine up when I selected all 148 of them, which didn't necessarily surprise me given one of these devices has 48(??) lamps in our content (for a total of 7104 lamps). What DID surprise me, however, was MacOS reported something like 150GB of memory usage at the time of the lockup... which is alarming to say the least. I do think I had my settings cranked to max; meaning the light mask image was 2048x2048. So, that probably played into it. But, nevertheless, I just want to make sure we're not leaking memory or anything.

I'm not super familiar with some of the industry terminology. So, I hope I'm answering your question correctly. 1) If there is no MA hardware and you have the USB dongle, then you should have no problems driving the fixtures in Vision from the MAonPC software console. 2) To get more information about the Vectorworks Vision Dongle for MA2Net, I would suggest you reach out to your Vectorworks Distributor. They should be able to help you with pricing and different options. If you run into any trouble, let me know and I'll try to get you directed to someone who can help further.

Yup! The MAonPC for GrandMA2, which uses MA2Net, is entirely software based. It, again, does require a small usb dongle that must be purchased from Vectorworks. There is something similar for GrandMA3. They have an entirely software based console which uses MA3Net. This, however, requires a usb dongle that must be purchased from GrandMA (not Vectorworks). I hope this helps!

I think this video will answer your questions. It is possible to connect the GrandMA2 MAonPC Software Console to Vision, but you must have purchased the appropriate Vision license dongle from Vectorworks to unlock this functionality. https://university.vectorworks.net/course/info.php?id=578

If not sure if you are running into this issue or not. But, you mentioned that the lamp is always on. I just wanted to point out that if the lighting device is selected in the Scene Graph, it will force the dimmer to 100%.

So, I realize now why you're not getting the option to insert the color like you'd expect. These fixture modes are, what I refer to as, multi-part fixtures. The problem with a multi-part is that every part can have its own color. And both the VW and Vision UI doesn't support this level of dynamic interfacing. I talked with one of our content guys and their suggestion was that, if you cannot use the color as-is, you try swapping your fixture out for either a 3 cell that is a single circuit or 3 single cell fixtures. Because these fixture modes are not multi-parts, the UI that you need should be exposed and you should be able to set the color you desire. My apologies for the inconvenience! I hope you are able to work around this issue. We'll have to think about our UI and how we might be able to handle this better in the future.

If you can tell me what your Fixture Mode is set to, I can look at the content and tell you what color options are supported by the device. My guess is that the selected device does not have Color Wheels and only supports RGB/CMY color mixing via DMX.

Both very good points! Many users of Vision struggle to understand why an NDI stream doesn't need to be 4K and it is precisely the reason you state. Often times, the overall size of the rendering onto the monitor is relatively small. A lower resolution, like 720p or even lower, is often adequate and much better for performance. Also, I hadn't considered an "update on user input" option. One perhaps like sheet layer viewports where you can select an iMag camera and click an "Update" button in the OIP that would trigger the rendering. This would likely integrate much better with renderworks, redshift, twin motion, etc. And, it would also address performance concerns as you would get to choose when to do the update. I guess some of this might be possible with current versions of Vectorworks and the enhancement being discussed here would just streamline that workflow.

This is an interesting idea / request for Vectorworks! One quick thing I want to point out is that because Vectorworks doesn't render in realtime, using anything like NDI would not be possible. If, however, NDI was supported in VW, you could "farm out" these renderings to other machines on your local network. So, you could have the same VWX open on 4 machines, 3 of them rendering "iMag cameras" output over NDI and the main machine could receive those NDI streams for rendering onto a monitor in the primary view pane. This would significantly reduce the performance issues, but I haven't given a lot of thought as to how it might affect or integrate with things like FQRW, redshift, or twin motion. Anyway, let's move on and away from NDI; assuming this is all happening on a single machine. In Shaded mode, it might actually be fairly fast as Shaded mode can generally render the scene from different points of view quite quickly. Take, for example, the navigation tools. The framerate while panning, zooming, or using the flyover tool is quite good. So, having to render the scene multiple times from different iMag cameras likely wouldn't have a huge impact. At worst, it would half or quarter the framerate while navigating. But, we could also special case navigation in the code so that it only updates the iMag screens once navigation has stopped. The bigger issue would be with render modes like FQRW. If you had 3 iMag cameras displaying on 3 monitors/screens (which seems like a fairly reasonable use case), the scene would need to be rendered 4 times (once for each iMag camera and once for the view pane). FQRW is very high quality, but does take some time as it is. Tripling the render time here may not be acceptable to some, but I guess they could always just not use this feature or reduce the number of iMag cameras in use. For example, a single iMag camera displayed on 3 monitors is much more performance friendly that 3 iMag cameras on 3 monitors. The only other complication with this feature is its integration into things like redshift or twin motion. I'm sure it would be possible, but I'm not super familiar with these as I work primarily on Vision and am not even sure where to start regarding this portion of the discussion. There may be technical limitations that prevent these integrations from working with iMag entirely. Either way, a pretty neat idea!

I think safe mode is harder to trigger on PC than on Mac. But, the way I would try to do it is by opening task manager and forcefully ending the task. Vision basically writes a flag out when it closes successfully called "CleanExit". If "CleanExit" is set, then we do not spawn into safe mode. If "CleanExit" is not set, then we assume that Vision crashed and ask the user if they would like to spawn into safe mode as a result. If you cannot get the DMX Recorder back into a location where you can see it on the monitor, we might be able to work together on nuking some registry key entries to get safe mode to spawn. Safe mode, when entered, clears out ALL user settings; including the last position of the DMX Recorder window. So, in theory, if we can get it to boot into safe mode, we can reset all windows positions back to their defaults.

You can download SP1 here: https://release.vectorworks.net/nnapub/all/2023/SP1/672714/NNA/eng/installer1/Vision2023-672714-installer1-osx.dmg https://release.vectorworks.net/nnapub/all/2023/SP1/672714/NNA/eng/installer1/Vision2023-672714-installer1-win.exe

We believe we found the issue in the code and are testing a fix now. If and when the fix is made public, I will post here.

I am able to reproduce this issue with both the 3DS and glTF backed MVRs. This leads me to believe the issue is not with the 3DS/glTF/MVR plugins, but rather an issue down in the core with the UVs the tessellator is giving us. One workaround would be to export your wall as an OBJ and merge that OBJ into Vision. The reason this works is because the OBJ exporter uses a different mechanism for exporting UVs and geometry (one that unfortunately does not work with MVR as it can only export the entire scene and not individual objects). I'll bring this issue with 3DS and glTF to the attention of the core team.

It looks like VSN worked in 2023 SP1 but broke in 2023 SP2. I'm working on narrowing down the code change that caused the issue. You can continue using V3S or fallback to SP1 to work around this issue until we get it fixed. Sorry for the inconvenience.

I did just see a similar thing. V3S works. VSN does not. This is probably a good sign that points to the bug being a little easier to fix, as this implies that Vision does still have the textures after loading the MVR. If the V3S failed, it might imply that we somehow failed to "record" the textures in RAM and thus failed to write them to disk. I'll have to pick up further investigations tomorrow.

I like the way you're thinking! 😅 I'll make sure to run some more basic tests myself as well and also loop QA into this issue for additional testing. It's kind of good, in a weird way, that multiple people are experiencing this issue. Just means we are probably more likely to reproduce it in house. And, it's always easiest to fix a bug when you can step through the code line by line and watch it happen.

It might also be worth asking if you guys are only running into this issue with "complex" files; meaning ones with many many textures. Do you find that importing MVR and saving a VSN works in the simpler cases where, say, they are only a dozen textures?

I have some MVRs that were private messaged to me for testing. I'm going to try to reproduce the issue and debug it in the code. If I have trouble reproducing with their MVRs, I might ask for yours. Either way, I'll make sure to post updates here. One possible workaround for you guys, @DBLDand @TVTechTyler, would be to save the file as a V3S instead of a VSN. This can be done by exporting to the "legacy" file format from the file menu. Actually... this would be a really interesting test for you guys to perform. If it does not break when exporting to V3S but it does break when saving as a VSN, it might narrow things down in the code for me quite a bit.

One thing that is particularly odd, in my mind, is the default content from Vision such as the drummer. These textures should always exist on disk in the installation folder and if VIsion ever fails to find a texture inside of the VSN, it should reach out to disk and search the install folder for the appropriate drummer texture (which should, in theory, never fail as it should always be present). Furthermore, the default content such as the drummer doesn't really use any super advanced texturing or anything. So, I don't believe it should matter if the Texture Quality is set to Very Low, Low, Medium, High, or Very High. The drummer texturing should render regardless of that level. Could you post your VSN file or send it via DM for us to take a look? Thanks!

Yea, the render still and render movie functions do not handle bloom in this scenario. It is a technical limitation that we would like to address for sure! Frankly, it is just surprising from a user standpoint when it works sometimes but doesn't work other times.

It is odd that your pan and tilt would be working over DMX but the dimmer would not. I would try your best to make sure you are using the proper fixture personalities/modes in both Vision and the light console as this is the most likely cause. If you continue running into issues, you can contact VW Technical Support or might be able to post your VSN here. If we can reproduce the issue in-house, we should be able to fix the code or content.

Yup, @ASalien got it! You may need to ensure your document preference dialog is in "advanced" mode to uncheck the box. But, I believe you had to already be in advanced mode to check it in the first place 😄 Hope these posts have helped you!

Vision, unfortunately, does not support transparency. It only supports alpha masking right now. If you look at our 2021 demo file, you will see an example / work around to this issue. We basically made an alpha mask that put a bunch of tiny holes in the mesh. This allowed you to see through it somewhat and also allowed light to shine through. Do note that higher levels of Texture Quality are required for Alpha Textures to take effect. Transparency is something we would like to add to Vision, but it is difficult to handle this with our deferred rendering technology. Transparency can also get quite complicated with many many lights; making it look right and not bad/fake can be tough. And of course, we always want to ensure new features we add don't negatively impact performance. I hope you find something that works for you! If you don't need real time rendering and are just trying to get a still image look together, you may consider using VW Renderworks as well as transparency is supported in that software.