Performance Improvement in VA

VisualARQ
1

Hello,

till now there are many threads about performance issues. The VA team deals with Many of them (or all of them), and provides fixes, RC or even official updates. Overall, in my opinion there is a significant mismatch between what the computer specs can provide in terms of performance and what the Rhino and VA can handle and how fast. In other words, I believe that in simple tasks, Rhino and VA could improve in terms of performance.

The file I am working with is: 236 MB, attached in a worksession file, containing other files including two 5GB point cloud files (.3dm). The point clouds are not visible in the viewport. When I try to update the vaplans, it takes ages. When opening the .rws it takes ages. When I try to move layers up and down - pretty standard when trying to get things clean - it has serious lags.

I am curious, if the point clouds are not visible, are they taken in calculations of the VAplans and VAsections? Is this related to a previous - fixed with the RC - thing about calculating non visible worksessions files’ elements, such as guides? Should worksession elements calculated in VAplans or not?

I’ve tested in the laptop that I am currently working, RTX4070 with low ram and in the desktop with ram ~32GB. I am not posting all the specs here. The layers movement, has been tested with similar performance without 5GB point clouds too.

If it’s about computer specs, can you give us officially the recommended setup? If it’s about configuration, can you give us the recommended one? Do you think that you can provide improvements in the near future, maybe in collaboration with Mcneel? Because for sure, there are performance factors related to Mcneel itself.

Fellow architects, work with similar computer specs, with 500MB files in Archicad, Sketchup etc, with a slighly higher performance I must say.

Have you as VA dev team found things that can be improved?

Thanks in advance.

performance

performance-2

I forgot to mention Autosave..

I forgot to mention changing a layer in the wall style attributes…

performance-3

I forgot to mention: orbiting in perspective mode, while having 2d drawings in the file (exploded vaplans or vasections)

2

Hi @GabrielB,
Do you have a point cloud, or a large amount of points?

VisualARQ doesn’t take into account point clouds in the generation of 2D plan and section views, no matter if they are visible or hidden.
These 2D drawings do take into account the geometry in all files inside a worksession.

The timing and performance of generation of 2D plan and section views in VisualARQ depends on the amount of geometry existing in the model, also in hidden layers (since VisualARQ needs to know what needs to be generated and what needs to be hidden). And it also depends on the complexity of that geometry.

In general, with the same model, the timing or performance to generate the 2D views should be similar than the Rhino Make2D tool. Have you tried to create a Make2D drawing of that model from a similar point of view with VisualARQ disabled? have you compared the timing?

If you can share the involved files, I can test this for you.

To sum up, let me list the situations you are describing that are very slow:

  1. Navigation in Layer Manager (Moving Layers up or down)
  2. Generation of VisualARQ Plan/Section views
  3. Navigation in the Wall Styles dialog (changing a layer)
  4. Orbiting in perspective mode while having 2D drawings
  5. Autosave

I suspect points # 1, #4 and #5 are unrelated to VisualARQ (you can try them with VisualARQ disabled and compare the performance).

If they are still slow with the same files involved (I’d dare to say a 236MB file with 5GB of point cloud attached might be a huge file to work with) without VisualARQ, you can report this to mcneel developers, we can’t help it. But if you notice a difference, please let me know.

As I mentioned, the point #2 depends on the amount of objects and complexity of the model. But it should be similar as Rhino Make2D with the same model.

I’d like to test #3 if you can share the files involved.