Vectorworks, Inc Employee Popular Post bbudzon Posted March 20, 2019 Vectorworks, Inc Employee Popular Post Share Posted March 20, 2019 I just wanted to take a moment aside to stress the importance of using MVR moving forward when exporting from VW to Vision 🙂 MVR has solved a LOT of issues for us with the Vision application. ==============================  - For starters, ESC files always had a textures folder next to it which was annoying. MVR has everything baked into the file so no more lugging around extra files/folders like you had to in the past when sharing ESCs!  - Next up is the improved rendering quality. Because the MVR file format uses a more standardize backend for its geometry, we can use 3rd party libraries to correct some things at import time. This allows us to enable the "Use Normals" checkbox by default for the MVR file format!  ESC Truss:  MVR Truss:  This is just ONE SMALL example of the improved quality of renderings when using MVR.  - MVR also now exports each object uniquely, regardless of whether or not they share a texture! No more exporting each stick of truss into it's own ESC file!!  - MVR now names geometry according to the data contained in the MVR! This means that you can name objects in VW and they will come over to Vision with the proper name instead of coming over with MeshShape everywhere! If you do not provide a name, we will default to the name in the OIP. Straight Truss will come over with the name Straight Truss, Slabs will come over as Slabs, Doors will come over as Doors... you get the point! No more giant lists of MeshShapes with absolutely no idea what is what!  - MVR contains a unique identifier that allows Vision to detect updates when merging an MVR into an existing MVR document! This means you no longer need to do special exports when you move your truss around. Simply export the entire scene via MVR from VW and merge it into your existing document in Vision. It should auto-update everything for you without duplicating anything!  - MVR contains proper local coordinate systems which allows for proper DMX XForm Rotations!  ==============================  I'll try to field questions here, but I'm excited for you guys to play around with some of this new stuff!! 6 Quote Link to comment
wclights Posted March 23, 2019 Share Posted March 23, 2019 Can MVR import Focus Points for conventional fixtures from Vectorworks so they are already focused on import? I haven't been keeping up lately, but this is the main feature I have been hoping for for a while now. Quote Link to comment
Vectorworks, Inc Employee bbudzon Posted March 23, 2019 Author Vectorworks, Inc Employee Share Posted March 23, 2019 1 hour ago, wclights said: Can MVR import Focus Points for conventional fixtures from Vectorworks so they are already focused on import? I haven't been keeping up lately, but this is the main feature I have been hoping for for a while now.  It can! In theory, esc should support this as well in 2018+ 😉 Quote Link to comment
DavidRoy Posted March 27, 2019 Share Posted March 27, 2019 Can you clarify: from Vectorworks, what file type does the "Send to Vision" command use, and is it the preferred file type? Â Â Quote Link to comment
Vectorworks, Inc Employee bbudzon Posted March 27, 2019 Author Vectorworks, Inc Employee Share Posted March 27, 2019 10 minutes ago, DavidRoy said: from Vectorworks, what file type does the "Send to Vision" command use  It still uses ESC unfortunately. We were hesitant to change Send to Vision to use MVR as it would change up the workflow mid-release. 2020 will likely use MVR as the default format for Send to Vision.  11 minutes ago, DavidRoy said: and is it the preferred file type?  MVR will be the preferred file type moving forward. I highly recommend checking it out. For the time being, from VW simply export an MVR to your desktop or a user-created folder. From Vision, "Open" this MVR to create the initial document. Now you can go back into VW, make more changes, and export the MVR overwriting the original file. From Vision, you may now "Merge" this updated/overwritten MVR into the existing Vision document. Because we use UUIDs to track objects, only updates to existing objects and new objects will be pulled in! It truly is a HUGE improvement to the old workflow (which was plagued by special exports of selected items and other nonsense that users shouldn't have to deal with). 2 Quote Link to comment
Jake DeGroot Posted April 14, 2019 Share Posted April 14, 2019 Thanks for this, @bbudzon. Trying it out now.  A few questions: In the Export MVR dialog in VW: I see the list of object types to export with check marks but I don't see a way to clear check marks and prevent some objects from being exported. I don't want my Title Block Borders to export to Vision. I have tried single-clicking, double-clicking, space bar, right-clicking. Nothing works. When I change the "Settings" Radio Button, from "All Objects in the Drawing" to "Visible Objects", I would expect the object counts to change in the Object Types pane. They do not When I change the "Settings" Radio Button, from "All Objects in the Drawing" to "Selected Objects", The object counts do change, but they do *not* reflect what I actually have selected (currently nothing). I just tried exporting an MVR of visible objects and it included everything in my scene. When I did select some objects in the scene, I was able to export just those. When the fixtures arrive in Vision, they are not named according to their channel as they are via ESC. The "Name" of the Vision node now seems to be the VW "Unit Number", and the VW "Channel Number" is nowhere to be found, despite my Mappings in VW's Spotlight Preferences being corrent. This maked it impossible to identify my fixtures in the Vision Scene Graph. Things only look right when I tell Vision the unit in my MVR is millimeters, even though the unit in the VWX that was the source of the MVR is inches. Why? But the geometry does render nicer. And splitting up the objects and tracking them by UID is a wonderful improvement! Quote Link to comment
Vectorworks, Inc Employee bbudzon Posted April 14, 2019 Author Vectorworks, Inc Employee Share Posted April 14, 2019 @Jake DeGroot Thanks for trying things out!  1. All of this is on the VW side, which I am less familiar with. I'll pass this info along to @klinzey and @Moritz Staffel, however! 2. Same as 1. 3. Same as 1. 4. This seems like an issue with VW not respecting the Data Visualizer Mappings? I know ESC uses those mappings, perhaps MVR isn't? I'll pass this info along as well and try to do some testing on the Vision side. 5. Because MVR is spec'ed to millimeters, this should almost always be selected. The only reason I decided to include it was in the event a 3rd party program implemented MVR in a non-standard way (didn't want to leave everyone hanging!). Millimeters is the default and should rarely be changed, regardless of the units in your VW document.  14 hours ago, Jake DeGroot said: But the geometry does render nicer. And splitting up the objects and tracking them by UID is a wonderful improvement!  I'm glad you're finding reasons to adopt MVR into your workflow! If you haven't tried out the merge functionality, give that a shot too! Very cool 😎 Quote Link to comment
Gaspar Potocnik Posted April 15, 2019 Share Posted April 15, 2019 20 hours ago, bbudzon said: 5. Because MVR is spec'ed to millimeters, this should almost always be selected. The only reason I decided to include it was in the event a 3rd party program implemented MVR in a non-standard way (didn't want to leave everyone hanging!). Millimeters is the default and should rarely be changed, regardless of the units in your VW document. Â If this is the case, and vision won't convert units, then it should be stated somewhere, either in the dropdown, special pop up or something. Coming from VW were you can use any unit anywhere and the app will convert it, it makes no sense to be given an option to change units but only millimeter will work. 1 Quote Link to comment
Vectorworks, Inc Employee klinzey Posted April 15, 2019 Vectorworks, Inc Employee Share Posted April 15, 2019 2 hours ago, Gaspar Potocnik said:  If this is the case, and vision won't convert units, then it should be stated somewhere, either in the dropdown, special pop up or something. Coming from VW were you can use any unit anywhere and the app will convert it, it makes no sense to be given an option to change units but only millimeter will work.  Vision only operates in inches. In the dialog you are selecting the unit measurement used by the file being imported so it can properly be converted to inches. Regardless of the units used by the application the MVR file will always be stored using millimeters by the current MVR specifications. In future versions we will disable the units option when importing an MVR file. (Earlier versions of the MVR specification did not specify the units so we had to account for different types in the import dialog till the 1.0 specification was adopted by everyone.)  Right now the units selection is similar to the units selection in Vectorworks when you import a DWG/DXF file. When we see an MVR file and we default to millimeters and we are correct 99% of the time but since there could be an MVR file from another application not following the new standards we have to allow you to change the units just in case. Quote Link to comment
Gaspar Potocnik Posted April 17, 2019 Share Posted April 17, 2019 On 4/15/2019 at 12:59 PM, klinzey said: Vision only operates in inches  Any chance vision can be multi unit as Vectorworks? Or since mvr is mm it can become mm? 1 Quote Link to comment
Vectorworks, Inc Employee klinzey Posted April 17, 2019 Vectorworks, Inc Employee Share Posted April 17, 2019 In the future Vision may support other distance units. It is a wish list item from several users. Quote Link to comment
Charlie Winter Posted May 7, 2019 Share Posted May 7, 2019 On 4/13/2019 at 10:10 PM, Jake DeGroot said: When the fixtures arrive in Vision, they are not named according to their channel as they are via ESC. The "Name" of the Vision node now seems to be the VW "Unit Number", and the VW "Channel Number" is nowhere to be found, despite my Mappings in VW's Spotlight Preferences being corrent. This maked it impossible to identify my fixtures in the Vision Scene Graph. Just ran into this myself today and submitted a bug.  Quote Link to comment
Cory Pattak Posted July 1, 2019 Share Posted July 1, 2019 So just to clarify...when I look at the X, Y, Z positions in the Properties Window..and I see a number like 150 or 360. Is that in inches or in mm? Â Quote Link to comment
Vectorworks, Inc Employee bbudzon Posted July 1, 2019 Author Vectorworks, Inc Employee Share Posted July 1, 2019 1 hour ago, Cory Pattak said: Is that in inches or in mm?  Vision's Properties Palette is always in units of inches when referring to distance 😉 Quote Link to comment
Cory Pattak Posted July 1, 2019 Share Posted July 1, 2019 gotcha. Just curious, how would a user know that? Should the numbers in those fields have a " after it to indicate inches? I can imagine every new user wondering the same thing I did. Â Cory 1 Quote Link to comment
Vectorworks, Inc Employee bbudzon Posted July 2, 2019 Author Vectorworks, Inc Employee Share Posted July 2, 2019 13 hours ago, Cory Pattak said: Should the numbers in those fields have a " after it to indicate inches?  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 😞  13 hours ago, Cory Pattak said: Just curious, how would a user know that?  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. Quote Link to comment
Cory Pattak Posted July 3, 2019 Share Posted July 3, 2019 Hi Brandon,  There's a lot of info in there, most of which I understand, some of which I don't. All I'll say is that at the end of the day, I don't think new users are thinking that in depth about a program. Ultimately it comes down to 1) Is this software right for me, 2) Is it worth the cost, 3) Is the learning curve manageable.  Showing that these measurements are in inches is obviously a minor thing. But there are many of these little things like this scattered throughout the program, some of which we've discussed in the past couple days...areas of the program that are buggy, or are unintuitive, or don't match VW behavior. Obviously VW (and Vision) is a business and the ultimately goal is to sell licenses. When a potential user downloads the demo, they are gonna try it out, and either decide Vision is for them, or it isn't. I can say at the moment that within the theatrical lighting design community (at least in NY) the decision generally seems to be that "Vision is not for me." Spotlight users are using Capture, or Light Converse, or another alternative to Vision or not even bothering with Previz. With all due respect to the hard work the entire Vision team has put in to improve the program, a new user doesn't know or necessarily care about all the back end reasons a program functions the way it does. (I know you're laying it out for me because we get more technical here on the Beta board, delving into the "Why") For most users, it's a gut feeling..."do I like using this software." So a lot of the reports I file, are about trying to address all those  little hiccups that collectively add up to a piece of software that many people are just deciding doesn't work for them. Valid reasons or not, the end user just wants the calm duck above the water, they are not interested in what the legs are doing underneath.  22 hours ago, bbudzon said: The next logical step from there is making the UI localizable so the UI text is fully decoupled from the backend data.  If I'm understanding what this means, I think this is a HUGE step in trying to get Vision into the hands of more people. The info in the Properties dialogue box still looks somewhat like back end code. The missing units, the presence of "True" or "False." (Obv there's a million checkboxes in VW and none of them say True/False, they are just a checkbox.) What the engineers code and the what the users see should be very different, and the user's experience should drive the UI, not having the code dictate the UI. I say this as a completely non-technical, non-code writing person. I think it's going to continue to be difficult to acquire new users until Vision feels a little less "code-y" and a little more user friendly. (Even though it has taken a big step foward in the past 2 years) This is the main feedback I'm hearing from other designers. And with ETC's 'Augmented' software on the horizon, which is VERY user friendly (and free), designers are going to be even more reluctant to spend time in a program they feel is unintuitive or comes with a set of asterisks of all the tasks that it still doesn't do well yet, but is on the list for down the road.  Just my two cents based on talking to a lot of other LDs.  thanks Cory 2 Quote Link to comment
jweston Posted July 10, 2019 Share Posted July 10, 2019 On 3/20/2019 at 11:27 AM, bbudzon said: MVR now names geometry according to the data contained in the MVR! This means that you can name objects in VW and they will come over to Vision with the proper name instead of coming over with MeshShape everywhere! If you do not provide a name, we will default to the name in the OIP. Straight Truss will come over with the name Straight Truss, Slabs will come over as Slabs, Doors will come over as Doors... you get the point! No more giant lists of MeshShapes with absolutely no idea what is what!  How does this work for a simple extrude shape? where is the Name for the MVR object? Quote Link to comment
Vectorworks, Inc Employee bbudzon Posted July 10, 2019 Author Vectorworks, Inc Employee Share Posted July 10, 2019 22 minutes ago, jweston said: How does this work for a simple extrude shape? where is the Name for the MVR object?  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. 1 Quote Link to comment
LJ TMS Posted July 10, 2019 Share Posted July 10, 2019 23 minutes ago, jweston said: How does this work for a simple extrude shape? where is the Name for the MVR object? Â There's a field at the bottom of the Object Info palette where you can type a name in for any object. Â 1 1 Quote Link to comment
TReimann Posted August 28, 2019 Share Posted August 28, 2019 On 7/3/2019 at 1:57 PM, Cory Pattak said: Hi Brandon,  There's a lot of info in there, most of which I understand, some of which I don't. All I'll say is that at the end of the day, I don't think new users are thinking that in depth about a program. Ultimately it comes down to 1) Is this software right for me, 2) Is it worth the cost, 3) Is the learning curve manageable.  Showing that these measurements are in inches is obviously a minor thing. But there are many of these little things like this scattered throughout the program, some of which we've discussed in the past couple days...areas of the program that are buggy, or are unintuitive, or don't match VW behavior. Obviously VW (and Vision) is a business and the ultimately goal is to sell licenses. When a potential user downloads the demo, they are gonna try it out, and either decide Vision is for them, or it isn't. I can say at the moment that within the theatrical lighting design community (at least in NY) the decision generally seems to be that "Vision is not for me." Spotlight users are using Capture, or Light Converse, or another alternative to Vision or not even bothering with Previz. With all due respect to the hard work the entire Vision team has put in to improve the program, a new user doesn't know or necessarily care about all the back end reasons a program functions the way it does. (I know you're laying it out for me because we get more technical here on the Beta board, delving into the "Why") For most users, it's a gut feeling..."do I like using this software." So a lot of the reports I file, are about trying to address all those  little hiccups that collectively add up to a piece of software that many people are just deciding doesn't work for them. Valid reasons or not, the end user just wants the calm duck above the water, they are not interested in what the legs are doing underneath.   If I'm understanding what this means, I think this is a HUGE step in trying to get Vision into the hands of more people. The info in the Properties dialogue box still looks somewhat like back end code. The missing units, the presence of "True" or "False." (Obv there's a million checkboxes in VW and none of them say True/False, they are just a checkbox.) What the engineers code and the what the users see should be very different, and the user's experience should drive the UI, not having the code dictate the UI. I say this as a completely non-technical, non-code writing person. I think it's going to continue to be difficult to acquire new users until Vision feels a little less "code-y" and a little more user friendly. (Even though it has taken a big step foward in the past 2 years) This is the main feedback I'm hearing from other designers. And with ETC's 'Augmented' software on the horizon, which is VERY user friendly (and free), designers are going to be even more reluctant to spend time in a program they feel is unintuitive or comes with a set of asterisks of all the tasks that it still doesn't do well yet, but is on the list for down the road.  Just my two cents based on talking to a lot of other LDs.  thanks Cory I'd like to mention the importance of all Cory said because basically it's the summary of nearly all I told you at the beginning of this year and I hope that this also helps Brandon to push the importance of some points to the decision makers:  If Vision isn't intuitive (especially for Vectorworks users), they won't use it because there are some other (partially cheaper) visualisation programs on the market (grandMA 3D, WYSIWYG) they already use. Why should they change to a program that takes a lot time and work to understand? And the point that Vision looks better than other visualizer will NOT be the deciding point. I can only speak for all of the LDs and lighting programmer I know and work with but I am very sure that this is the standard in Germany: at the end the lighting programmer is the one that decides which visualisation program will be used. And for him it's not the most important point that it looks good. This is a good selling point for the LD, but again... at the end he is not the one who decides. And for the programmer it is most important that he can work fast and intuitiv with the software, that he can make quick changes during the preprogramming and that the fixtures behave in the software like they do in reality.  So as Cory mentioned, there are some "small" things like the measuring unit but at the end these things will make the decision if someone buys a Vision licence or not. As you know I had a lot of troubles last year finding out what these numbers stand for and it tooks me a lot of time to make small changes in the Vision file like lifting the trusses 1m up because they decided this during the preprogramming or to tell anybody on which height a truss actually is when I don't wanted to run the Vectorworks file the whole time. I had the time to figure it out because we made this test project but anybody else would go back to his known program to save time.  Especially there is no Vision manual at the moment the program has to be user friendly!  And for really good lighting design renderings where the look is the most important thing, in my opinion at the moment Vision also isn't the program to choose because often the lighting design is made by persons who don't use lighting consoles very often so the need pallettes where they can control colour, gobos and things like that easily without using a lighting console (like Capture, Cinema4D).  So Vision needs to decide if it wants to be a previz programm for lighting design - than it needs some more tools - or a preprogramming software - than all these "small" things that make working with it so complicated (I also mentioned them in my mail at the beginning of this year) need to be fixed.  By the way... please keep on making Vision usuable in mm because otherwise it will be hard to distribute it in Europe.  Thanks, Tina Quote Link to comment
Vectorworks, Inc Employee TomWhiteLight Posted August 28, 2019 Vectorworks, Inc Employee Share Posted August 28, 2019 (edited) Have to agree with Tina and Cory from a UK perspective.  however most prospects using capture are looking for ease of use and not needing to redraw or swap geometry on import. (Referring to capture workflow). I am a long term Vectorworks user who used to export to capture for visuals  A lot of the Vision eccentricities can be overlooked if send to vision worked flawlessly in terms of syncing all information (and I mean everything, perfectly). It is a visualizer not a separate application.  it is cheaper than wyg though!  keep up the good work it’s nearly there.  Edited August 28, 2019 by TomWhiteLight Clarity Quote Link to comment
Jake DeGroot Posted August 28, 2019 Share Posted August 28, 2019 On 7/3/2019 at 7:57 AM, Cory Pattak said: What the engineers code and the what the users see should be very different, and the user's experience should drive the UI, not having the code dictate the UI. I say this as a completely non-technical, non-code writing person. I think it's going to continue to be difficult to acquire new users until Vision feels a little less "code-y" and a little more user friendly.  What @Cory Pattak says here is certainly, unarguably, true.  It is also the exact same thing that @bbudzon is saying in the post right above that:  On 7/2/2019 at 9:23 AM, bbudzon said: This is where you get to see the nasty side of Vision... .... Furthermore, the UI was not decoupled from the backend code.  I think we're in vigorous agreement here. The challenge is not convincing the folks at VWX that the Vision UI and Vision backend should be decoupled; the problem is, as always, convincing them to prioritize the time and energy towards what amounts to a major project of actually doing that work.  One quick question on this, @bbudzon - I understand that the values in the vision properties window are directly used by the backend so adding strings to them is a no-go. Are the keys also directly used? Could you more easily change "X" to be "X (inches)"? Or is that the same problem?  Quote Link to comment
Vectorworks, Inc Employee klinzey Posted August 28, 2019 Vectorworks, Inc Employee Share Posted August 28, 2019 3 hours ago, TReimann said: Especially there is no Vision manual at the moment the program has to be user friendly! Vision has the same style user manual that is available for Vectorworks. It's accessible via the help menu or by pressing F1. Â It always going to be difficult for Vision to compete with "Free" software. If the programmer is happy with the rendering speed and quality they get from GrandMA 3D it's going to be almost impossible to sell them Vision because of the additional cost. The user needs to want something more or different than they can get from GrandMA 3D for them to even look at Vision. Quote Link to comment
TReimann Posted August 29, 2019 Share Posted August 29, 2019 11 hours ago, klinzey said: Vision has the same style user manual that is available for Vectorworks. It's accessible via the help menu or by pressing F1.    That`s right, but when I used it last time most of the points I wanted to know weren`t written down there or some important points within the explanation were missing. But I will look through it.  The point is not to compete with a free software, especially GrandMa 3D also has many problems. A lot of people are interested in Vision. What I wanted to say is changing to a program that the programmer find hard to understand will not work. They would spend money for Vision if they see an advantage for their work. And in the programmer world it`s not only the rendering quality (which is really good in Vision) that matters, but more an easy and time saving workflow to transform a Vectorworks file into a visualisation. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.