2020 Teaser Tuesday - VGM Level of Detail - Vectorworks 2020

[Amorphous - Julian]

@JuanP looks fantastic! Will this improve the Performance of 'Multiple Pane Views' as well?

 

I find that when I use 'Multiple Pane Views' with say one OpenGL perspective and one plan view window, the graphic performance of VW is drastically slower than just using one View Pane. 

I currently use a RX580 (8GB) graphics card and thinking of upgrading to a Vega 56. 

Questions:
(1) Would the above VGM improve the Multiple Pane View performance?
(2) Would the performance of Multiple Pane View improve with my said upgrade of GPU? Is Multiple Pane View performance GPU-bound?

[mgebel]

I am also very interested to know how this will affect working with point cloud data. I have been working with Faro Scene, and it seems to handle very large (243 million) clouds without much trouble - very snappy. Taking for granted that VW handles pointclouds in a different way than Scene, it still seems crazy to me that after reducing the point cloud to 1/100th the number of points, it is still maxing out the ram on my machine and nearly crashing VW (and this with a fairly powerful gaming computer)

 

I recently switched over to VW in part because of the integrate point cloud capability, as Laser scanning is becoming a core part of my workflow, but without improvements to performance when handling point clouds, the feature will be severely lacking.

 

On a positive note, I discovered a great workaround, which is to use clipping cubes in Faro Scene to export smaller blocks of the full project point cloud, which break up at specific planes on the VW project - eg. "top of slab" levels. This way, the smaller sectioned point clouds can be associated with the story layers, and toggle on and off when needed. Saves a lot on performance, and makes them easier to visualize, as well.

 

Edited August 30, 2019 by mgebel

[jblock]

On 8/29/2019 at 7:27 PM, Amorphous - Julian said:

@JuanP looks fantastic! Will this improve the Performance of 'Multiple Pane Views' as well?

 

I find that when I use 'Multiple Pane Views' with say one OpenGL perspective and one plan view window, the graphic performance of VW is drastically slower than just using one View Pane. 

I currently use a RX580 (8GB) graphics card and thinking of upgrading to a Vega 56. 

Questions:
(1) Would the above VGM improve the Multiple Pane View performance?
(2) Would the performance of Multiple Pane View improve with my said upgrade of GPU? Is Multiple Pane View performance GPU-bound?

 

Yes, these VGM Improvements could help with Multiple View Panes. However, it is probably going to depend more on what type of geometry you have. A lot of the improvements that we have seen are with native VW objects, especially curved geometry like Truss and Lighting Devices. If you have a bunch of that type of stuff in your file, you will probably see a bigger improvement, even with Multiple View Panes.

[jblock]

On 8/29/2019 at 9:44 PM, mgebel said:

I am also very interested to know how this will affect working with point cloud data. I have been working with Faro Scene, and it seems to handle very large (243 million) clouds without much trouble - very snappy. Taking for granted that VW handles pointclouds in a different way than Scene, it still seems crazy to me that after reducing the point cloud to 1/100th the number of points, it is still maxing out the ram on my machine and nearly crashing VW (and this with a fairly powerful gaming computer)

 

I recently switched over to VW in part because of the integrate point cloud capability, as Laser scanning is becoming a core part of my workflow, but without improvements to performance when handling point clouds, the feature will be severely lacking.

 

On a positive note, I discovered a great workaround, which is to use clipping cubes in Faro Scene to export smaller blocks of the full project point cloud, which break up at specific planes on the VW project - eg. "top of slab" levels. This way, the smaller sectioned point clouds can be associated with the story layers, and toggle on and off when needed. Saves a lot on performance, and makes them easier to visualize, as well.

 

 

 

Good point! I also like your workaround with the Clip Cube. However, I don't know how much improvement you will see with just Point Cloud data and the VGM imrpovements in 2020. I think you will see some benefit with less RAM usage, but for overall performance with point cloud data, I would expect it to be similar to 2019. This task was more focused on simplifying geometry. 

[Mark Aceto]

On 8/29/2019 at 2:16 PM, JuanP said:

Busy day today!!! I've been checking with the different engineers involved with the VGM to help me get the answers to all your questions. I'm hoping that tomorrow I'll be able to provide you with additional information.

 

 

@JuanP any updates?

[Jeremy Best]

On 8/28/2019 at 9:29 PM, line-weight said:

Bit odd the way this is explained in the video, as if it's resolving a fault in users rather than in the software.

 

If setting the quality to 'very high' means that VW draws stuff in the distance in more detail than is necessary then that doesn't mean that users are making a 'wrong' choice, it means that VW is doing it wrong.

 

(For context; I provide Tech Support for clients of the New Zealand distributor, Megabits). 

 

As someone who frequently gets online with users and gets to see how people set up and use Vectorworks, I observe: 

• Most/Many users don't have an appreciation of how powerful their computer is or is not. 
• Whether or not users know how powerful their computer is or is not, they often don't know: 
  • What Vectorworks or graphics card settings affect performance 
  • What conditions in their file play a role in performance 

So my take on what they said is this: This new capability means users can get better performance from Vectorworks regardless of how much they know. (Which is good design). 

[line-weight]

9 hours ago, Jeremy Best said:

 

(For context; I provide Tech Support for clients of the New Zealand distributor, Megabits). 

 

As someone who frequently gets online with users and gets to see how people set up and use Vectorworks, I observe: 

• Most/Many users don't have an appreciation of how powerful their computer is or is not. 
• Whether or not users know how powerful their computer is or is not, they often don't know: 
  • What Vectorworks or graphics card settings affect performance 
  • What conditions in their file play a role in performance 

So my take on what they said is this: This new capability means users can get better performance from Vectorworks regardless of how much they know. (Which is good design). 

 

Sure. But my point is that if setting to "high quality" results in VW drawing in more detail than necessary, then that is somewhat independent of how much users know. Even a user with a high awareness of their computer's power and the conditions in their file would reasonably expect that setting something to a "higher" quality would provide some kind of advantage in exchange for slower zooming, etc.

 

The way I see it, the way in which "how much users know" would affect things, is by users knowing "VW doesn't work properly therefore I have to change a setting to compensate" which indicates bad software design. But this new capability (hopefully) is an example of better design.

[JuanP]

On 8/29/2019 at 10:49 AM, Mark Aceto said:

1. Making more of the code multi-threaded, which you just answered
2. Lifting the 4-core limit (on modeling not rendering), which is still a mystery

Please let us know where we stand with #2, including a roadmap of the version/year ahead.

Sorry for the delay.

 

2. We have excessive thread blocking in a supporting library, causing us to set the three core limit. We are looking at possibly lift this limitation in the next version, but we can't promise anything yet. We will have more information Q2 next year. I will keep you all posted.

[Mark Aceto]

19 hours ago, JuanP said:

Sorry for the delay.

 

2. We have excessive thread blocking in a supporting library, causing us to set the three core limit. We are looking at possibly lift this limitation in the next version, but we can't promise anything yet. We will have more information Q2 next year. I will keep you all posted.

 

First of all, thank you for the straight answer that we've been trying to get ever since the announcement a year ago.

 

Second, this is crushing news - particularly 3 cores instead of 4. With the current state of CPU's moving in the direction of more cores / lower base clock speed, we simply can't combine a fast single core clock speed with a decent GPU in a laptop (especially Apple). That's not VW's fault by any means, but we've all been trying to win at this game for years, and the currently available hardware is forcing us to take a step backward (at a premium price).

 

It seems like we've been begging for this spaghetti code to be rewritten since sometime around v2015, and it's still getting pushed to v2021, so what's the holdup?

 

Edited September 10, 2019 by Mark Aceto

[Ross Harris]

3 hours ago, JuanP said:

in a supporting library

By 'a' are we talking about one library? This/these should have the highest priority to revise - its insane that we are limited to 3 cores when AMD and Intel are going core crazy in their desktop CPU's to get around the fact that they can't increase speeds due to temperature and fabrication issues. At least AMD have some respectable base clock speeds - Intel's are terrible at decent core counts and both seem to only want to publicise their boost clock speeds for one-upmanship - intel being the worst again and bad for macs.. 

It becomes a real problem upgrading when other applications you use have no limits and the main one you use is still dragging the chain making your purchasing decision potentially degrade the performance of other apps because of the core/single core clock speed trade off.