I know the arguments against a overly compressed 3dm documents: The current setup allows for partial document recovery when files get corrupted and since harddisk space is relatively cheap, the pressure to compromise on data safety is low.
However…
There are situations I run into that makes me wish for a compressed 3dm fileformat:
When on the road, mobile internet is often of very poor quality; sending up to 300% more data is not an option so I find myself zipping all files I send.
Yes, harddisk space is cheap, yet professional online/cloud backup storage is not.
and even if it is cheap, see the argument above about slow internet speeds when on the road or at the offce when stuck with a @%$# ISP.
What do you think about adding a functionality in V6 to _SaveCompressed?
Thinking out loud:
Files would be stripped of meshes (like SaveSmall) and all object attributes regarded as “default” would be discarded or filled with a small placeholder. Upon opening the file all these placeholders are populated with default values…or whatever type of mechanisms could lower the file footprint.
Finally a maximum compression would be applied.
@Willem, just fyi, I ran this by the developer - it would, (as you suggest), need to be a separate thing and not a replacement for Save, the sticking point being that the compressed file would not be recoverable in the event of corruption. Rhino files can often be fully or partially recovered even with some corruption to the bits and bytes.
Hi Pascal,
Thanks for the follow up, indeed like it was pointed out in every discussion that popped up on the NG every now and then, recovery is a great advantage. If Rhino can come with it’s own (de)compressor I think the advantage could be that apart from a final generic compression algorithm, the data could first be stripped of generic data that can be filled after decompression. Maybe this is already done, but there is no point in setting geometry attributes when those attributes are all the default values.
I guess an analogy is that of a series of point objects versus a pointcloud.
May I use the opportunity to again wish for more cloud type objects for V6 (Curve-cloud) (Surface-cloud).
A good example in my workflow is managing make2D results. Files with many curves get slow when handling, if the curves could be clouded that could increase the handling speed (or so I was told), and probably also the filesize of generic 3dm files.
