Bug: "export selected" file bloat and mess

@pascal and @wim can you please help addressing this?

I can only describe this as a bug since it really messes with our files.
(I understand that it behaves as it is programmed to do, but still, for us users it is behaving wrong, like something is buggy)

Check out the file consisting a single point exported from my project


  • The point it is created on the Default layer
  • The Default layer has all the default settings except color is changed to orange. That’s all.
  • The point is exported with default export selected settings

Now when you open the file you will se:

  • ALL materials from the project are included
  • Named views are included
  • Annotation style is included
  • It starts grasshopper since the file thinks it is a VisualArq project

Why is this a problem?

  • It is the biggest problem when the file is imported into another file because
  • It bloats files
  • It ads tons of materials to the file that is not needed and not wanted making organizing the other file a mess
  • It adds annotation styles to projects that we don’t want
  • It adds named views to projects that we don’t want
  • It wastes a lot of time

This also affects Copy-Paste which has been addressed many times before.

To clean up something as simple as copying a point from one file to another we have to:

  • export selected
  • open the exported file
  • Run purge (And make sure that the settings there are correct)
  • open material editor to check that all materials are gone
  • delete named views one by one
  • add a new annotation style and delete the other one.
    • This is a bug on it’s own since Rhino will not let us NOT have an annotation style in the file, so I have to add one that I think I will use in the other file.
  • use saveas and toggle save small and toggle off Save Plugin Data (this can be done on export too, but should not be nessessary since the point has no plugin data assigned to it.
  • import the file into the project.

So it’s a lot of hassle to copy something as simple as a point from one project to another.


  • Rhino should be smart enough to ONLY export relevant data to the objects being exported.
  • A point or a curve should have NO materials with them.
  • Annotation styles should ONLY be included IF annotations are exported AND if they use them.
  • Named Views should ONLY be included IF the user wishes, so it needs a toggle
  • Plugindata should ONLY be included IF objects use them AND if the users has this toggled on.

This applies to both export and copy-paste, it has been addressed may times and need to be fixed.
So PLEASE spend time on getting it high on the list for things to fix. I can not understand that this is a difficult task, a big one maybe, but the current copy-all-stuff-with-everything-because-it’s-easy-for-the-programmers attitude isn’t OK for the users. It really steals a lot of time and messes up stuff and causes file to bloat and organized files to become unorganized.

The annotation style will also cause a “missing font” warning if imported to Rhino 7.


point.3dm (202.2 KB)


  • Open file and have a look.
  • Clean it up for your self to see how long it takes to just import a single point…
  • Import the original into another project you have and see how it ads all kinds of junk to that, now have fun cleaning it up again. Problem here is that maybe you have hatches and materials not in use that you want to keep, so PURGE can NOT be used… so have fun doing that by hand…

Here is a cleaned up file NOTE that HATCH PATTERN’S are not purged…

point clean.3dm (36.8 KB)

It went from 202 KB to 37 KB…


Hi Jorgen - thanks for the detailed report - it is partly addressed here:

RH-57625 Exported 3dm file is bloated by unused textures

But I’ll add items as needed for your other points.

RH-58797 Limit export to relevant data

@Holo, The current annotation style is exported, that seems reasonable, to me…?


1 Like

Why? It is not used?
IMO all settings in a file should be default unless used by the objects in the export.
edit: (That means including default linetypes, hatches etc though)

I forgot to mention Environments, they come a cross as well. All of them, not only the active ones.
(plural since more than one can used at the same time for different tasks, I mention it just in case the programmer who handles this isn’t into rendering and Rhino is a vast landscape to know it all about… Even for oldtimers :slight_smile: )

To debate this I can see that in some situations you want to make a copy of your file with just a few elements in them. MAYBE export should cover this through a toggle that says: “Clean Export with only relevent object related data” and have that toggled on by default.
Copy-Paste should definitely only use that IMO.

Thanks for pushing this up the pile Pascal.

Because, some annotation style needs to be exported… what else would it be but the current one?


The STANDARD one unless another one is used by objects exported.
Otherwise Rhino will import this unused definition into the other file.

Rhino does not show in the annotations list if they are used or not, so in theory you can copy stuff from differrent files (common) and end up with many unused annotation styles that you don’t know which to use. Real life example from importing many dwg’s:
I have no idea which I use in the file from looking at the list.
I have to select all annotations and go through them and make a manual list if I want to clean that up…

I can delete all of these but one (the one I choose as default) and Rhino asks me IF I AM SURE, but does not tell me that any objects uses it, and those annotations just change to the current one. Rhino just do that with out further notifications.

Makes sense?

Hi Jorgen - I don’t know if the mechanics make sense, the way things are hooked up. I am somewhat making things up here, we should ask @lowell as well, what is possible or sensible, but if the file must be written with a style current, as I expect, it just seems like a bit of a stretch, to me, to activate one of the built in styles that is not even in the current documant’s list of annotation styles and make it current…


1 Like

Well, you guys are already stretching backwards for us in every thinkable situation, so this being too difficult surprises me :wink:

But I guess it is the least important participant of the list, so I will not moan if it gets cut!

The same applies to API I wrote about it here but staff wasn’t interested I guess…

I haven’t tried making files without dimstyles, so I don’t know for sure what might show up. I think it would be ok, though, as far as Rhino is concerned. If there are annotations in the file, there should be a dimstyle. Otherwise the ON Default would be used.

Would this be a good result for Exporting the point in the point.3dm file you posted above?

ExportPoint.3dm (11.9 KB)