Rhino file size Again:

Here’s a slightly different version,

  • if any items are preselected, it will report the memory footprint of all selected items
  • if nothing is preselected, it will ask you how many items you want to check. This way will also include hidden or locked objects as well as those on off or locked layers.
  • Lists (largest first) the object ID, est. memory use, and whether it’s valid, locked or hidden

Formatting is not incredible, but it gives you the info in a text out window that you can copy somewhere.

Edit: revised version
DisplayObjMemEstimate2.py (2.7 KB)

–Mitch

1 Like

Looking at the attached Jpg in @Douglas1 post above, I doubt whether you could reduce the size of the file anyway - looks like a really heavy mesh with thousands of faces.

Here is a screenshot showing how meshes, converted from a clean surface in this case, can increase (edit) the file size, obviously growing with the fineness of the mesh.

Thanks a lot @Helvetosaur and @emilio for these scripts, really useful having object size knowledge just a click away.

I think bloat isn’t the right term. For dense meshes that is just how it is. Large memory footprint yes, bloat not really. Of course one can question the necessity of ultradense meshes, but then one should also ask why the user chose to create those.

The images do nicely illustrate how the use of certain data can cause files to grow, though.

Completely agree, sometimes you have no choice if using a file from an external source. In the case attached, I would create a very simple re-model or some datum geometry and export the culprit to a reference file.

ReduceMesh does a great job most times in these cases and gives you a good control over how heavy the imported mesh is ( sometimes on imported mesh models it produces a much better result if RebuildMesh is run prior to the ReduceMesh command )

-j

In that case it´s logical that the file size becomes bigger with more density. But if you import a large stl scan file or a model with countless fillets or point clouds or thousands of lines and polylinies you don´t know what kind of bad geometry you get in the background. For example i also know invisible objects that you can select with “selall” but you can´t "zoom to it and Rhino tells you what it is, but you can´t delete it. I also got files with 80000 lines with zero length that made the file ten times bigger but it was possible to delete it with selshortcrv. I also know imported files from Creo or NX with strange untrimmed visible fillets but no way to delete it, because you couldn´t select it. That´s one of the reasons i stay as long as possible in my Rhino tools and try to deliver as much as possible from myself. In both directions it´s mostly some extra work to transfer all informations.

And you are reporting (i.e. sending in the files) each and every one of these cases, I hope?

Hi Mitch

Yes … I was thinking about something like that …
But did not find the time, so I posted the bare-bones release. :wink:

Thank you for the improved version. Much better ! :slight_smile:

You’re welcome Brian ! ( But Mitch and Rolf did most of the work … :wink: )

In general, those are “bad objects” that will select with _SelBadObjects… If you can’t delete them, Ctrl+X (cut) often works to remove them. That being said, while “phantom objects” were somewhat common in the past, I haven’t seen them much at all in recent versions… This is an old Wiki article I wrote on the subject…

Well, they probably weren’t really 0 length - not allowed in Rhino - but possibly really, really tiny…

Bad objects again, most likely…

Sounds like most of this stuff is related to importing files and not what Rhino has produced - thus not something that can really be fixed. However, hopefully we have the tools to detect and delete…

–Mitch

_selbadobject and cut couldn´t fix these problems, don´t know why. But mostly it´s enough to copy/paste the good stuff in a new rhino.
You are right, with V5 and the latest SR most of this is history. I don´t understand all that software stuff in a mathematical way, so i can only report my experience over the years, but it was always imported geometry.

Hmm, running into a small problem, the “Text out” function is not letting me output more than 20 lines… Not quite sure what is happening there, could be the length of my lines, as I tried with shorter ones and it works… Obscure bug, appears to be fixed in the WIP, so sorry.

Here is a revised version that will use an EditBox for V5 if the number of objects is >15. Couple of other small refinements as well.

DisplayObjMemEstimate2.py (2.7 KB)

–Mitch

1 Like

I just ran into a typical example here - on a milling project with several similar models, I noticed that one model was taking a long time saving, so I had a look at the file size. While all the other models in the series were around 20-30Mb (toolpaths included), this one was around 130 Mb. This is what Audit3dmFile showed:

The object table has about 6Mb of geometry:

image

The CAM toolpaths take up about 25 Mb:

image

So, where is the rest of the file size coming from? The Bitmap Table entry shows the culprit:

image

102 Mb for an invisible bitmap…

In this case, only TestPurgeBitmapTable worked to remove the bitmap… File size reduced to 30Mb.

–Mitch

2 Likes

Is this “mystery” content, or do you know exactly where it came from now that you’ve done the analysis to remind you?

In general, I work with student files, so I never really know where this stuff comes from… However, pretty easy to guess in this instance, looking at the image name and knowing that this is a terrain model, it’s a hi-res orthophoto (aerial view) that got stuck on a surface somewhere…

–Mitch

Great observation! I have learned a lot of great techniques by fixing beginners mangled files. And, of course, visiting this fine forum.

As we have architecture students, frequently the files that end up here at the model shop have been through AutoCAD, ArchiCAD, VectorWorks, Sketchup, Rhino, or all of the above…

Not to mention containing imported objects from who knows where on the .net… :stuck_out_tongue_closed_eyes:

–Mitch

A post was split to a new topic: RhinoCAM file bloat?

Hello - you can remove all plug-in userdata, but, depending on what you have, you may or may not want to do that -
-SaveAs SavePlugInData-No

-Pascal