I regularly work with model files in the 2gb+ range and having large files complicates things when working with limited file servers. Transfer times back and forth between the cloud can be long, and space needs can balloon quickly when saving versions of models.
Would it be possible to implement some sort of compressed 3DM file format? The performance hit would only happen when the file is opened and saved by the user. Autosaves could still be saved in the current format if it is more performant. And it could be made optional and not the default if users would rather use the default format.
I ran some tests on my end, and 7-zip (which uses LZMA) was able to compress a sample 2.7gb model file to 880mb (1/3 of its size) in about 10 seconds, using the fastest compression setting. Uncompressing only takes 2 seconds, which is nothing. This is a file that takes about 45-60 seconds to open and to save (to a mechanical HD, not SSD). Obviously more extensive benchmarking would be needed to evaluate things.
changing to a fast ssd would help a lot. Saving in rhino software could be light speed, but if its scratching to a mechanical harddrive you’ll still be waiting.
Thanks for the response. I am not concerned about save and open speeds, and I have tried the same file on an SSD without vastly different results (this is a newer machine with 11th gen i9 intel processor).
My request was about reducing the size of file after the save is complete, so that the files would be easier to manage and archive. For me, it would be worth a performance hit for smaller files.
When I audit my example file, it shows that the bulk of the file size is from objects:
63085 objects with 123494 plug-in data items, 2838815100 bytes (offset 1496692 to 2840311792)
Archive size = 2840635090 bytes (end mark size = 2840635090)
I did try “Save Small”, and that reduces the file size to 1.7gb, which is a pretty good savings, but I understand that this would dump all the display meshes and slow down the file the next time it opens.
My suggestion is to provide an option to compress the 3dm file, which only impacts performance when opening and saving the file, and gives a much greater storage savings (2.7gb to 900 mb), without dumping meshes.
@skysurfer yes, it resulted in a 1gb savings. But I understand this comes at the cost of performance the next time the file is opened (since the meshes need to be regenerated).
@stevebaer “save plugin data” only shaved a few mb off the file size.
Knowing now that Rhino is already employing compression (which only results in a 20% file savings, and is already impacting file open/save times), my revised wish is that a more efficient default compression algorithm be considered for future Rhino versions. Using 7-zip, I tested gzip, bzip2, and LZMA, at their fastest setting (least storage efficient), and all do better than 50% compression.
Maybe there is a way to use the 3d scan model as an external reference geometry which is not saved every time within the main file? Or Worksession manager?
If the external scan was “linked” instead of embedded, then yes, the 3dm would be smaller on disc but you would still have to store it, and manage it if files moved around. The point is there would be no net savings in combined file size like @d_j_c is looking for.
Regular use of the Save Small option to strip out render and analysis meshes is the only real file size savings.
I second better compression as a wish list item. I generate a lot of colored meshes coming out of analysis software like ladybug.tools and the internal Rhino compression does a poor job. Here is a Rhino file saved small with compression enabled, with that same “compressed” file thrown in a zip file:
I tend to get 70-90% file size reductions with these types of files when using zip. My office uses network drives, which can also be relatively slow, so it is not just an SSD vs HDD issue.
