The updated Audit3dmFile command in Rhino WIP presents an interactive “tree map” visualization showing the relative size of objects in the file.
Why is this useful?
Audit3dmFile allows you to see which objects (or data!) take up the most space on disk. Once identified, you can use the tree map (or the list) to select the object in the file.
If an object is selected, and you resize the Audit3dmFile window, the yellow selection frame loses the correct position.
I now see that’s already known…
Agreed. Added to the list: RH-89393 Audit3dmFile: Refresh button (I had thought I’d already logged it, but I guess I hadn’t). Thanks for the reminder.
I think I know what’s causing this and it’s related to this item: RH-87790 Audit3dmFile: Do not render rectangles that are under a certain size
…which is really part of a broader issue I’m not sure how I’ll solve just yet: the issue of having 500,000 small (in bytes) items.
Got it. Logged here: RH-89394 Audit3dmFile: Add Filename to Title Bar
Wow - this is a great tool! Nice having more ways to develop insights into where the weight in geometries is coming from.
Speaking of WinDirStat, (and also SequoiaView), how crazy is it that in 2025 we still have to resort to these little known applications to get a global view of memory usage? (I know the technical justifications for it on OS’es, but it seems conspicuousnessly ignored in the tech wold at large)
Thanks for testing and the encouraging feedback. It definitely has a long way to go…there are loads of bugs when dealing with 3dm files with very large numbers of objects (which I actually think is fairly typical these days).
In these cases, my current approach will likely be to only render the top largest, say, thousand objects (rectangles) in the TreeMap, but allow you to zoom to the areas of the TreeMap if you like. We’ll see where the wheels fall off with that approach.
It’s also way too slow to Audit those files with a truly large number of objects right now…but we can fix that in time.
…which is really part of a broader issue I’m not sure how I’ll solve just yet: the issue of having 500,000 small (in bytes) items.
Maybe a single pseudo-block representing the total size of all objects below a certain size threshold? Throw a “small objects” label over it, maybe with the object count, or give it a different color to distinguish it from single-element blocks.
Thanks for running it again Martin! Slowly, but surely, I’ll optimize for speed.
It contains all the plugin-specific “user data” goo - data that specific plugins can attach to objects, etc. I’ve been considering a way of breaking this out per-object - rather than per table - as sometimes that can identify a particular bloat issue that is item-specific, rather than plugin-specific.
I see. So even if “Layer with stuff” is actually a sublayer of Layer 01, Layer 01 would sort to the top, right? Instead of this?
Agreed. I thought I’d logged that one, but I think I’d forgotten… is this what you have in mind: RH-89801 Audit3dmFile: Save As button on legacy audit log ?
I meant it would be nice to see the layer path. In my files I always have child layers with identical names but different parents. The layer name itself does not tell me what it is or where it belongs to.
Is there a way for handling files like this (so many lineworks) can object in groups show as a single object? not sure, but for this test file (with linked PDFs) It took over 10 minutes to populate:
