Site Tools


How did my file size get so huge?

Periodically there is a post on the Rhino forum by a user that has seen their relatively simple file grow to a huge size and they don't understand why or how to reduce the size back to “normal”. This article will attempt to explain what has happened and why; as well as offer some possible fixes.

What causes "file bloat"?

Several things can dramatically add to file size:

  • Display meshes - Rhino uses special meshes to display surface objects on the screen. Very fine display mesh settings can cause large file sizes without you realizing it. You see the display as normal, but you are not necessarily aware of how many polygons the display mesh has.
  • Textures/Bitmap images - High resolution bitmap textures stored in the file - used as render materials or for picture (frame) objects you created - can dramatically increase file size.
  • Materials - it is possible to have a large collection of materials which can take up a significant amount of file space. Sometimes materials get needlessly duplicated, multiplying this effect.
  • Plug-ins - Rhino plug-ins can add all kinds of additional functions to Rhino from advanced rendering to branch-specific design tools to CAM. Plug-ins are allowed to store their own data in the Rhino file, and it can be quite copious depending on the nature of the plug-in and how it was used.
  • Big data - finally, Rhino files can simply contain massive amounts of geometry in the form of curves, surfaces or meshes. Large file sizes in this case are to be expected…

How can I see where the problem is?

Having read the above, you might already have some “usual suspects” in mind. If so, you may be able to skip this section and go to the “possible remedy” section below.

However, if you are stumped, or just want to see all of what your file contains in extreme geeky detail, you can use the Audit3dmFile command inside of Rhino. You can run this on the Rhino file you currently have open or even some other 3dm file on your computer. A text window will open with a lot of info. The top section will be some info about your Rhino installation and what plug-ins are loaded. Below that comes the interesting part - the various “tables” where information is stored in the Rhino file being analyzed.

  • First is the “Bitmap Table”. It will tell you how many bitmaps are in the file, and most importantly the total size. If you see some very large numbers in there (they are in bytes, so be careful) that might explain part of your file size.
  • Next is the “Material Table”, which you should also check for size.
  • Further down is the “Object Table”, which will give you a summary of how much storage space your actual geometry is taking up. In V5, you will only see the total size of all the objects; in V6 and later, it will show size details per-object as well. Note that the object size includes the attached render meshes, which might be useful if that is what is contributing to the file size problem.
  • Lastly, at the bottom is the “Model User Data Table”, which enumerates all the plug-ins that are loaded and any data they are storing. If any of those are very large, that is another suspect to consider.

OK, I see some possible suspects, how do I proceed now?

  • Display meshes: If you suspect your display mesh settings are causing an inflated file size, there are several things to try. You can try using the command _SaveSmall, which will save the file without the render meshes. Check the freshly saved file size, if it has dramatically decreased, that was at least part of your problem. If you want to preserve the original, you can also use _SaveAs with a different name and check the box “Save small” in the dialog.
  • Materials: If the materials table contains large entries, you could first try the _Purge command with _Materials=_Yes. That should purge any unused materials, see if that helps. If not, see the Plug-in data section below…
  • Bitmaps (images): If the bitmap table contains large entries, it could be one of several things. Picture(frame) images, background bitmaps and images applied as textures are all stored in the Bitmap Table. You might see if you have any unused textures that are somehow stuck in the file and eliminate them, and remove any Picture(frame) elements you no longer need. However, that might not always fix things, sometimes bitmap images get “stuck” in the file even when the object that carried them such as a Picture(frame) is deleted. In that case, you may have to “go nuclear” and purge the bitmap table. In Rhino V5, there is a test command to do this - TestPurgeBitmapTable - you have to type it all out, it does not autocomplete. BEWARE, this will remove ALL bitmaps from the document, including some you might still need, so use this command carefully…
  • Plug-in data: Data created by Rhino plug-ins stays in the file even if the Rhino instance opening the file doesn't have the appropriate plug-in(s) installed - you can't access it, but it's still there and doesn't get purged when re-saving the file. That's actually a good thing.

    However, perhaps you got a file back from your render person with all their custom materials in it, or from your modelmaker with all their CAM toolpaths in it; you don't want any of that stuff anymore anyway and would like to reduce the file size if possible.

    The way to do that is to use _-SaveAs (with the dash!); on the command line you will see an entry _SavePlugInData. Set that to _No and save. Warning: this will nuke all data from all plug-ins (currently) so make sure you are really not going to need this stuff again! Good idea to make a copy just in case.

    Using the above procedure to remove plug-in data can also solve some of the problems with data from some “unknown source” that is “stuck” in the file that you haven't been able to remove any other way.
  • Massive amounts of geometry in the file: As said earlier, assuming the file has already been created, there is not all that much you can do about reducing the file size in this case - Rhino needs that space to correctly describe all the objects. If you need to send the file to someone, zipping it often helps reduce Rhino file size significantly. If you haven't already created the file, and you will be having lots of identical objects in it, using blocks may help keep file size down. See the Rhino Help for more on using blocks.

    If your object table memory size is very large and you really believe it shouldn't be, then you will have to go on a search for the object or objects that are causing the file size. Check first if anything is hidden or on an off layer that might be causing the problem. Another thing might be one or more huge surfaces (with thousands of control points) that have been trimmed down to a small size. you may think they don't take any space, but Rhino stores the original (untrimmed) definition of the surface, so an apparently small surface may indeed take a lot of memory. The command _ShrinkTrimmedSrf will remove the unneeded part of these surfaces.

What other possibilities are there?

Some other things that can be tried if all the above fail…

  • Sometimes opening a new blank file, copying and pasting the geometry out of the old file and into the new can fix things. But, sometimes, the objects can still bring the monster stuck bitmaps to them when copied, so you're back where you started.
  • If things are really bad and absolutely nothing else works, you can try using _SaveAs and check “Geometry only”. In principle only the actual objects will survive that one, but beware, it also completely destroys any file organization, the objects will all end up on only one layer, no color, no groups, no nothing… Really a last resort.

(comments welcome...)
rhino/checkreducefilesize.txt · Last modified: 2017/10/19 by mitch