There’s a delete button in the Rhino options > View > display modes list already… but I don’t follow…
Now I’m confused. Why would this be? Is there overlapping of names when you save a file with materials (as an analogy)?
There would be no ‘automatic addition’, because this extra list of local-to-document display modes is simply loaded/saved with the file, independent of the other display modes which are saved as Rhino options.
Maybe we should sleep over this…
Is the request for an imported file to appear the same when opened as it did when saved?
OR
Is the request for the user of an imported file to have access to all the display modes of the user who save the file?
My assumption is the first: an imported file appears the same when opened as it did when saved.
Currently viewport layout and camera positions, and display mode names are saved when the file was saved. Other display mode information is not saved.
Currently when a saved file is opened the viewport layout and camera positions are same as when saved. Each viewport uses the display mode on the opening system with the saved display mode, unless the display mode does not exist. Then it uses a default display mode.
My proposal is when a file is saved the relevant display mode information for each viewport is saved in the file. When the file is opened the user has the option to use the display mode information in the file, or to use their display modes with the same names. There would also be an option to display mode information in the file as new or updated display modes.
Over the years this request has come in both forms. At a minimum everyone wants files to appear the same when opened on a different computer or even when opened a year later on the same computer.
Yes, absolutely. That’s what this is all about.
Not all of them, but to those the user chose to be part of the document, not the ones stored under his Rhino options.
That means, if the user wants other users to see exactly what he sees in a viewport (or detail, mostly - that’s what I would usually like), he has to create/move/copy a display mode in this hypothetical new display mode group/pool/repository in the document settings, and use/choose this mode in his detail/viewports, where needed.
To avoid this either/or situation is the reason for my proposal. Document display modes would always be loaded, but Rhino option d.m.s would always be left unchanged. Best of both, so to say.
Edit
A better wording might be: there would be a public (per document) and a private (per Rhino) set of display modes.
I think this is definitely way to go with this. Just a new panel for document display modes with the basic functions (edit, rename, duplication, delete, import from 3dm file etc). Users could save current active display mode to the document (and vice versa). No need to worry about naming conflict and so on. You could have document “Shaded” and the global “Shaded” for example. Users could even save template files with custom document display modes in them.
Yes, my point exactly.
It always has been problematic with Rhino that the same file looks completely different depending on which system it is open on, because of how the Display Modes are configured. Being able to make it work and look consistent between computers in a way that is flexible, intuitive and not overly complicated would be fantastic. I also wish it was implemented, but so far I share a lot of concerns that Steve and Gijs pointed out, plus a few more. At the same time, maybe this brainstorming can lead to some good result, so please see below.
One thing for sure: if this is implemented badly, it can lead to a huge mess and better not touch it unless we have a bulletproof solution!
IMHO Eugen’s suggestion is the closest to what may work and keep things relatively clean (Document Display Modes vs Global/System Display Modes). But here are some things to consider:
Display Modes in files are used in many ways: Viewports, Per-object per Viewport, in Layouts and also saved as SnapShots. To make it really meaningful and consistent, all of these occurrences should be taken into account in the Display Mode transfers.
Embedding the display modes in Document should be optional
There should be an option when opening a Document with embedded Display Modes to use System display modes with corresponding names, or even let the user decide which ones to use from System, which ones from Document if name conflict occurs
Which DisplayModes to include in the saved file? Imagine a Document with a bunch of modes in Viewports, Per-Object, Layout and Snapshots so when saving, all of the used ones can be included if user choses to. But what if no viewport is set to Rendered mode but I want someone who opens my file to see the Rendered mode of my file to look like it does on my system? I should be able to manually pick any additional “not used” modes to be included. So I imagine a dialog that lists all of the used display modes vs all other modes where user can chose which extra to include or which used modes to delete from the list.
How do we handle Open vs Import? I would think Open has all the above behavior vs import has only per-object display modes included (if we chose to import them)
Naming pollution can still be a problem: Imagine 3 users pass along the same Document, each of them has their own Rendered mode that gets assigned to a new or one of the Viewports or, more likely, per-object. Now the Document Display mode list would have 3 “different” Rendered display modes sharing exactly the same name (even if they have different GUID, in UI all look the same). How to handle this? I guess it would be up to the user(s) to keep things reasonable, assuming they are aware of how these things work.
Considering the above, we would need a tool like “Display Mode Mapper” where one or more Display Mode occurrences in the document can be switched using another DM from a list.
So as you can see it gets quite complicated and not considering all of the scenarios when implementing this could result in a big mess. But maybe it is worth giving it a shot, keeping most of the things “optional”!
my 2c.
–jarek
Sharp thinking, Jarek!
ad 1)
Definitely. On every occurrence in the UI where you can choose display modes, you would see both ‘repositories’ (system and document) to pick from.
If it’s a dropdown menu, there could be simply 2 sections.
ad 2)
Yes. The document repository could be empty, too. Like when you open an older file.
ad 3)
That would make it more complicated, no? If anyone wants to ‘map’ any display mode to another one, it should be done in the (new and theoretical) display mode manager panel.
I would suggest to keep document and system display modes strictly different, and in the user’s responsibility if he wants to share a display mode or not. The less automatisms, the better. No auto-mapping between document and system, ever. Plain and simple.
ad 4)
Exactly those in the document repository, nothing more.
See 1: whenever the user chooses a display mode, (s)he will be presented with those 2 lists. Only if a d.mode from the document list is chosen, it will be shared.
Then you should have chosen the d.mode from document’s d.mode repository before saving. Do this, send the file again, done.
The other user will never see any display modes from the ‘system’ repository of another one.
Yes…
The usual actually, but with 2 sections.
ad 5)
‘Open’ loads the document’s d.modes into the document d.mode repository (like materials, named views, snapshots, …)
‘Import’ loads the d.modes only of objects that have a document d.mode attached to it.
ad 6)
No, it can’t.
Is this used Rendered mode part of the ‘document repo’, or the ‘system repo’? It will only be loaded in the first case.
In Rhino, only one person can change a document at a time. Therefore, it can never happen that in one and the same document multiple d.modes of the same name occur in it’s document repo.
Only d.modes that are in the ‘system repository’ on different user’s Rhino installation can have the same name, accidentially. Since these are never loaded with a file, there can’t be any clashes.
ad 7) Might not be necessary for the above reason.
One question remains: are duplicated d.mode names allowed between the document and system? In the existing system repository, they are not., but I think between system and document, this should be allowed, since it would otherwise force everybody who is opening the file to rename/remap between the two repos.
Since document d.modes would be tagged in some way, there would be a difference internally, even if the name is the same.
(Maybe this is what Jarek meant in 6)
Thanks!
I would echo Eugen’s point that this seems to add an extra layer of perceived complexity.
When I open a document with embedded custom display modes, I don’t want to have dialogues pop-up that require me thinking of which option to pick. It would be particularly annoying if I’m opening a document that is frequently shared with a colleague and this pop-up kept appearing when I’m already thinking of the next steps of the project I’m working on as the new instance of Rhino is starting up.
have a small indicator button showing that a view uses a mode of the same name as a system one, and is out of sync with it
and you can click the button to sync it
that button would run a command on the view, which could also be done to all views by a toolbar button
this would work the same when opening a file, so no need arises for warning dialogs/etc
or, colouring the title different for super minimalists
I guess you are right, it may be too much, but there would need to be a good system to enforce System Display Modes if I don’t want to use the ones that came with the document, otherwise it will be a nightmare to manage.
Sounds fair, the responsibility would be on the one who saves/shares the file to include all the “looks” in the file (either via assigning them to different viewports, per-object or in SnapShot state)
So my question is, does the Document Level display mode list get created automatically, or I need to make it ‘by hand’ and assign these modes all over to make it shareable? The 2nd option would be a lot of extra work! If it is automatic, then how about this scenario:
I get a document from a colleague with a display mode named “Rendered” assigned to an object (it was their System Level mode, but became Document Level Mode on Save as well). OK, that mode is assigned to the Document Level Display Modes list automatically on Save, right?. On my system,I pick another object in the file, and assign my System Rendered Mode to it and save the file. Now, on Document Level for a consistent look it needs my Rendered Mode and another Rendered mode that came with the doument before, these could look very different despite the same name. How is that being handled? What stops 3rd user from adding their 3rd “Rendered” mode to the document level list?
-j
My suggestion would definitely be: make it ‘by hand’. Otherwise, you buy complications. It should be a deliberate decision which d.mode to share. Public = document, private = system display modes.
Creating a document display mode could be rather simple. Just open the options (or some new display mode panel), d&d a system d.mode into the document d.mode area, done.
If even that is too bothersome, there could be a RMB context menu entry in the display mode list “copy to document”.
Again, I would not add any automatisms, no matter how smart. Let’s wait what the McNeel pros say to all this.
I see, OK in that case there would be more responsibility to the creators but less room for automated bloating and confusion. Maybe that could work. But again, in that case I would want a tool to automatically “copy” or embed my System Modes into Document Modes, or later on reassign Document Modes to given System Modes (I have System Modes I am attached to emotionally and would not want to use other ones unless I absolutely have to, so getting someone else’s file with their Document Modes would almost always result in me converting these to System Modes here).
-j
Not adding much to the topic with this but… you’re not alone hahah
It is not complicated. SketchUp manages this just fine.
You have a local collection of styles on your pc.
And then also the model has an embedded collection.
Every time you use a display from your own collection, or from the presets, it gets added to the Model Displays.
You can also independently manage the Model collection by deleting or adding new styles, customizing what you want to share.
If display modes are to be saved in the Rhino file, please include the option to override the appearance of the major and minor grid lines within the display mode by using “mode-specific settings” instead of the global application settings. Opening a file with a dark display mode makes the grid look way too bright with my default settings, as seen in the image.
I like the basic idea of opening a document with the same appearance as it was saved by somebody else.
But I am not sure, if the majority of users need a more complicated setting for this. I think it most important to have some very great, powerful default / build in display modes.
Modifying and Creating display modes is something for the more advanced users. And as Display modes can already be imported / exported as readable text / .ini files. What about a
Display-Mode-Embed-Plug-in
it should be very simple to integrate them as documentUserText or custom user Data into the .3dm file.
So my suggestion: it would be great to have a plug-in that does the job of writing the used display modes (settings) into the 3dm file (with a name and a guid) and load them back.
If the plug-in gets a huge response it might become part of the standard rhino installation.
…but in this context it would be great to have some additional functionality regarding plug-in userData (or does it already exists ?). if a plug-in wrote data to a 3dm file it would be great if rhino could inform the user “this file has data from <…> plug-in” maybe even point to food4rhino / package manager or some other web-Adress.
when sketchup has it rhino MUST have it. overthinking too much. there are plenty of good examples around other softwares. nothing to invent just implement in good way.
Is there any plan to implement a file based view mode from McNeel´s side?
I am also running into this problem on a regular basis (Client opens the Rhino file and it does not look like mine, I open an old file and the display modes are gone / modified)
Please !
