We have a large number of individual components which include nested sub-components (over 300) which are then organised into various levels of sub-assemblies, assemblies and then ‘arrays’ for different building configurations.
We noticed that our main structural components assembly had increased dramatically in size from 20 MB to over 60 MB and we traced this increase back to when we created CNC pockets in extruded solids using the boolean difference/ makehole commands.
The original solid is extruded from the geometry lines and the file size is only a few hundred KB. We then add in the pockets and the file size increase to over 2MB. With hundreds of these components the increased size compounds in the final arrays and creates large final file sizes.
One of our team is using VisualArq 2 to extract documentation plans and sections of the final array model and the file size seems to become problematic when over 60MB and it can hang the file while loading with the VA plugin is enabled. When we previously managed to reduce our files sizes these problems cease to occur.
Is there any way after conducting boolean operations to reduce the increase in fille size. Attached are an example of the extruded solid and the solid with subsequent boolean differences applied to illustrate the difference in file sizes.flg_ext_srf_02a(rw-test).3dm (312.2 KB) flg_ext_srf_02a.3dm (2.0 MB)
SaveSmall helps take it down a little to 1606 KB from 2 MB but still way above the 312 KB previously. Getting it down around 500 KB would be helpful but this may not be possible? Not really sure why the Boolean adds so much overhead to the file - is this just the nature of the tool? Can turn a small file large rather rapidly when carving out a few pockets.
Well, it depends on the geometry of course but you end up introducing trims into previously (presumably) simpler surfaces - those could be heavy, depending on the shapes and the tolerances in the file,and will almost certainly result is an increase in complexity of the rendering meshes (which is what SaveSmall leaves out, btw) . Or you could be cutting up relatively heavy (control point wise) surfaces into multiple parts - each of the parts will contain the full underlying surface that was cut up - in this case, again depending on the specifics, ShrinkTrimmedSrf may or may not help. That’s all that comes to mind at the moment…
In looking at the files you posted, I did notice that the original extruded model is an extrusion object. Extrusion objects are lighter weight, so that would explain why the file size is so small. The reason the file size gets larger after you run the booleans on the part is an extrusion object has to be converted to a polysurface in order for the boolean to work. Doing so will increase the geometry that is saved in the file. That, in turn, will make the file larger as mentioned by Pascal.
I was wondering if it is possible for your application to turn your parts into block instances. In the example screen shot, I have 275 of the booleaned parts arrayed in the file but I made them block instances. As you can see at the bottom of the capture, this results in a file size of approx. 1.8MB
Appreciate the input. I think that’s pretty much the path we have been trying to follow with all the component assemblies.
The file uploaded is one of the many different components inserted into the overall array through various nesting levels so hopefully we are using blocks as much as possible to reduce the file size overhead.
The current master array file of which ultimately holds this component as one of the many types within it is 73,055 KB. As a test, when I explode all levels of nested blocks in the array file the size increases to 417,523 KB so over 5 times the size.
As a further note I’ve also been working via email with Enric at VisualArq to troubleshoot bugs and the problems seem to be lessening with the recent updates so fingers crossed that continues.
