I wonder if anyone can help? I’m trying to get my rhino model to be as small as possible from the off.
Saving the document, without any changes / any modelling, saves as 4Mb on my laptop. This feels crazy high to me compared with SketchUp, where the model I’m trying to replicate saves onto this program at only 450kb.
Is there a reason my base file is so huge?
For context, I’m experimenting with Rhino and the new drafting tools with V8. I’d like to use it for drawing, but it feels like it’s not work it when the file size builds up so quickly, esp. when cutting sections.
storing the file regular containg a simple cube test 1.3dm (4.5 MB)
export without texture and plugin data test 2.3dm (827.7 KB)
both have the exact same preview image
many people me included have mentioned this issue since the mac version launched as a commercial if i still remember right.
assuming that still could be the preview which as explained above does not seems to be quite right: i have a 4k+ monitor with 4608 x 3074 resolution, taking this as a reference which seems quite a bit overkill for a preview, an image needs less than 4,7mb, if you compress that with a very weak standard png compression that would already yeald 2mb, using jpg with a simple jpg compression maintaining a crystal clear image would even lower the file size needed to around 500 to 1000 kb which could still be reduced when slightly more compressed without losing detail. and not to forget we are still talking about a resolution higher than 4k.
besides all that the image still looks pixelated gobbling up space for nothing in that case.
here a snippet from a preview, fully aliased.
On R8 (r8.4) on a Mac, file size grows v. quickly, with only simple shapes and operations. A files of a few MB after small save becomes ≈2 GB after a few minutes/operations. No textures, just duplicating spheres and a few similar operations.
“Save small” on a Mac also erroneously wipes the “open with” file information, so a subsequent double click on the saved small R8 file opens in R7, or tries to before R7 complains.
Hello- the only ‘good’ reason for this would be the re-addition of display or analysis meshes meshes which are not saved in SaveSmall - if you have a repeatable example please send the small version to tech@mcneel.com to my attention, with an outline of the steps used to inflate the file size.
Seems like the version saving is growing exponentially. I’ll see if I can make a demo file, but making an array of 100 spheres, then performing some option-drag (copies), moves, cut and pastes seems to make the file big in no time.
Hello- but can you tell if is render meshes? Do the same, but before you start, make sure all viewports are in wireframe mode and stay that way throughout.
With wireframe, the file size is reasonable. With Shaded it is not, and the file keeps the added weight, even if I go back to wire-frame.
If I use shaded render (m2 metal default) the file becomes ≈30x larger for simple spheres with no changes except the display settings. See video. The view mode alone affects the stored size. The enlarged file slows Rhino8, even after save and quit, and reopening with a new file, as if it is accessing some large disc buffer (spinning beach ball). The mac is otherwise zippy.
I made the same file in Blender (25 x 25 spheres, smooth shaded) and the file stays small after saves (2.2MB) regardless of the rendering mode.
Video shows Rhino 8 with new file with 25x25 spheres, displayed as wire frame, saved, then displayed as shaded then saved, the wire frame then saved. File size is 1.9MB, 298.5MB, 298.5MB as seen in the “Get Info” window. (There are 2 warnings about frequent saves). And this is for an incredibly simple, low object count file.
In order to see NURBS objects on the screen in shaded mode, Rhino has to mesh them. Depending on the mesh settings the display meshes can be quite heavy, much heavier than the NURBS model alone. This might be particularly the case with larger spheres and fine mesh settings. What size are your spheres and what are your mesh settings?
In Rhino you can use _PolygonCount to see how many polygons are generated in shaded or rendered mode - actually, no need to switch display modes for that, it’ll generated the render meshes for you.
In Blender 25x25 UV spheres gives 600 000 triangles. Default settings for UV sphere, used two Array modifiers.
In Rhino 8 25x25 spheres with radius 1 in a mm file gives 10 080 000 triangles.
That is helpful. I now understand what is going on.
The sphere in Rhino was a default solid object 1m.
The sphere in Blender was default UV sphere 1m.
Triangle counts are as @Nathan
The file size seems to be due to R8 saving all the poly’s during routine operations, and at saves. R8 has also increased the sphere poly count by 4x over R7.
OK, but why? A sphere in space is fully described by a few numbers. Why are 625 of these records about a 1/3GB on disc? Is there an advantage of storing every poly? I can “save small” but is there a way to do this for automatic ongoing backups, thereby eliminating the multi GB files? On my system at least they can be recreated about as quickly as the file can be read.
The Sphere
Geometry:
Valid surface.
closed surface.
Surface of Revolution
U = angular parameter, V = curve parameter
“U”: Periodic (0.000 <= U <= 6.283)
“V”: (-1.571 <= V <= 1.571)
Axis of revolution: (-0.063,1.049,0.000) to (-0.063,1.049,1.000)
Angles: from 0 radians (0 degrees) to 6.28319 radians (360 degrees).
Revolute:
Arc
start = (-0.063,1.049,-1.000)
end = (-0.063,1.049,1.000)
center = (-0.063,1.049,0.000)
radius = 1.000
angle = 180 degrees
Edge Tally:
1 seam edges
2 singular edges
= 3 total edges
Edge Tolerances: all 0.000
Vertex Tolerances: all 0.000
Render mesh: none present
Analysis mesh: 1 mesh 8385 vertices 8192 polygons
Created with default analysis meshing parameters.
My recollection is the saving of render meshes predates 2009 when I started using Rhino. At that time computers were much slower doing calculations and with complex models there could be a significant reduction in time when openning a file or switching out of wireframe if the render mesh was already available. Hardware today is much faster and the time reduction may not be noticeable in many situations.
