bbudzon

This has been removed. I'll wait for someone more familiar with Spotlight to chime in, but basically we have new fields in 2020 that must be used in order for ESC/MVR exports to export properly.

I'm looking at the SGM Palco 5 and the SGM Palco 3 (these are the display names that should show up in the Fixture Mode / Vision). We may need to tie @Mark Eli in here as he handles our fixture personalities. From what I can see though, it looks like channel 1 controls both the strobe and the zoom, which doesn't seem quite right 😛 So, I'm assuming I'm reading the content wrong. Perhaps you could verify this? In theory, if you're sending 255 to channel 2 (the dimmer channel) and you send DMX values between 8-15 to channel 1, it should have a narrow zoom (5 degs) and the strobe will be in the On state. If you're sending 255 to channel 2 (the dimmer channel) and you send DMX values between 200-223 to channel 1, it should have a wide zoom (8 degs) and the strobe will be in the On state. Now that I'm typing this out, it may be that this is how the fixture is designed. Hard for me to say as I'm just a code monkey 🤣 Hopefully @Mark Eli can chime in and help get things rolling!

Attachments aren't quite working and until they work better we should probably remove the UI. From what I can tell looking at that fixture, it accepts DMX in the range of 0-255 on it's first channel for controlling zoom. Keep in mind that VW doesn't handle DMX for movers but Vision requires it.

Just for completeness, I'll post here as well. If anyone is experiencing this issue, please update to VW 2020 SP2 as a fix went into this build 😉 VB-165306 Some lighting devices won't accept a manually-applied fixture mode If you're still having issues, we'll try to track it down!

I'm not sure if this is a separate issue or not, but please make sure you are running VW 2020 SP2 as this fix went into the build 😉 VB-165306 Some lighting devices won't accept a manually-applied fixture mode

It's hard to say, but my money is on the Fixture Mode not being properly set 😉 Usually if a fixture comes over to Vision as just raw geometry, it is a result of the Fixture Mode not being set in VW.

I'm not sure if you were able to use the new Rotate 3D Menu command to solve this workflow issue or not. But if you were, I'm glad that I was able to get that feature in to make things easy for you! (The new Move and Rotate 3D menu commands are so incredibly powerful in Vision as they allow you to perform arithmetic on multiple objects where you could not before! My favorite example is taking all trusses at various trim heights and "adding 5 feet of trim" to them all. Previously, this was not possible in Vision as you could only assign all sticks of truss to be at a height of 5 feet! 😛)

😛 No worries! I'm glad you go the brightness figured out. FWIW, I would _highly_ recommend tweaking your Application and Document settings to get better performance. It is obvious that this comes at the cost of quality. So finding a sweet spot is very much a personal preference 😉 Some of the biggest offenders of performance are: Resolution Quality Haze Quality Haze Style Render Shadows Shadow Quality Render Fixtures Surface Light Quality Dynamic Shadows Edit: Oh, one more thing. This is not always ideal but it IS an option nevertheless. If you have lights that are hurting performance but you don't necessarily need beams out of them, you can flag all of these fixtures via multiple selection as "Emissive" via the "Force Emissive" option. The best example of this is usually blinders as they are not casting light onto the stage but rather the audience. As such, these lights generally don't need to cast light/beams but simply need to "blow out" the rendering (ie; blinding the camera/eye/audience with light). This emissive intensity can be controlled via the Bloom Lens Strength option. I generally recommend keeping Bloom Percentage and Bloom Threshold at 1 and 1 (only adjust the Bloom Lens Strength value to get bright lens bloom).

@Monkeypuzzle, I have an older MBP running 10.14. I have the "automatic graphics switching" enabled in the Energy Saver settings. I usually run with external monitors hooked up though which forces OSX to use my AMD card always as opposed to my builtin Intel. I also have a program called gfxSwitcher that lets me force certain cards when they would not be used otherwise. https://gfx.io/ If you want to increase the overall light output of fixtures, it is generally recommended that you increase your exposure value. This may result in you needing to lower than ambient intensity for the room to remain "dark". Edit: Just to be clear, you are talking about both "surface light" and "beams" not being bright enough? If this is true, exposure is the key. If you would like only the beams to appear brighter/thicker, you could adjust some of the Haze Intensity values to pump up the fog 😉

You may have hit a point in which ESC may be better than MVR. Let me explain... The ESC File Format is Vision specific. No other program in the world can read it, including VW. VW is the only program I am aware of that can export ESC as well (Vision cannot, as odd as this may seem). My point in all of this is that because the ESC exported from VW can only go to Vision, VW can do "special Vision stuff" at export time. This means you can control exports in VW through things like the the fixture type being set to Moving Light. The MVR File Format is generic. Any program that supports MVR can import it. Any program that supports MVR could also export it. My point here is that because MVR can be sent to any program, VW cannot do "special Vision stuff" at export time. This means you cannot control exports in VW through things like the fixture type being set to Moving Light. Looking at it another way, VW flips Moving Lights during ESC export. So the lights are actually flipped inside of the ESC. Vision does not do any flipping at import time for ESC because VW already did the "flipping". Because VW could not do this for MVR (and because we haven't fully implemented GDTF in Vision), we had to implement the "flip" at import time in Vision instead of export time in VW. The downside to this is that you lose control over each individual fixture being flipped or not. (Note: It may not be obvious, but once we get GDTF reading properly in Vision most of these issues go away.) My suggestion would be to either use a mix of ESC and MVR, or use MVR entirely and use the new Rotate 3D menu command to fix all disoriented fixtures in (more or less) a single click.

I'm glad that you managed to get things working! FWIW, I downloaded your zip, launched Vision 2020 SP2, clicked File->Open, navigated to your MVR, and opened it with default MVR Import options. All of the color temperatures seemed to be correct.

If you select a light that is "white", what is it's color temperature in the Property Window? If you select a light that is "amber", what it it's color temperature in the Property Window? It's been a while since I've seen this. Perhaps you could post/pm this file as well and we can see if we can reproduce and see what problems may exist in the code.

Would you mind posting your file or pm'ing it to me?

Just to be clear, the Software Console that exists inside of Vision is intended to control conventional fixtures. Think of it like a stage hand. If you'd like to control movers, you will need to do as Rob says and hook up a light board such as MA. Once your light board is patched and matching Vision, make sure your DMX Provider in Vision is set accordingly. Once that is all taken care of you should be good to go!

You absolutely should!! There are only a few select cases (namely things like lamp rotations on a conventional) where ESC is recommended. Check out my post for more details!

No worries! I'll have to defer to @Mark Eli on this one as he handles more of the fixture profile side of things. If he has trouble getting things to "sync up" with MA and he believes the profile/personality is correct on both sides, he can bug me and point me to a spot in the code where things may be breaking down 😉

Took a look at your file. Very cool!! I think the issue you are running into may be related to our content. - The DTS Raptor has an appropriate candela value of 33,750,000. So, it appears accordingly "bright". - However, the pixie beam is showing up as 6345 candela. Based on my calculations (11120 lux @ 3 meters), the candela value should be closer to 100080. - Similarly, the DTS Katana is showing up as 10,000 candela. But, based on my calculations (9600 lumens @ 30 degrees), the candela value should be closer to 44840. Good news is Vision's multiple selections are getting better and better with each passing year. If you simply select the Pixie Beam "Fixture Group" in the Scene Graph, updating one Pixie Beam candela value should update them all. Same applies to the DTS Katana. (Note: I'll also ping @Mark Eli on this, as he would be able to determine if the content needs updated, and if so he can push out a content update that can be pulled down with the Vision Updater! This way, you won't have to make adjustments in Vision but things will just come over properly!) The only issue I wasn't able to figure out was the magic panel. There are two parts in the backend for this fixture; the lenses that glow on the face of the fixture and the beam of light that it casts into the scene. It appears that this fixture has been broken going all the way back to Vision 2018 (which means it's likely been this way since Vision 4). Thank you very much for pointing this out and we will see if we can figure out what is going on!

I've seen two issues related to mouse clicks. One is clicking in the viewport and the other is clicking UI elements. It seems like the issue you are experiencing is with UI elements. I think we have a ticket internally for the viewport but not for the UI. One deep rooted design choice that was made well before VW acquired ESPVision is that our renderer runs in the same thread as the UI. This means that when the rendering slows down, the UI does as well. We've been meaning to address this for some time but I'm not sure management has placed a proper priority on this. I'll pass your information along in our next meeting. The more users that are experiencing this, the more of a priority this issue will receive!

Once a VW document is sent to Vision, Vision has the ability to convert any mesh to an RGB Emissive. This mesh must be given a candela, a universe, and a channel. These can be applied via Vision's multiple selection. http://app-help.vectorworks.net/2020/Vision/index.htm#t=2020_Vision%2FVision%2FThe_Properties_palette.htm (See Object and fixture parameters -> Emissive (Objects only)) The downsides to this workflow primarily involve a difficult patch workflow and the potential for a new Send to Vision to "wipe" your changes. There is definitely room for improvement for custom geometry emissives, but our solution involves supporting custom fixtures via GDTF rather than reworking this old behavior. The new GDTF workflow will not suffer from patching difficulties and will also allow you to set things up in VW so your changes aren't "trashed" when sending to Vision. I hope our current solution works well enough for you for now. In the hopefully not so distant future, Vision will support more customized fixtures via GDTF and then we could revisit this!

The easiest way to make a large quantity of RGB Emissives is to use the 1in generic emissive RGB sphere in Vision. You can set this up in VW by selecting 1in generic RGB sphere in the Other dialog for Fixture Mode (ideally the VW symbol for this fixture will be a 1in sphere as well as this allows for proper positioning of the instance). Then, you can distribute along array or any other number of ways to duplicate this device in your document. The alternative workflow (which allows custom geometry) is not as clean of a workflow, but it is possible.

If you are talking about creating a rendered movie from Vision via a DMX Recording, we always write our videos out as MPEG-1. We've recently discovered this is what is causing a crash when rendering at a resolution of 4096x2160 as MPEG-1 only supports up to 4095x4095 (ie; our height was one pixel too tall for the codec). We're going to remove this option for now, but would like to investigate other export formats. If you have any suggestions/insights that would be great! If you are talking about reading a video file off of disk for playback in Vision, the generally consensus has been "If the OS can play it, we can play it." I'm not very familiar with the code that handles this as it was written well before my time. But if we need to support better codecs here, it would be good to know that customers would like it investigated!

@TomWhiteLight hit the nail on the head here. What you want to be looking at are DMX XForms in Vision. The help contains valuable information such as what our profile/personality looks like for controlling various features of DMX XForms in Vision. Generally speaking, each input should show up as a unique entry in the Video Input dialog. There are a few ways to go about doing this, but the simplest way of doing this from inside of Vision itself is to simply select a mesh/object and then right clicking in the viewport to get the context menu. There will be an Assign Video Inputs option. This will spawn a dialog with all available UVC Devices (ie; webcams, capture cards) and NDI Streams.

We actually do not officially support merging v3s files. That being said, there is a hacky work around... If you open a v3s and copy the items you want, you can then open notepad/textedit and paste "v3s-like" content into it. If you now open a new v3s, you can then copy everything in notepad/textedit and paste into Vision. I tried this and it worked for me, but again this is not officially supported so I cannot guarantee it will work. I will bring up v3s merging in one of our meetings so we can see how we want to go about approaching it. One easy thing we could probably do is just not clear the clipboard when opening new files. This way, you could simply open a v3s, copy, open another v3s, paste 😉

Most rendering engines do something called "face culling" for performance reasons. Essentially, what this boils down to is: in the real world, you can never see more than 3 sides of a cube. This is true for rendering as well. When Face Culling is Off in Vision, we render all 6 sides. When Face Culling in On, we only render the 3 visible camera-facing sides. Face Culling relies on Winding Order. Winding order specifies whether the 3 vertices that make up a triangle are wound CW or CCW. Flip Winding Order converts CW to CCW and visa versa 😉 Truth be told, because our engine uses something called deferred rendering, Face Culling doesn't seem to make THAT much of a difference in performance. Due to some bugs with VW winding order, we generally just leave "Face Culling" turned off 🙂

Was pouring over old posts and forgot about this one. Get out there and download 2020! We've added a "Replace Selected Fixtures" to Vision's Scene Graph Dock Context Menu 😄 One thing I do want to point out is that even though we added this feature to Vision, you should try your best to always make your changes in VW and leverage the MVR workflow. I understand this isn't always possible which is why we wanted to add in the feature. But if you make this change in Vision and then send your document from VW to Vision it will trash these changes! Just forewarning!! 😛