thanks for the request, I think this would also help with support.
But let’s first discuss what needs to happen,
A couple of possible scenarios I could think of:
The user makes modifications to a built in profile (do these changes need to be written in the file?
The user makes a custom profile
The user has a custom profile and modifies this in the file
It can become tricky to handle all that, because:
Say a user works in file A, and makes modifications to any of the display modes. Now opens file B and makes more modifications to any of the display modes. So far the behavior is the same as current Rhino. Now the user opens up file A again, that uses the same display modes as in file B. Should file A still be opened as it was, or should the changes from file B stay?
How about this:
There could be 2 ‘repositories’ for display modes. One in the document properties, the other in Rhino options, as usual. 1) is saved with the file, and 2) with Rhino, of course.
The local repo is always loaded from the file, the global one sticks.
The user can choose where to put display modes (local or global), and is thus responsible for putting it in the right place. Local, if it needs to be passed along with the file.
That way there needn’t be some smart mechanism to figure out what should happen, right?
The viewport menu could show 2 sections for these 2 repositories:
I’m afraid this is getting complex quickly, and I want to avoid making Rhino more complex than it already is. Maybe a first good step would be to save the display modes in the file (silently) and make them retrievable with a command.
It gets complicated very fast. Lets say I have 40 custom display modes and save a 3dm file with all 40 custom modes. I hand this file to a friend with 10 custom display modes. My friend make a change and hands the 3dm file back to me. I now would open a file with 50 custom display modes. Even worse there are duplicate names since me and my friend use the same names for display modes.
I’m all for saving display modes in 3dm files. We just need to carefully design the system so it doesn’t turn in a ever growing list.
just to toy with an idea: the problem is that display modes are a global state at all, rather than being just a set of parameters that may be applied to a view
when I spin my camera, I don’t worry about how the file is going to open on my friend’s machine, with their “camera direction mode” applied because no one would ever code such a thing
and when that file has named views, we don’t find ourselves discussing in which repository the named views should be placed upon opening my file, because the evolution of rhino did not make it seem sensible to put a list of named views in the global rhino options
we just have them, import them, apply them, we can have as many as we like in a file without affecting anything globally, and we can save as many template 3dms as we like, all with totally different sets of named views in them
so I think I’m saying not much needs to change; just the subtle detail of making it so that display modes are applied rather than being a global state existing outside of any document, which is forced on every document you happen to open
if you want to let them be saved in files like named views, that would also seem to be pretty great to me
the current design made sense when it was only about modeling – I don’t want to know how you set up your viewport, I like to model how I like to model
but as viewport rendering has come more into the picture, more people expect to open a file and see exactly what the writer of the file saw
I’ll try to convey my suggestion a bit better, for the sake of it. I believe it’s not really complicated.
Every file has it’s own pool of display modes (which can be empty also), in addition to the ones in the Rhino options. When a file is loaded, the ‘per document’ display modes are replaced with the one from the file (comparable to materials). No accumulation of display modes is happening here, like Steve mentions, because per-document and per-Rhino d.m.s do not mingle automatically (except when needed).
D.m.s could be freely moved/duplicated between those two pools.
The user can choose the needed d.m. out of both pools. If a good and nice d.m. should be passed on (to have layouts/details appear the same etc.), it needs to be chosen from the ‘per-document-pool’, and will of course appear in whatever Rhino this document is opened.
Nothing changes for the display modes in the Rhino options. Work like always. What needs to be added is this ‘per-document’ list.
The advantage over the “from file” idea is: you never have to worry about duplicates. When you choose to load them “from file”, you might, because there could be a clash with the existing Rhino options display modes.
One more thought: display modes could use GUIDs, not just names. No more clashes…
like this it is brilliant and absolutely trivial.creating new list of display modes reorganizing settings and saving ini files within file. problem solved.
If you work with template files then it is one time process and you can be sure that when you share your file your model looks the same with the same display mode embedded in the file. Thats the point that file looks the same on every pc.
All the display modes (if any) that are kept in the “local” = “per-document” repository (or however you want to call it) are always saved/loaded with the document.
Load another document, and those per-document are replaced. No overlapping/mixing. Just think of the way materials are handled.
The display modes in the Rhino options are not touched by this. They can be exported/imported if needed, like always.
Of course, “Rhino option display modes” and “per document display modes” could be happily swapped/moved/copied to and fro. How this is handled in the Options panel needs some consideration, but nothing too complicated. There could be two different places, one in Document properties > Display modes (new), another in the Rhino options > View > Display modes (existing).
Maybe there are simply some copy/paste buttons, or maybe there’s a common panel for all display modes, with some color code for “per-document” and “per-Rhino”.
Each document would have it’s own list of per-document display modes. How could this lead to pollution? Anybody who opens the file gets the same display modes, that’s the idea.
Like: when I open a file with some materials in it, there’s just these materials, right? When I give it to someone else, this person also gets the same materials.
The ‘regular’ Rhino options display modes would not concerned by this. Other ‘context’, so to say.
I must be confused. If I have a display mode that is marked as “save in document” and you hand me a file that I make a change in and hand back to you, wouldn’t my display mode also get saved?
Well, yes. All the ‘local to document’ display modes always get saved. If one user chooses to change those, it will change the look of whatever viewports they were used in, of course.
I can’t think of no better ananlogy than with materials. If you give me a file with some materials in it, and I change them, save, and pass it on to you, you will have these changed materials. But that’s not ‘pollution’ - because it does not happen by accident. You won’t carelessly mess with materials in a scene you got when you know they are used to make a rendering look correct.
The usual per-Rhino display modes would be in another “context”. They stick with your Rhino session, and don’t cumulate by loading any per-document display modes.
Maybe that’s the misunderstanding: these theoretical “per-document” display modes are not part of the list in the Rhino options, but in a new list in Document properties.
This means there would need to be a way to manually remove display modes from a file. With automatic saving, there will be pollution and overlapping of names.
If there is UI for manually removing, then having UI for manually adding may make sense over automatic addition.
