# Parsing content of a 3dm file - identify large chunks

**URL:** <https://discourse.mcneel.com/t/parsing-content-of-a-3dm-file-identify-large-chunks/204089>\
**Category:** Scripting\
**Tags:** windows, scripting\
**Created:** [May 6, 2025, 7:23am UTC](https://discourse.mcneel.com/t/parsing-content-of-a-3dm-file-identify-large-chunks/204089 "2025-05-06T07:23:56Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![sonderskovmathias](https://sea3.discourse-cdn.com/mcneel/user_avatar/discourse.mcneel.com/sonderskovmathias/32/478545_2.png) [@sonderskovmathias](https://discourse.mcneel.com/u/sonderskovmathias)\
**Post date:** [May 6, 2025, 7:23am UTC](https://discourse.mcneel.com/t/parsing-content-of-a-3dm-file-identify-large-chunks/204089/1 "2025-05-06T07:23:56Z")

</div>

Hi I have a few files that get extraordinarily large and I cant seem to find out why.

I’m looking for a way to parse length of serialized data in my 3dm file to identify large objects.

Something that could output a piechart og textures, user data, saved block definitions etc etc. Eventually also size of content pr layer etc.

I might give it a shot to script it myself - but throwing it out there in case other people have done something similar, or eventually if enough people would like this to pitch as a feature request in V9.

If I’m to look at it myself i was thinking to go through the Rhino.FileIO namespace.

---

<div class="post-metadata">

**Author:** ![dan](https://sea3.discourse-cdn.com/mcneel/user_avatar/discourse.mcneel.com/dan/32/481637_2.png) [@dan](https://discourse.mcneel.com/u/dan)\
**Post date:** [May 6, 2025, 3:30pm UTC](https://discourse.mcneel.com/t/parsing-content-of-a-3dm-file-identify-large-chunks/204089/3 "2025-05-06T15:30:25Z")

</div>

Hi Mathias-

I’m working on a utility to help with this for Rhino 9. It’s not quite ready for prime-time but should be testable in the not-too-distant future. It’s a sort of `Audit3dmFile` (Graphically). There are loads of glaring bugs I’d like to fix before announcing this for broader testing, but you’re welcome to test it now on your files with `TestAudit3dmFile`. Please test with the latest RhinoWIP only.

I would really appreciate it if you could share your file with me. It would really help to have samples of “in-the-wild” 3dm files that necessitate such a tool. Can you privately share it here: [Upload to McNeel](https://www.rhino3d.com/upload) ? (If you can, please add [dan@mcneel.com](mailto:dan@mcneel.com) as the recipient address).

-Dan

---

<div class="post-metadata">

**Author:** ![sonderskovmathias](https://sea3.discourse-cdn.com/mcneel/user_avatar/discourse.mcneel.com/sonderskovmathias/32/478545_2.png) [@sonderskovmathias](https://discourse.mcneel.com/u/sonderskovmathias)\
**Post date:** [May 6, 2025, 7:20pm UTC](https://discourse.mcneel.com/t/parsing-content-of-a-3dm-file-identify-large-chunks/204089/4 "2025-05-06T19:20:39Z")

</div>

Hi Dan,

Fantastic! Great minds think alike 😉 .

I didn’t know about the current Audit3dmfile - looks like many of the clues I was looking for are hidden here.

I’ll try out the command when I get WIP installed - also sending you my annoying real life file through the upload system. It has a heavy mesh on my walls layer - so heavy that there’s quite a lag when i change clipping planes - but that’s for another thread 😉 .

 ![image](https://global.discourse-cdn.com/mcneel/uploads/default/original/4X/7/e/8/7e85977ee3bc087616e72a2f7ff68d16ef5d5308.jpeg)

If you’re curious then it’s a file I use for calculating daylight through some rule of thumbs in a grasshopper definition and it will print pdf reports like this:

 ![image](https://global.discourse-cdn.com/mcneel/uploads/default/original/4X/b/9/a/b9af922ad749bb137ad0c0ab7ddbfb84178914de.png)

---

<div class="post-metadata">

**Author:** ![dan](https://sea3.discourse-cdn.com/mcneel/user_avatar/discourse.mcneel.com/dan/32/481637_2.png) [@dan](https://discourse.mcneel.com/u/dan)\
**Post date:** [May 6, 2025, 8:26pm UTC](https://discourse.mcneel.com/t/parsing-content-of-a-3dm-file-identify-large-chunks/204089/5 "2025-05-06T20:26:52Z")

</div>

> [@sonderskovmathias](#):
>
> I didn’t know about the current Audit3dmfile - looks like many of the clues I was looking for are hidden here.

Yes, we sometimes use `Audit3dmFile` and it’s quite useful…but also lacking if you just want to know where the bloat lies. The successor command hopefully will show you without having to parse a bunch of text. As you’ll see when you test, I’m currently using a TreeMap (I’m a fan of [WinDirStat](https://windirstat.net/)), but I also think a radial TreeMap could work (I’m also a fan of [DaisyDisk](https://daisydiskapp.com/) on Mac).

Thank you so much for the file and the background info! This is already tremendously helpful. Your file immediately exposes a bunch of flaws in my current approach, which is great. Exactly what I’m looking for…files with TONS of stuff:

 ![Screenshot 2025-05-06 at 1.21.52 PM](https://global.discourse-cdn.com/mcneel/uploads/default/original/4X/2/4/6/2462d997ccec396484afeffae4d0b94b97a58f55.png)

I’m curious what conclusions you come to with vanilla `Audit3dmFile` and if they would be the same with `TestAudit3dmFile`. As it stands now, with your file, I don’t think it would be helpful…yet.

---

<div class="post-metadata">

**Author:** ![sonderskovmathias](https://sea3.discourse-cdn.com/mcneel/user_avatar/discourse.mcneel.com/sonderskovmathias/32/478545_2.png) [@sonderskovmathias](https://discourse.mcneel.com/u/sonderskovmathias)\
**Post date:** [May 6, 2025, 8:42pm UTC](https://discourse.mcneel.com/t/parsing-content-of-a-3dm-file-identify-large-chunks/204089/6 "2025-05-06T20:42:03Z")

</div>

You mention my 2 favorite disk apps 😉 . Wow it looks great so far, exactly what I was looking for.

Few ideas:

- Might be nice to have ‘cleanup’ buttons in the interface such as “delete all userstrings (save 943kB) / plugin data (save 2MB)”, materials etc (a bit like purge but allowing to delete stuff in use)

- You’ve grouped it nicely but maybe it would be to see another distribution of the objects: Perhaps instead of measuring bytes per object, it could be split in geometry, userstrings, plugindata, and pool that across of objects. Especially its nice for developers to double check if something is added to objects by mistake.

I’ll let you know when I get WIP installed after current deadlines.

---

<div class="post-metadata">

**Author:** ![sonderskovmathias](https://sea3.discourse-cdn.com/mcneel/user_avatar/discourse.mcneel.com/sonderskovmathias/32/478545_2.png) [@sonderskovmathias](https://discourse.mcneel.com/u/sonderskovmathias)\
**Post date:** [May 6, 2025, 8:43pm UTC](https://discourse.mcneel.com/t/parsing-content-of-a-3dm-file-identify-large-chunks/204089/7 "2025-05-06T20:43:37Z")

</div>

Also, Mb per layer would be super useful.

---

<div class="post-metadata">

**Author:** ![sonderskovmathias](https://sea3.discourse-cdn.com/mcneel/user_avatar/discourse.mcneel.com/sonderskovmathias/32/478545_2.png) [@sonderskovmathias](https://discourse.mcneel.com/u/sonderskovmathias)\
**Post date:** [May 6, 2025, 8:47pm UTC](https://discourse.mcneel.com/t/parsing-content-of-a-3dm-file-identify-large-chunks/204089/8 "2025-05-06T20:47:55Z")

</div>

i ended up exporting layers separately to identify chunks. Found out my grids layer is 200Mb of 300Mb!

 ![image](https://global.discourse-cdn.com/mcneel/uploads/default/original/4X/a/b/e/abe2bd3fdbd7a8edefd698be4a8aa1108e219e6d.png)

might be related to each grid having a few userstrings (x 2500 surfaces):

 ![image](https://global.discourse-cdn.com/mcneel/uploads/default/original/4X/c/1/6/c16562fde51fdc69f6d33f9bb9a0b0707a5a9e04.png)

---

<div class="post-metadata">

**Author:** ![martinsiegrist](https://sea3.discourse-cdn.com/mcneel/user_avatar/discourse.mcneel.com/martinsiegrist/32/498369_2.png) [@martinsiegrist](https://discourse.mcneel.com/u/martinsiegrist)\
**Post date:** [May 6, 2025, 8:49pm UTC](https://discourse.mcneel.com/t/parsing-content-of-a-3dm-file-identify-large-chunks/204089/9 "2025-05-06T20:49:39Z")

</div>

Interesting!

I just ran the test command on a 779 MB file. It took 5 minutes to execute.

 ![image](https://global.discourse-cdn.com/mcneel/uploads/default/original/4X/b/0/c/b0ca16747e5371bc9ed1d21c94cc5b6a546c7beb.jpeg)

---

<div class="post-metadata">

**Author:** ![sonderskovmathias](https://sea3.discourse-cdn.com/mcneel/user_avatar/discourse.mcneel.com/sonderskovmathias/32/478545_2.png) [@sonderskovmathias](https://discourse.mcneel.com/u/sonderskovmathias)\
**Post date:** [May 6, 2025, 8:54pm UTC](https://discourse.mcneel.com/t/parsing-content-of-a-3dm-file-identify-large-chunks/204089/10 "2025-05-06T20:54:12Z")

</div>

Exporting grids with the options of “save small” and “geometry only” → 20Mb  
Exporting grids → 200Mb.

---

<div class="post-metadata">

**Author:** ![dan](https://sea3.discourse-cdn.com/mcneel/user_avatar/discourse.mcneel.com/dan/32/481637_2.png) [@dan](https://discourse.mcneel.com/u/dan)\
**Post date:** [May 6, 2025, 9:19pm UTC](https://discourse.mcneel.com/t/parsing-content-of-a-3dm-file-identify-large-chunks/204089/11 "2025-05-06T21:19:12Z")

</div>

> [@martinsiegrist](#):
>
> It took 5 minutes to execute.

Ja ja that’s one of the reasons I haven’t announced it just yet 🙂 …but also I might not optimize much before I do actually.

---

<div class="post-metadata">

**Author:** ![dan](https://sea3.discourse-cdn.com/mcneel/user_avatar/discourse.mcneel.com/dan/32/481637_2.png) [@dan](https://discourse.mcneel.com/u/dan)\
**Post date:** [May 6, 2025, 9:26pm UTC](https://discourse.mcneel.com/t/parsing-content-of-a-3dm-file-identify-large-chunks/204089/12 "2025-05-06T21:26:26Z")

</div>

> [@sonderskovmathias](#):
>
> You’ve grouped it nicely but maybe it would be to see another distribution of the objects: Perhaps instead of measuring bytes per object, it could be split in geometry, userstrings, plugindata, and pool that across of objects. Especially its nice for developers to double check if something is added to objects by mistake.

Yep, we are definitely on the same page here! I have some ideas and approaches to try. I think first I’d like to see if column sorting alone can solve the problem…with both count and size.

If not that, some sort of options for _grouping by_. Here’s an early mock-up:

 ![unnamed](https://global.discourse-cdn.com/mcneel/uploads/default/original/4X/f/5/f/f5f91b1e1b7ce15966c070c19e77fc606c41114d.png)

> [@sonderskovmathias](#):
>
> Might be nice to have ‘cleanup’ buttons in the interface such as “delete all userstrings (save 943kB) / plugin data (save 2MB)”, materials etc (a bit like purge but allowing to delete stuff in use)

Indeed. I’ve been giving that some thought too. It’ll probably be phase 2. I’ve noted this down though.

Thanks again!

---

<div class="post-metadata">

**Author:** ![martinsiegrist](https://sea3.discourse-cdn.com/mcneel/user_avatar/discourse.mcneel.com/martinsiegrist/32/498369_2.png) [@martinsiegrist](https://discourse.mcneel.com/u/martinsiegrist)\
**Post date:** [May 7, 2025, 1:10am UTC](https://discourse.mcneel.com/t/parsing-content-of-a-3dm-file-identify-large-chunks/204089/13 "2025-05-07T01:10:49Z")

</div>

In file explorer you can sort files and group by various attributes

---

<div class="post-metadata">

**Author:** ![brian](https://sea3.discourse-cdn.com/mcneel/user_avatar/discourse.mcneel.com/brian/32/504171_2.png) [@brian](https://discourse.mcneel.com/u/brian)\
**Post date:** [March 24, 2026, 9:59pm UTC](https://discourse.mcneel.com/t/parsing-content-of-a-3dm-file-identify-large-chunks/204089/14 "2026-03-24T21:59:56Z")

</div>

[RH-88765](https://mcneel.myjetbrains.com/youtrack/issue/RH-88765) is fixed in Rhino [WIP](https://discourse.mcneel.com/t/welcome-to-serengeti/9612)