Tibidabo substantially increasing size

VisualARQ
1

I have been struggling with my model since the beginning in terms of size. As it turned out VisualARQ is all behind it and as far as I understand that 20 curtain wall extended to an organic roof can increase the file size for about 1GB I don’t get how Tibidabo creates data on native rhino objects. So I have been working as usual and noticed that in about 10 minutes model gained 800 MB. I have been just testing a different method of extending the curtain walls using vaSubstractSolid command and I had just edited one of the very walls. So I started taking the model apart. Exporting all elements checking how big they are. Out of 800MB, the curtain walls took 400MB. I started taking apart native Rhino objects and boom my columns are 300MB although they have nothing to do with visualARQ.Rhino audit says that Tibidabo takes 150 MB in them and the rest is geometry. I have made an extra file with new 200 cylinders of similar height and it was 2MB. So my question is how come Tibidabo creates sooooo much data in normal Rhino object and how is it possible that so of this data is in their geometry?

There is file with 200 columns that is 2 MB
ddd.3dm (1.7 MB)
and here is link for my columns that somehow have about 300 mb

2

Hi @mijalskid17,

I’ve been checking your file, and the problem is not related to Tibidabo, although it is true that Tibidabo stores some data in the model. Let me explain what is Tibidabo storing in the model:

First of all, yes, It is true that there is Tibidabo user data in the geometry, but this user data is just temporary in runtime, and is not saved in the 3DM. Here you can see what Details says about this Tibidabo geometry user data:

image
image667×684 13.8 KB

There is also plugin data stored in the document. Here, Tibidabo stores a database for its objects, and some information of document objects. It is true that some of this information is duplicated from the Rhino geometry, and this is something we’ll try to fix in VisualARQ 3. In normal conditions, Tibidabo overhead in a 3DM is between 5%-15%, depending on the model. In extreme cases like your model, it could be as much as 40%-50%, but this is not normal, and again, we’ll fix this in VisualARQ 3.

Finally: why your columns are so big? Well, it seems the top surface of the column, is a trimmed surface, from a reaaaaaaally big surface: here are some screenshots when you explode the column and show the control points for the top face:

image
image915×618 5.08 KB

image
image915×618 7.06 KB

image
image915×618 16.4 KB

Only this surface is almost 900 KB in size… if you have 181 columns… well, this is more 150 MB.

I don’t know how you created this surface, but you can use the command ShrinkTrimmedSrf to simplify it.

Regarding the curtain wall issue: if the top surface where you extend the curtain wall is very complicated (that what I understand when you say “organic”), it is normal that the curtain wall takes so much memory. Top frame, mullions, and cells are adjusted to the surface, and there will be offset surfaces, that tend to be also much complex and big in memory. We can try to rebuild all generated surfaces so they can be much smaller in memory.

Again, we’ll try to improve VisualARQ 3 so it can add as little memory/file overhead as possible. By the way, we’ve made big improvements related to speed in VisualARQ 2.11, in many scenarios: file open, save, display, section view and plan view updates, space calculation, copy and paste, etc.

Thanks, and sorry for the long response!

Enric

3

Thanks for good explanation. I have managed to figure it out and you are right regaridng ShrinkTrimmedSrf and now everything seems fine but I do need to explode all the walls and curtain walls to run the command. So what I was thinking is that you could somhow add it to the script of vaSubstactSolid so that at some point there is somthing like ShrinkTrimmed Surface. I think that would fix the issue. Anyones thats just a suggestion. Thanks for help and good luck with developing the plugin.

Daniel

4

Hi @mijalskid17,

So I understand the columns were VisualARQ columns, which a solid subtracted, and then you just exploded them. Is that correct?

If that’s the case, we can try to rebuild surfaces after performing the boolean subtraction. The problem is that VisualARQ keeps a history of all changes, as you can then change the radius of the column profile, so I need to store the solid to subtract internally (here is another example of data that Tibidabo needs to store), and as the solid was so complicated, the file will be bigger again. Moreover, Tibidabo needs to store the solid for each column, as any transform applied to the column is also applied to the solid.

One possible solution is to implement Top/Bottom extension for columns like we have now in walls, so the top solid will be stored just once in the document.

Regards,

Enric

5

@enric The columns were native Rhino geometry, what I meant was regarding curtain walls but yeah I have subtracted the top surface from them and I had to explode them to shrink trim.

By the way, I am trying to export plans using vaPlanview but it doesn’t work, I think the model might be too much, in the end, it is a massive building with complex surfaces but yeah I need it. So when I do vaPlanView I see that VisualARQ is generating graphics but it stays at 0% forever and my PC works 100% CPU forever and I don’t want the processor to melt so I have to close rhino. Do you have any ideas of how to overcome this? Now I am trying to turn off some inhabitation layers like vegetation or railings but still, I need them which sucks.

Daniel

Edit: It worked after a while of waiting, thanks anyways

6

Hi Daniel,

Can you send me the model to enric@asuni.com?

As I mentioned earlier, we have made many performance improvements in VisualARQ 2.11. But I can take a look at your model and see if we can do something more.

Thanks,

Enric