Worksession Update or Detach is extremely slow - how to debug?

VisualARQ
,
1

Hi, this is not necessarily a VisualARQ issue per se, but as it is heavily utilised in the files, I think it at least plays a big role.

The issue is that I have very large files, filled with Rhino and VARQ geometry. File sizes between 800Mt to 2Gb regularly. I might have one active file and 1-2 worksession files attached.

When I attach a worksession, the file opens remarkably fast: in seconds, definitely under a minute.
Sometimes I need to make changes to the attached worksession files, and save. This would then require update to the active file. Regardless if I Detach or Update, both actions take hours. Yes, hours. It has become waaaay faster to close the file and redo open and worksessioning. It is super annoying, but at least it’s done within minutes.

I suspect that Update is the same as Detach + Attach, hense there is propably no difference between them. But what happens at Detach that makes the process so slow?

Obviously I cannot attach the files here, and because the testing, whether it works or not is a very slow process - do you have suggestions on how to narrow the culprit down on this case?

1 Like
2

This is impressive, Tony. Would you have any hints for maintaing such huge projects? And how deep do you go with detailing? All done as 3D model? With live plans and sections? So many questions… :wink:
I don’t use worksessions, myself. I prefer external blocks, embedded and linked. And it works. More or less.
Cheers, Jaro

3

@jerry.bakowski
Hi, I don’t think I can offer any significant hints. Except logical organisation of elements to layers, by names and by Key/Values. This helps quite a lot to keep things organised and selecting/Hiding stuff you do not wish to affect. Everything is manageable, as long as you are organised. However, here I’m talking more about realisation/fabrication of somebody elses designed projects that come to our table, not so much about the use of VARQ in architectural design stage.

I work a lot with large, complex facades so the accuracy is for fabrication. We’re talking 0.1mm accuracy in modelling and CNC data, 0.5-1mm for production drawings. Part naming is crucial, as you do want to match each drawing to a specific part. And when you end up with more than 100.000 parts in the model, the naming convention needs to be smart.

I tend to keep (if possible) all geometry generation in Gh, and limit manual tweaks to minimum. This way, all updates (and there will be updates) are super fast to apply. If some modeling process takes 5 steps, it’s better to split it into 5 scripts than do everything in one. Such as generate beam/ generate drillings and cuts/ name unique beams ← so that would be preferrably 3 separate scripts, which are then easy to update from any given step.

A lots of script for generating structures, individual components, drawings, or excel lists. Naming these script files so that you can understand the purpose of the script without opening it.

For large projects, creating VARQ dynamic blocks for parts. For instance, I created a dynamic Window object with 3 LOD levels; a box for positioning and size comparison, Simple frame for model, and accurate complex frame for drawings.

If project is large, split into files, and think about the division at the very beginning of the project. It also affects the division of labour, as one person can easily be in charge of one file, and the division line is set early on.

Here is one smallish facade on my screen now, all in just one file. Aluminium profiles. ~5800 beams, 1500 connection parts, glasses and sheet metals as surfaces and polysurfaces. File size about 1,6Gb.

kuva
kuva1663×1176 221 KB

Accuracy is high, alu cuts and drill holes present.

kuva
kuva1389×919 118 KB

Everything that can be is VARQ beam, as it can carry profile, length, cuts and drill holes without any additional preparations.

kuva
kuva1391×934 271 KB

I have sorted all project profiles to a separate, cumulative file. From there I can select and copy required beams, or change beam profile curve from MQ to HQ. MQ from modelling, HQ if necessary for some purpose. Again VARQ offers here the very easy option to change between these two.

kuva
kuva1576×979 193 KB

MQ vs HQ. You want to avoid arcs for speed.
kuva
kuva1056×716 19.9 KB

Some larger projects (geometria.fi) utilising VisualARQ:
Nokia Areena

kuva
kuva766×643 84.7 KB

Kannen Opaali
kuva
kuva743×660 99.8 KB

kuva
kuva950×1021 136 KB

Keilaniemen portti

kuva
kuva1189×741 130 KB

Katajanokan laituri
kuva
kuva1015×507 66.1 KB

kuva
kuva1147×1053 148 KB

6 Likes
4

Hi @Toni_Osterlund I’ve tested the slow response you report here when updating files across worksessions, and I’ve noticed a significant difference when VisualARQ is loaded than when it isn’t. We will revise this problem and get back to you when we find a solution.

PD: Beautiful projects! :wink:

1 Like
5

How about use reference function to organise the file instead of worksession? I also noticed, it becomes very slow to open the main file when VA is loaded and worksession is been used. Reference function works almost the same as worksession right?

6

@microinspire If you experience a slow performance also when using referenced blocks and VisualARQ is enabled, it might be a different case than the worksessions. Please share the involved files so we can investigate what’s happening.

When using referenced files with VisualARQ, they need to be inserted as embedded and linked blocks, otherwise their plan view representation won’t be displayed properly.

7

@fsalla Is there a way to work with linked blocks while still having the plan view display correctly? The plan view with linked blocks isn’t showing them properly (I think this would be the most efficient solution for large-scale projects, since linked blocks are the least resource-intensive for Rhino).

8

Hi @miguelayora3, no, it isn’t. The only way (right now) to display external blocks properly in plan and section views is to insert them as embedded and linked blocks.

9

@fsalla Do you have plans to add this for future versions?

10

@miguelayora3 We may need to study if it is feasible. Why would you need that instead of using emmbedded and linked blocks, or work with worksessions?

11

@fsalla because the file is lighter and the performance for modeling in the main file is better

12

@miguelayora3 When using “linked” option, the file is lighter, indeed, but not compared with the worksessions. And the performance for modeling, display, etc should be the same as when using “emmbedded and linked”.