Rhino file size Again:

Discourse Research to date reveals McNeels advice. Period.
Save As
Save Small
_purge command
_-SaveAs and check SaveSmall=Yes and SavePlugInData=No"
use blocks to make a simplified version of the file

616 MB down to 11.6 with 3 Clicks, rebuild invalid surfaces that were valid previously, to attain a final file size of 24.5 MB.

591.5MB of information needed to recreate the model, in the event it corrupts? Has to be more to it than that.

Another file of 7.95 MB down to 6.60 MB, same 3 Clicks!

‘How’ is for me to know, and Tech Support to answer you all.

Well, I don’t quite understand what you’re trying to say here…

If you’re looking for a cookbook solution to reduce file size, there isn’t one.

In order to understand what actually reduces the file size when you run certain commands, you need to know what exactly these commands do and what they’re modifying/throwing away. Most of this info can be found in the Help, but following is a résumé.

  • SaveSmall discards all the display/render meshes in the file. Depending on your meshing settings and the complexity of your objects, they can be quite sizeable. Doing this comes at the expense of Rhino having to re-create them the next time you open the file (if you use any shaded modes), which could take some time. Your render meshing settings themselves will affect file size, if they’re very fine, file size may increase significantly.

  • SavePlugInData=No discards any data created by any non-standard plug-ins like render engines, CAM programs etc. These could be quite sizeable as well, such as hi-res bitmap textures used as materials or toolpaths created for machining. Doing this will of course remove them from the file, so if you need them, you are going to be out of luck. However, sometimes plug-in data has been added inadvertently, or by someone else working on the same file and if you don’t really need it, this may help. Just keep in mind that it nukes data from ALL plug-ins indiscriminately, so if you need data from one of them and not the others, you’re out of luck again. IIRC, the next version might let you purge data selectively, but I haven’t checked if that has been implemented.

  • Purge will purge unused layers, block definitions and the like, that in itself may not reduce file size dramatically, but it also removes unused materials, which might.

  • One other thing not mentioned but worth verifying: see if you don’t have a whole bunch of hidden objects that are no longer needed and you have forgotten about…

  • As far as blocks go, if you have a lot of repetitive elements, you can save a lot of file size by making one element a block and multiplying the blocks. Blocks are simply transformation references to the original element, so they take up almost no space. However, blocks can be more difficult to edit, so you have to decide if the trade-off is worth it.

Finally, every situation will be different. In the case you mentioned of 600+Mb down to 11, something was really wrong - I suspect “stuck” render materials and the like but I really have no idea - but a minimal reduction from 8Mb to 6.6 is not really worth worrying about. File size is less of a problem these days with current RAM, disk and processor capacities. Sometimes large file sizes are just inevitable if you have complex models.


Well Mitch if you cannot understand Plain English, we might as well all give up.

In this particular there was cookbook solution (as you crudely put it), I only included the 7.95 MB down to 6.60 MB,as an example that the method was repeatable.

You well know what was previously occurring with the original file,
System to all intent and purpose USELESS…

All you can suggest is to upload a 616 MB file. when if anyone at McNeel really cared about the problems, you would get a simple program such as Team Viewer and take a look for your selves in real time!..

You can always upload files to McNeel at rhino3d.com/upload along with a detailed description of the problem you are experiencing.

FORGET IT, your all from the same mould.

Wow, that’s a pretty unpleasant thing to say, to put it nicely… Time spent trying to explain stuff to you seems not to be acknowledged or appreciated, so I guess I won’t bother anymore… Good luck.



Hi Douglas - reading this thread, it’s hard to tell if you’re asking for some help, or just using the opportunity to yell. It looks a lot like the latter, but if you have a question or suggestion, just possibly, I’m going out on a limb here, a complaint, about something in Rhino, please just state that as clearly as you can - as Nathan pointed out, you can upload files to us, that would probably be useful here. Also, it’s the weekend.



Good summary, thanks Mitch.

@Douglas1 The command ‘Audit3dmFile’ is a good place to start when a file is bigger than you feel it should be. Try it, it breaks the file down into parts - plug-in info, materials, textures, lurking bitmaps etc. and allocates bytes used to each section. You’ll soon see where the size is suspect.


Hey here’s a secret…they DO use stuff like Team Viewer where it is helpful. I’m not sure how it would help them see what the extra junk in the file is, mind, as opposed to just opening it up in their developer tools.

It’s 2017, uploading a 650mb file is not really an onerous request…and it’s somewhat ironic to prefer desktop sharing, which is also very bandwidth-intensive. Is this trolling? I mean seriously, who insults MITCH? And what exactly are you complaining about, it’s possible to have really big files? Again, it’s 2017, unless it’s the result of a bug who gives a crap how big they are? You’re not saying it is due to a bug, for all we know from your incoherent babbling it might just be the render mesh data–which you can choose to never save–or it’s coming from a 3rd party plugin, in which case it’s not strictly speaking McNeel’s problem.


Now that you have all ‘chirped’
On reading the post, it is obvious that my comment (FORGET IT, your all from the same mould) was directed at nathanletwory ‘NOT’ Helvetosaur ‘Mitch’

Nathanletwory ‘chirps’ into a conversation that he has ‘no’ prior knowledge off. But Helvetosaur ‘Mitch’ does!

It had already been explained to Mitch that due to forces beyond ones control. Save the TOT Public Company Limited Thailand. It is just not possible to upload a 616 MB (zipped or no) Consistent dropped link. However it might stay connected long enough to use a program such as Team Viewer to at least witness what was occurring.
I trust that is plain enough for Mr. Jim Carruthers to understand, or will he still determine plain English to be ‘incoherent babbling’

Being at the start I raised:
Discourse Research to date reveals McNeels advice. Period.
Save As
Save Small
_purge command
_-SaveAs and check SaveSmall=Yes and SavePlugInData=No"
use blocks to make a simplified version of the file
I was perplexed as to why Helvetosaur ‘Mitch’ should explain them in detail. I was obviously aware and had tried them all. To NO Avail.

Pascal and Brian M at least have the right attitude, although Pascal is not aware of the reason one cannot upload, and probably not aware that a dump file sent previously revealed nil.
One is perplexed by Pascal’s statement (I’m going out on a limb here), and (Also, it’s the weekend)
Rhino is used all over the world, time zones and cultural practice should not come into it.

However: The answer to Pascal’s enquiry (please just state that as clearly as you can) was previously posted 9 days ago. To answer Wim’s enquiry. As follows:
For one, Surfaces are going bad when one has been nowhere near them, save breaking and joining the model looking for any bad entries on what one has just put right.
Two: copy a valid set of joined surfaces into a new drawing, and it becomes Invalid.
For another join a valid surface to other already joined valid valid surfaces and it crashes.
Sent the Dump file to McNeel, they come back it does not tell them what they need to know.
That is when Helvetosaur ‘Mitch’ became involved.

Brian M, writes (The command ‘Audit3dmFile’ is a good place to start when a file is bigger than you feel it should be. Try it)
Audit3dm was carried out on the inflated file and the rebuilt file, in anticipation that someone at Tech-Support would raise it,
Both files have been sent to a world renowned authority in this field for comment.
I did not bother to send them to McNeel, as the last two messages remain were not replied to. So what is the point? So YES Pascal I used the opportunity to Yell.
One cannot get to the bottom of anything with your organization, the constant chirping from persons with no prior knowledge is to say the lease Unprofessional.

So I will finish of here by putting Mr Jim Carruthers hat well and truly ‘straight’
10 Days ago Sep 22 at 7:47 PM I wrote to Helvetosaur ‘Mitch’ amongst other the following.
Mitch thanks for trying to assist,.

Gentlemen. The facts remain;

  1.  A Rhino file should never have reached a file size of 616 MB. In doing so it caused to many problems to list with the system (Dell M6800 – Win 10 Pro – Rhino V 5)
  2.  It was not possible by your recommended action to substantially reduce the file size.
  3.  The file now reads 25.7 MB slightly up from the 24.5 MB attained previously. (worked on)
  4.  All previously trimmed surfaces, can be un-trimmed.
  5.  The system Rhino V 5 and Win 10 Pro, have returned to their normal function.

‘Incoherent babbling’ I beg to differ.

Well, my better judgement speaks against posting this but…

This is a public forum; you are getting answers here from both users and McNeel staff. Everyone in here is free to post contributions to a particular subject - whether you think they are helpful or not. FYI:

Pascal, John Brock and Nathan work for McNeel (but in two different parts of the world)
Jim Carruthers and myself are authorized Rhino resellers and longtime users (but not McNeel employees)
Everyone else that answered you is a fellow Rhino user, all with a lot of experience.
So note that with the exception of the McNeel employees, everyone in here trying to help is doing so for free and on their own time. And as noted earlier, some McNeel employees are also answering on their own time (weekends).

It’s the weekend at McNeel offices around the world, that means most of the main McNeel people are not in the office (taking weekends is “cultural practice” in many places). Pascal is probably posting from home, as I am here on a Sunday morning.

There are lots of other people in here besides yourself, I wrote those explanations for the benefit of all in case someone else has a similar problem. While on that particular subject, you seem to think this is a generalized problem that happens to everyone, which it is not. It is is something related to your particular file or to your particular setup, and everyone in here is making suggestions to help you ascertain what is causing the file size jump.

Dump files sometimes can contain a pointer to where the crash occurred - as in the video driver or a particular plug-in being used - but unfortunately do not always reveal any conclusive evidence. They are just another diagnostic tool that might yield clues (or not).

That was excellent advice from @BrianM, I always forget to run that first. But, as you did not post the results of the audit here, nobody really knows still what might have caused the problem. You also did not supply any information on your setup, or if you are using any McNeel or 3rd party plug-ins such as rendering and the like (or maybe I missed that).

Things going bad can sometimes happen because they were bad to begin with, but for some reason the object checker didn’t flag them as such when they were created - but then the simple act of moving or copying them can “wake up” the object checker and suddenly it tells you the object is bad. If Rhino crashes during a simple operation like Join, it is most often a sign that something is unstable with the system, or something put Rhino into an unstable state. The second is pretty rare - Rhino is extremely stable - but it can happen.

This is not true. Although your file in this case should not be that big, Rhino can handle that file size easily - I regularly work with files that big or larger. And an M6800 should also be able to handle that file size without a problem.

What actually did then? I didn’t see that information posted anywhere.

Please let us know what the “authority’s” conclusions are…

(voilà an hour spent on this Sunday morning)


Too many chile pepper in the Tom Yum…

Not gonna happy…


If you have file size upload problem, split the file into multiple parts and send over several separate uploads:
For example: KB Corel: Split Zip files and how to create them
There is no better way to figure out the problem than looking at your actual file.

But first and foremost, your attitude on this forum needs as much fixing as your file size problem.
Please be respectful and invest some time to write clearly - you will have much better chances of getting help and advice that in many cases here is voluntary and you could be effectively discouraging it.


1 Like

Remarkable to read of your ire. I’m a big fan of Rhino 3D and have used it with great success since the first beta was released. While it may not be as powerful as programs costing five times as much, as NURBS based CAD programs go, it’s the best in my book. From mental concept to Rhino to Reality; just look what it has done for me and my clients. If your’re going to bitch. bitch at the prices of the expensive Gods of CAD; they are the ones that deserve it.


Good morning Mitch

Now the dust has settled, perhaps common sense will prevail. To what at the end of the day was no more than an Intelligence Test.?

616 MB down to 11.6 with 3 Clicks.

It is perfectly clear that I was referring to 616 MB file, but you decide to go off on a tangent re the virtue of the file size Rhino can handle. (Vested interest as a re-seller no doubt) But then of course that depends on the hardware does it not?
As you rightly state (And an M6800 should also be able to handle that file) Dell M6800 that is.

No you did not miss information re McNeel or 3rd party plug-ins such as rendering and the like
There is only one third party plugin on my system and that is Orcad3D that has always performed flawlessly, however it has not been applied to the particular file. As for anything else kindly note the file has never been rendered, not even with the rhino renderer.

Generalized problem: Enter into any search engine ‘Rhino file size’ to note numerous entries referring to it. Therefore it cannot possible be ‘something related to your particular file or to your particular setup’
You have noted the machine is a Dell an M6800 laptop/work station. It has also been made clear the machine runs Win 10 Pro, the latter having been purchased ‘not free’

One appreciates the ec2638 Humorous comment. Obviously someone laid back with nothing to prove.
As for Robb what can one say, apart from question his purchasing power.

Now Jarek is a whole different ball game. He offers clear concise advice re splitting a zipped file into manageable portions using WinZip, kindly note for those who do not have deep pockets 7-Zip has the same capability. But then spoils it.
So let’s be clear. I have never directly sought from the Forum ‘help and advice’
Obviously when researching the net articles from the Forum appear that in some cases do assist, likewise points raised by users in the monthly newsletter.

So to end this Saga, be aware I do not intend to give McNeel or anyone else ‘at this time’ any more than advise 616 MB down to 11.6 with 3 Clicks. As when I have contacted Tech-Support in the past they have never got to the bottom of the point raised, and when on one occasion they did acknowledged a point raised, (to be put on the pile) as they put it. Obviously is still in the pile along with numerous other raised over years by users? Notwithstanding the times they have not bothered to respond at all.

An answer to the exaggerated file size is known and provable (Graphics of what is there that should not be there) However as some of the junk it still in the reduced sized file, there is more to it!
Now if someone wishes to conclude that it is the Dell M6800 and Win 10 Pro is responsible. Not Rhino: Carry on!

But I would say first and foremost, the attitude of McNeel, not I that has to change. 3 Clicks is all that it took to reduce a 616 MB down to 11.6 MB, how small it can be once the answer to removal of the remaining junk, remains to be known.

Finally the whole point as to how I first posted the subject, was meant for McNeel to put there thinking cap on and investigate in a professional manner, with the aim of building a better program. To date they have failed.
They have my email, and despite all. They can have the evidence if they really care about users that purchase their product.

Good day to you all, it has been an interesting experience.

No, 20 years of experience as a user. I have no vested interest in this at all.

Sure it can. There are thousands of Rhino users creating files with the program every day, with dozens of expert users right here in this forum. If it was a generalized problem that affected more than just a tiny percentage of users and files, you, me, and everyone else here would hear about it. But it’s not, much as you would like to believe so. Well, you’re free to believe what you want.

The solutions to removing the “junk” were all given to you. That is not the issue. The question is to know how it got there in the first place. Without the file to analyze or your posting the complete results of Audit3dmFile, that will still be impossible for anyone here to determine.

If you are able to provide McNeel or anyone else here with a “recipe” for creating a bloated file that can be repeated reliably, than that will point to a concrete bug that can then be fixed. However, if there isn’t a way for anyone to reproduce the problem, then it likely will never get addressed - for obvious reasons - there is nothing to analyze or work on.

Yes, interesting is a good way to describe it.


1 Like

There is still a sliver of hope for anyone able to comprehend and process humor.

Oh, I have plenty to prove…trust me.

@Helvetosaur deserves a medal.

Heck we don’t even know if the ‘junk’ is actually ‘junk.’

Was hoping to learn something from this thread, but can’t figure it out with the unproductive discourse.


If you’re looking for objects that take a lot of room, V6 has an improved tool.

The Audit3dmFile command in Rhino V6 has been improved to report all of the object detail. The downside is the list can can get long.
After generating the list, you can visually scan down the page to find objects that have really big byte sizes. Take note or their object IDs.
Then use the SelID command to select them in the file.
At least then you can find them semi-efficiently.

Commonly found problems are plug-ins that duplicate material definitions and attach them to multiple objects, use of inappropriately large image files when making textures or PictureFrames (Picture for V6), and inappropriate use of blocks. There are others, but that’s what I see most of the time in tech support.

Keep in mind that an inappropriately large file size is almost always a symptom of a different problem.
Find and fix the problem.