@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
info:
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.
Workaround
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.
Wish:
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.
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…
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 )
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.
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.
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…
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.