bbudzon

hahahah sorry! I thought we were in the beta forums 😆 Essentially, I was trying to make sure this doesn't get lost by asking you to put it in our system. But just the other day I found it in our system! So, that is good! 😛 Now, we just need to work on collecting workflow information from users so we know we are going down the right path!

Unfortunately, this is something we haven't gotten around to handling in VW or Vision. You have found about the best workaround which is adjusting things on the VW side. While this could be done on the Vision side, it would have to be done every time you send an MVR to Vision. So, doing it in VW is ideal. I just talked with our team internally about this and we'd like to get a TO together. Would you mind maybe opening up a VE for this and any ideas you have for how you would like this workflow to behave? Some ideas we've thrown around internally is having a "marker" specifically for DMX Rotations. You could drag this "marker" around in VW to "adjust" the rotation point for Vision. Doing this in VW ensures that every time you Send to Vision, you get the result you want 😉 While technically, this would only be needed in VW, it would be nice to have the same UI/UX in Vision in the event you need to adjust something. (But I will say now, ALL adjustments should be done in VW! If you adjust a DMX Rotation in Vision and not VW, then the next Send to Vision will "wipe out" your changes! 😧 Always, whenever possible, make your changes in your VWX! 😄)

I'm not sure this helps at all, but I can see the workflow frustration here. Everytime you send to vision you have to keep "re-enabling" the "Force Emissive" option on your fixtures... It would be a nice enhancements request to be able to set this flag from VW when sending to vision. The only half way work around that I can think of is leveraging the MVR workflow and only exporting/merging necessary updates. If the Force Emissive fixtures in Vision are not contained in the MVR that is being merged, then they will be left alone in Vision and all other items will be "updated" to match the MVR. Hopefully this helps!

Can you email me your VWX?? I'll get it to the right people so they can take a look. I don't think it should be taking that long!

@Charlie Winter I think the issue you are running into at a conceptual level is that alpha masks are not created for geometries but for textures. So generally speaking, when looking at a regular image texture, you will see a spot that "should not be rendered". For example, if you are using an extrude as a truss it will just look like a box when no texture is applied. When you apply a regular image texture that looks like a truss, the box now LOOKS like a truss but light doesn't shine through it like a truss. This is where you would want to generate an alpha mask from the regular image to allow light to "shine through". But bear in mind, this is all being done at a texture level. There is also a concept for generating normal maps called "baking". I know this has nothing to do with alpha masks, but it might be something you are interested in or at the very least something that helps make alpha masks make more sense. The interesting thing about "baking" is that it DOES work on geometries. So essentially what happens is you make a high poly count and a low poly count model. You then "bake" the high poly count model into a normal map and apply the normal map to the low poly count model. This gives you incredible quality at the cost of very little performance (look at the Lion Head in the Sponza model for a good example of baking normal maps into low poly count models). All of this being said, I always want to help people take their Vision renderings "to the next level". Perhaps, if you post an example VWX I could help you work through the alpha masking of the arches? I'm sure users here in the forums would benefit from this as well!

Hmm, that is odd! Please ensure you are on the latest version of Vision. Also as a test - try using this capture card with a 3rd party application, such as Skype, on both machines; this will help narrow down where the issue resides.

Hmm, we have an option for inverting pan/tilt, but not zoom 😧 Perhaps, @Mark Eli or can chime in here? If the content just needs updated, it might be a quick fix.

Check out this post! MVR is pretty frickin' amazing, especially for VW/Vision users 😉

I'm glad you have video inputs working! I'd need to let someone who knows more about VW chime in here (I'm a Vision developer), but you can adjust texture scaling in your VWX on the VW side of things. If you are using MVR, you can simply export and overwrite the old MVR file and merge these changes via MVR into Vision. If you aren't using MVR, you should look into it!

I can say that I've successfully used my MBP WebCam along with a Capture Card to feed different screens different feeds at the same time. Perhaps, there is an issue with the drivers or something? If you have 2 capture cards plugged into your machine, do other programs like Skype see both capture cards? Is it only Vision that does not see them both?

With a simple extrude shape, you can select the extrude in VW and at the bottom of the OIP is a Name field. Populate that field with a unique Name and export an MVR. When this MVR is opened in Vision, the MeshShape should now have the unique Name entered in the VW OIP.

@fuberator There may be a few different things you can try. For starters, make sure you are using a very narrow beamed S4 such as a 5deg. Next, bump up your Surface Light Quality to High or Very High in the Application Settings. Next, ensure that Volumetric Quality is at 100% in the Application Settings. Next, try toggling between the old Volumetrics and the new Enhanced Volumetrics. Also, try playing with haze settings in general as "pockets" of haze may make it appear like the laser has "disappeared". Lastly, try making the pinhole in your gobo just a little bit bigger if you are still running into issues. It may just be that it is such a small beam that it turns "paper thin" at certain angles/distances/etc.

ZOMG @LJ TMS you are a life saver hahahahah I totally forgot we already had this!! Thank you for being such a knowledgable customer!!! 😄

I'm not sure that it is possible to send the Zoom value from VW to Vision. However, to control the Zoom of this fixture in Vision simply select the fixture in the Scene Graph Dock and then open Vision's Software Console. Inside of the console, you should see a slider for Zoom. I believe a value of 255 is 30deg 😉

Now that we have some customers attempting to do this, I will bring this use case up in our meeting. I'm going to ping @Mark Eli again as he is the one that makes fixtures for Vision. Unfortunately, Vision does not have a way to create/import custom fixtures. We are working on GDTF support in Vision such that you could create a fixture using the GDTF Fixture Builder, but that is not currently implemented. Hopefully, we can put a fixture in the Vision library for you and you can just fetch the content update and use the fixture we've created for you. Otherwise, the best option in your case may be to simply delete the MeshShapes inside of the specific fixture you want to have no geometry. This will not store off in the v3s which is a pain 😞 This also reminds me of a few other "features" that were considered but never implemented... perhaps I can bring these up in our meeting as well. One such feature was the ability to turn off geometry for a fixture at the fixture level (instead of at the global level). Other features that we may need to consider more seriously is the ability to control whether or not lights cast shadows at a fixture level (instead of at the global level). I'm sorry that this workflow isn't the best but you are in uncharted territory hahahah! I'll go with you where no man has gone before, but it may be a rough ride... which isn't to say we can't make this easier in a future release!!

Sorry, this is specific to the Vision application 😞 I just tried it in Vision 2019 and an optimization we made to Gobo/Color/Animation Wheels broke it! (It did work in Vision 2018, however.) This is why it was never a documented feature 😛 I do think I might know a way we can get it working again, but the reason is broke it was because what we were doing before was very VERY bad for performance. Optimizing the wheels so they only updated when necessary was critical to the performance increases you see with Vision 2019. We may still be able to special case this without hurting performance too bad 🙂 I'll have to dig in the code and see what we might be able to do. Then maybe we can support it for real and we can document it as an actual feature! 🤣 Nevertheless, for a static laser like the OP is trying to do, a pinhole gobo will still do the trick 😉

You're on the right track! Use a needlepoint gobo for sure. I'd also recommend picking a fixture with a very tight beam/field angle as this (in combination with the needle point gobo) will give you the most realistic result. (And even if you don't need to, try a video file in a S4 gobo sometime, it's really cool!!) It's a little complicated changing geometry of a fixture like you're suggesting, though. You can do it, but it won't get saved off in the file as Vision doesn't expect anyone to modify the fixture content like that. So, you'd have to do it every time you opened the file. Instead, my suggestion (if at all tolerable) is to simply turn off the rendering of all fixtures in your application settings. Unfortunately, this can't be done at a per fixture level and it is only a global setting for the entire document (something we are looking into). Fortunately, this drastically increases performance in Vision 2019 as well. This may be too specific of a request for @Mark Eli, but I'll tie him in just in case. We have some generic emissive spheres but they only glow (they don't emit light). Perhaps it would be good for us to have some generic no-geometry beam-fixtures for users to play around with when "hacking" up Vision to do cool/clever things like this 😄 The other example I had that came up with was creating a make-shift desk lamp in Vision. Having a "no-geometry beam-fixture" would be incredibly helpful in this case!

Very cool you're looking into this! One thing you may not have known (and may not be applicable in this case) is: just like you can use an image on your desktop for a gobo, you can actually use a video file as well. This can achieve some really cool projector/laser like effects. You're on the right track using a second light at the mirror to simulate the "bounce". My suggestion for controlling whether or not the beam is "on" is to simply use the dimmer channel. You could even patch both lights (the real light and the one at the mirror) to the same uni/chan so that they respond to DMX the same way 😉 Hope this helps and interested to see how far you get with this POC laser in Vision! (I've done this myself btw and gotten some pretty good results!)

🤣 I was worried this may be the case... My suggestion here would be to mix and match ESC and MVR to get the result you want. It seems like some things work in ESC and some things don't. Everything that does work in the ESC file format can be exported from VW into an ESC. Everything that doesn't work in the ESC file format can be exported from VW into an MVR. You can then open the ESC and Merge in the MVR (or open the MVR and Merge in the ESC, either way should work). Absolutely. ESC is an incredibly buggy file format and not worth repairing. It will be faster and we believe more beneficial to our End Users to bring MVR import up to snuff.

I have seen this before but not quite this bad 😧 Is this happening in both ESC and MVR??

If the issue is rotational, it may be easier to fix! A little background... VW models all fixtures, regardless of type, to be in the "hung position". Vision models all moving light fixtures in the "floor mounted position" and all other lights in the "hung" position. (...mostly... this is where a lot of discrepancies occur between the two products... VW has always has a standard for modeling fixtures, Vision has not) There are two ways these lights re-rotate to account for this discrepancy. 1. If you are using MVR, the flip happens at import time in Vision. You can try to uncheck the "Flip Moving Lights" checkbox. (Note: If this checkbox is needed for some lights but not others, try merging together two separate MVRs (one MVR that needs the "Flip Moving Lights" option checked and another MVR that needs it unchecked).) 2. If you are using ESC, this flip actually happens at export time rather than import time. In this case, the ESC Exporter checks to see if the type of the fixture in VW is "Moving Head". If it is, it gets flipped. If it is not, it does not get flipped. So you can play around with the fixture type in VW to control how lights are flipped in ESC 😉 I hope this helps!

Sometimes this is a rotational issue, but in this instance it does seem position based... I'd confirm that the X/Y/Z Position values in Vision (units of inches and Y is Up) align with X/Y/Z Position values in VW (Z is Up). You may need to convert between units of measurement here, but in my experience this usually comes over without issue. My guess is that the issue is differences between the VW/Vision content itself. If this is the case, you can possibly call up the tech support team or the fixture request team and see if they can get it resolved for you. In the meantime, Vision does KIND OF support multiple selection and in this case you may be able to leverage it. Let's assume that in VW the strobes have a Z-Height of 24 inches and they look correct in VW. Let's also assume that this came over to Vision "correctly" with a Y-Height of 24 inches: If all of your strobes in Vision are at 24 inches Y-Height and you need them to be "raised up" another foot, then you can select all of your strobes at 24 inches Y-Height and simply adjust one of the strobes in the Properties Palette to have a Y-Height of 36 inches. This should set all of the selected strobes to have a Y-Height of 36 inches. This was just an example, but hopefully you understand how you can leverage Vision's somewhat broken multiple selections to work around your issue.

This is where you get to see the nasty side of Vision... Vision was never designed to be localizable. Furthermore, the UI was not decoupled from the backend code. Lastly, Vision still does not have a file migrator. What this means is that the UI elements you see in the Property Window are the keys into the backend data for the file format. If we added the string "inches" or "in." or a single quote (to signify inches) to any UI element, it would break file backward compatibility. This wouldn't be an issue if we had a file migrator as we could export to an older format. While there are ways we can change the UI and the code such that this breakage does not occur, it is difficult. What I personally would like to do is to make the file migrator for Vision a much higher priority, despite it not *seeming* important for end users. Not having one prevents us from doing a lot of things and one of those things is adding units to UI fields in Vision 😞 Right now the only way is via the help system. We are looking to improve the What's This system for 2020 which will be nice. But ultimately, Vision needs a file migrator. Then we can start looking into changing UI in a way that would normally break backward compatibility. The next logical step from there is making the UI localizable so the UI text is fully decoupled from the backend data.

Vision's Properties Palette is always in units of inches when referring to distance 😉

Yup! This is the way the Sponza Demo File works if you take a look at that 😉I highly recommend playing around with the textures in VW/Vision to get a feel for things. You can use the images from the Sponza Demo File as a POC. I particularly find the plant textures from the sponza model interesting as they leverage alpha masks and rgb reflectivity maps!