New Make2D of Viking head, 8 million polygon mesh

I am impressed, that it managed to crunch through an 8 millon polygon mesh is quite frankly amazing.
Rhino used 11GB of ram, the result is over 260.000 lines and Rhino became very slow. The calculation took 48 minutes for the perspective view:

I export the lines to Rhino 5 format and the file is 94 MB.
If I export as DWG the file is 22 MB.
Can you optimize Rhino’s line storage? This will be quite important IMO when people start using Rhino6 and make2D on large scandata.

1 Like

Do note that there’s a trade-off between compression and recoverability. The more the data inside a file is compressed, the more fragile it becomes.

That makes a lot of sense, but I have not had much trouble with stability with DWG’s during the last 10 years. Have you? Neither with 3dm files, so maybe “save small” could evolve into less recoverability too?

I welded the mesh at 80 degrees and ran make2d again and here is that result:

3 Likes

No, but I have had Grasshopper users who had damaged gh and ghx files. GHX is xml and can potentially be fixed by hand, whereas gh is zip-compressed and a single byte out of place will ruin the entire file.

1 Like

This discussion comes around every now an then. Basically it comes down to file storage space being so inexpensive, and increasingly so, that increasing the risk of file loss by compressing the file isn’t a smart trade off.

I fully appreciate that, and support it 100%, but when the files we are sending off are 500MB then things are different. So we can need an option to share small 3DM files. Maybe it should only be an export option, maybe as an share-only-small-3dm-zip, that way the files we work with are stable, and if the ones we share turns out bad we can export again. At least consider it a second time.

Are you saying you are sending uncompressed 3dm files?
Since file compression is now included as part of OSX and Windows, please tell me you use them…

Yeah, I’ve used compression since the 80’s :slight_smile:
7-zip is my preferred tool, as windows built in version isn’t very efficient at handling 500MB files.
And a 560MB file crunches down to 290MB in the versatile zip format.

I second Holo’s sentiment, sending of large files can be quite laborious and at times very frustrating depending on a variety of factors (just about all of which McNeel cannot control). However, that being said if an export option existed to hand off smaller, more manageable files, I would greatly appreciate it