Jump to content
bbudzon

Vision 2019 SP3 MVR Improvements

Recommended Posts

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.

Share this post


Link to post
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+ 😉

Share this post


Link to post

Can you clarify: from Vectorworks, what file type does the "Send to Vision" command use, and is it the preferred file type?

 

 

Share this post


Link to post
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).

  • Like 2

Share this post


Link to post

Thanks for this, @bbudzon. Trying it out now. 

 

A few questions:

  1. In the Export MVR dialog in VW:
    1. 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.
    2. 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
    3. 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).
  2. I just tried exporting an MVR of visible objects and it included everything in my scene.
  3. When I did select some objects in the scene, I was able to export just those.
  4. 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.
  5. 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!

Share this post


Link to post

@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 😎

Share this post


Link to post
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.

  • Like 1

Share this post


Link to post
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.

Share this post


Link to post
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?

  • Like 1

Share this post


Link to post

In the future Vision may support other distance units. It is a wish list item from several users.

Share this post


Link to post
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.

 

Share this post


Link to post

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?

 

Share this post


Link to post
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 😉

Share this post


Link to post

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

  • Like 1

Share this post


Link to post
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.

Share this post


Link to post

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

  • Like 2

Share this post


Link to post
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?

Share this post


Link to post
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.

  • Like 1

Share this post


Link to post
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.

 

name.thumb.png.b4c8dcfedfd39a204a0f22724f8c7a0b.png

  • Like 1
  • Love 1

Share this post


Link to post
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

Share this post


Link to post
Posted (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 by TomWhiteLight
Clarity

Share this post


Link to post
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?

 

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

×
×
  • Create New...