bbudzon

Agreed! And I'm sure you've likely seen this already. But, here is a great article I worked on with our Tech Pubs team regarding texturing in VW for Vision 2021+. We leveraged these techniques in our 2021 Demo File. So, that VWX and VSN is a good example of this article in practice. In reality, these practices are good to follow anytime you are exporting a 3DS/glTF/MVR to any other program. A lot of the testing I did involved Blender as an unbiased third party source. It's definitely a good read, but it's a little dense and may take a few passes to fully parse and grasp the concepts. Some things appear subtle or minor, but all of it is incredibly important. Feel free to ask questions in that thread if any come up!

Good! I'm glad it's working for you and I hope the whole process/procedure makes sense. I recently answered a similar question on the forums and they suggested we try to document this somehow. I'm going to try to work with our Technical Publications team to see if there's a way we can incorporate this into our help or something.

If that is what your VWX looks like in shaded mode with a 2514x1200 image applied, then Vision should render the same way when provided a 2514x1200 NDI Stream. One thing you might try as a debugging step, just to eliminate NDI from the equation, is removing the Video Source on the VW side. If you do this and send the file to Vision, Vision should render the same still image that VW renders in Shaded Mode. If Vision does not look like VW when using the same still image texture in both programs, then we need to figure that out first (and once we do the NDI stream should "just work" when we get back to trying it).

The problem here is the texture you have applied to the blended screen in VW. When I test NDI in Vision, I try to always verify a still image displays correctly in VW Shaded Mode first. I usually use a color bar test image so it is easy to see where the corners lie. So, if I insert a 16:9 television in VW, I make sure to apply the 16:9 color bar test texture from the default content. I then verify the Shaded Mode rendering in VW and proceed to Vision. Once you assign an NDI stream, which is also 16:9, it will render correctly in Vision. 1920 / 1080 = 1.777 16 / 9 = 1.777 2514 / 1200 = 2.095 I'm not sure what aspect ratio 2.095 is 😂 But 16:9 expressed as a float is 1.777. I would suggest you create a custom image with a resolution of 2514 x 1200 and paint the corners so it is like a test image. Then, apply this to your blended screen in VW and adjust the texture mapping until you are happy with the result. When you send this to Vision and apply a 2514 x 1200 NDI stream, you should then get a proper result that matches what you see in VW.

I'm glad it helped!! It took me a little bit to figure it out as well I didn't think changing the texture in VW would have that sort of effect. It's fairly simple with the easier cases where it's a well defined aspect ratio such as 4:3 or 16:9. I'm not the best with the texture tool in VW. So, the more bizarre / custom situations still baffle me a bit 😛 And I'll pass this information along to our Technical Publications team as well to see if we can find a way to better document this. Thanks!

DMX Rotation "in place" is definitely one of the harder types of XForms to do in Vision. This is because it relies on the insertion point in VW. So, if the insertion point on a stick of truss is at its end and not its center, then a DMX Rotation will rotate the truss around its end and not its center. Some workarounds exist which involve creating a new layer, putting the truss inside of that layer, and then doing the DMX Rotation on the trusses new parent layer. But, this can be a little difficult. Hopefully, it is possible in your case to ensure the insertion point in VW is the point that you want to rotate around. If you apply a DMX Rotation to the entire MVR layer, the one which contains the entire set, then the entire set will rotate. If you only want parts of the set to rotate, you need to apply the DMX Rotation to just those parts. I hope that makes sense. Try playing around with it a little more and if you're still struggling, let me know.

The best way to do it is to ensure that proper texture mapping exists on the VW side before export. The way that I normally do this with televisions is selecting an image texture from the default content that matches the televisions aspect ratio. So, if my television screen is 16:9, I make sure that I select the 16x9 Color Bar Test image in VW as it's image. If you enter shaded mode, you should see that the color bar test image is "mapped" correctly to the television screen and that all corners of the image are where you expect and no tiling is occurring. When you send this to Vision, Vision will be able to then render a 16:9 video or NDI stream to this television screen perfectly and without distortion as the texture mapping is correct from VW and the aspect ratio of the texture mapping matches that of the source video input. It took me a while to figure this stuff out in the past myself. I hope this helps and makes sense. The key, really, is getting VW to look right in shaded mode before the export to Vision when using an image in VW that is the same aspect ratio as the video or NDI stream in Vision.

Sorry it took me so long to get around to trying to reproduce this. Could you maybe post your file? I just tried with litfiles and GDTF and both worked on the first try after launching Vision from scratch with Render Fixtures set to Off. I wonder if it is some setting in your document or perhaps the specific GDTF you are using. It may also be worth posting a screenshot of your Vision Preferences (the application settings dialog for rendering quality that has the Performance / Quality slider, not the document settings dialog). Thanks!

Correct! You can input/receive an unlimited number of NDI streams. When we were implementing outputting/sending NDI streams out of Vision, we felt it was only necessary at that time to output the "main" viewport (as described above). I hope this answers your question!

Can you confirm which SP of 2023 you are running? If you could post a screenshot of the About Vision dialog, that would be helpful too as it includes the build number. Thanks!

I'm not sure if this answer your question, but there isn't any licensing restrictions for NDI Output out of Vision. There are functional restrictions, however. What I mean by this is that if you check the "Send NDI Stream" checkbox, the only stream Vision can send is a stream of the "main" viewport. In single viewport mode, this is the only viewport. In multi-view mode, it is the bottom right viewport. This was primarily implemented to work with Disguise's EVO feature. But, you could also leverage NDI Output out of VIsion to, say, stream realtime Vision rendering to another computer or television. If you are asking about receiving NDI Streams into Vision, then yes; there are licensing restrictions. You get as many NDI Input Streams into Vision as you have DMX Universes in your license. Other than that, it is not restricted in any way functionally. So, you can apply those NDI Streams as textures in your scene however you'd like.

It is hard to say from your post if this is the same issue or a new one. The fix mentioned in this thread only ensured that we do not crash if the name of a texture in a VWX starts `*`. Perhaps, you could post your VWX for us to test with internally and try to reproduce?

When you installed Vision on the Mac Pro, you should've been given an option to provide a serial number. If you did, then Vision should spawn a dialog at startup that requests that you Activate the license. That is all that should be required. If you installed Vision without providing a serial number, then you can launch into Demo Mode and go into the Vision Preferences. In there, is a Session tab. Here, you can provide your serial number. Vision will likely spawn a dialog that asks you to Activate the license, which is required to get things working. If you are having trouble inserting your serial number into Vision or activating your license, you can try contacting VW Tech Support. They should be able to help you further. I hope this helps!

Interesting... that definitely seems like a bug! I'll try to investigate and see if I can tell what is going on. Thanks for following up!

It can get a little confusing at times having the different gobo and color options. The main reason we separated the "previz" gobos and colors is because previz supports multiple gobo wheels (with multiple gobos for each wheel) and the same with colors and color wheels. If you're working with previz, it can be advantageous to set all of this up on the VW side. But, if you're not working with previz, it can become cumbersome and a simpler UI beneficial. Apologies for the confusion, but glad it all makes sense now!

No problem! But, be very careful adjust "tilt" that way. I do not believe it saves into the document and so it will "reset" the next time you open the file. Just to reiterate, you should never really modify anything inside of the fixture's scene graph like that in Vision. So much so, that we've had many internal discussions about disabling the expansion arrow. If you want to pan or tilt a fixture, you should use a Focus Point in VW before sending to Vision, the arrow keys inside of Vision, or rotate the entire fixture at the top most level.

Ahhh, yea this was the issue! Sorry I didn't see this the first time around. You should never go inside of a fixture like that and modify things in Vision. We've deeply considered removing the expansion arrow so that this just isn't possible even if you try. The three options you have are: Set up a Focus Point in VW. This should come over to Vision whether you use ESC or MVR. Rotate the entire fixture to get the beam / surface light pointed where you'd like. Use the arrow keys and or the Focus Selected Lights Here context menu to get the beam / surface light pointed where you'd like. Note: I'm not a fan of our Focus Selected Lights Here implementation. So, I'd recommend the arrow keys in that approach. And, if you decide to use the arrow keys to focus the lighting device, make sure that the "mouse focus" is in the viewport. I usually do this by right clicking in the viewport and then clicking somewhere to "cancel" the context menu.

Hmm... that does seem odd! When I opened your VSN file, the fixture geometry and the beam were all pointed up: I wanted to make sure that they rotated correct, both beam and geometry, when I modified the rotational values in the Properties Window. It worked as I expected: My only suggestion is that you try to ensure that you have the proper item selected in the Scene Graph when modifying the rotational values in the Properties Window. It is okay to modify a Fixture Group, as I have done in my screenshots above. And, it is okay to modify an individual fixture. But, the rotational stuff will break if you go inside of the fixture and start rotating its internal parts (you could think of this like modifying the symbol in VW). I hope you figure out what is going on or what steps we might take to reproduce the issue so we can investigate further.

Color should work with ESC, but it does not yet work with MVR. Make sure that you are assigning the Color in VW in the appropriate area for Vision: This is the result in Vision: All tests were run in VW/Vision 2023. I've also attached the VWX and ESC to this post for your reference. colorTest.esc colorTest.vwx

That's definitely an interesting use case and one where I can see that being valuable! Appreciate you explaining your workflow. It makes it that much more relatable when discussing the issue with others. Thanks, again!

The fixture speed is hard coded in the content and should be accurate. If it is not, I would like to see a bug opened to address the issue. That being said, some fixtures support an MSpeed that is controlled via DMX. I could be wrong, but I always thought this MSpeed to stand for Motor Speed. You can send various DMX values to the MSpeed channel of the fixture and it will increase/decrease the motor speed accordingly. For example, the Robe Wash 250 XT in Mode 1 has a "Speed of PAN/TILT movement" on Channel 5; where 0 is max speed and 249 is min speed. I hope this helps! And if you've found fixtures which do not support the MSpeed or just generally do not pan/tilt/zoom/iris at the proper speeds, contact Technical Support and let them know the make/models and we can have our content team investigate the values that are being used.

Vision currently does not support custom texturing on Lighting Devices. You did do the right thing by turning Render Fixtures to On. But, that will just render our hardcoded textures; which is still arguably better quality wise than forcing fixtures to black 😛 But yea, Vision does not support the functionality that you are trying to accomplish with those custom textures. That being said, there was no real reason behind this restriction. We mostly noticed that fixtures almost always had no textures. And, so forcing the hard coded ones was not an issue. I can bring this up in some of our internal meetings and see what it might take to expose/handle more custom textures for Lighting Devices.

Unfortunately, GDTF fixtures must be patched in VW as this cannot yet be done in Vision. A big part of this reasoning was technical limitations in the Vision UI for handling DMX Breaks, which GDTF supports but Vision does not. I always suggest that all changes to the document be made in VW as opposed to Vision. But, sometimes this is unavoidable. If you must update the patch of a GDTF in an existing VSN file, I suggest updating the patch in VW and exporting only that fixture to an MVR. You can then merge this MVR into the VSN document to pull in the new patch information. Because MVR contains UUIDs, it will ensure that you don't end up with duplicated fixtures.

I apologize as I had not provided an update on this. This issue should be resolved with Vision 2023 SP2. Keep an eye out for that release. EDIT: Just to clarify, for technical reasons this feature is only supported on PC. The framework we use does not allow web palettes on MacOS. So, until our third party framework resolves that issue, we cannot proceed with supporting this feature on Mac operating systems.

It sound like you are using procedurally generated renderworks textures. VW does not support exporting these types of textures into any file format as far as I'm aware. So, any program that opens these files will not be capable of rendering them. This is more of a limitation of VW than Vision. Whenever you are planning on exporting a file with textures out of VW, you should follow some guidelines we've created: While this guide is aimed at exporting to Vision, this really applies to exporting to any other program. A few things to note: Vision does not support partial transparency. Pixels of a texture are either fully transparent or fully opaque. Essentially, this is an alpha mask. So, something like opaque glass isn't possible as opaque glass is both opaque and transparent. Also, the best way to do scrim is with an alpha mask that is mostly opaque, but has some small "holes" in it. We leveraged this tactic / technique in our Vision 2021 Demo file. The texture we used for the VW Transparency Image Mask is this one: There is a LOT of information packed into that guide I linked. So, it may take some time to digest all of it. If you have any questions about the guide, please make a comment in that post and we'll do our best to answer there. This way, other forum users will benefit from the questions/answers/knowledge. Hope this helps!