Suggestion: should be able to embed custom display mode settings in any given file

Only this way we can develop evolving project specific display mode for better production workflow, instead of having personal settings or having to constantly sending settings file over the email every week.

It will really help out on working together as a team, especially one with team members come and go. Will also help on working with consultant and clients. Of course it should be a checkbox so you can choose to embed only one of the modes and not to share with outside people when transferring files.


It is a good suggestion and a common problem we run into while sharing files - it’s very hard to make sure the recipient of the file sees exactly what we see on our end, because the display modes can vary greatly, despite the same names.

Assuming that most users still use the default set of display modes, but customized (I am sure there is a lot of custom ones too), it would not be desired if the embedded modes override the existing modes permanently.
Ideally it would be possible to use the embedded modes to apply only for the specific file, and restore back to normal when file closes or Rhino exits. Perhaps a pop-up dialog on file open, which modes to use?

I am sure it is more complicated (what if the user wants to edit display mode while in the file - embedded one gets changed, or original, or…?) or other caveats (there are some settings outside of display modes that affect the display and may not be saved in the file), but it would be great to gather some ideas and discuss how that could be addressed.

Exporting display modes and asking other users to import them in order to view the files specific way doesn’t cut it. Especially if it would mess up their existing modes.


1 Like

Hi all - the only way, off hand, that I could see this working in a remotely non-confusing way would be to have some kind of clear switch between ‘current user’ modes and ‘file’. modes… it does seem a little can-o-wormsy but I get the request…


Hi Pascal,

It definitely is ‘can-o-wormsy’… If the goal of doing this is the consistency of the model look between different computers, then what also needs to be addressed is what to do with the display mode parameters that say “Use Application Settings”. My idea would be to change that to the mode-specific settings that follow the source application settings, so the embed mode doesn’t mess with users app settings but assures consistent look.

Also, if there are any texture images that display mode use, they would need to be embedded in the file as well. The whole “embed display modes” in file would need to be optional, of course.
It would need to scan all the views and per-object display modes to find the list of used display modes at the state the model is saved.

Also, if one choses to use “file” mode, there should be an option to convert to “Current User” modes, with an option to Ovewrite same-named modes, or create Auto-renamed copies…

If this idea would be seriously considered, I would be happy to help brainstorm and come up with possible scenarios and solutions, and that has been bugging me ever since starting using Rhino. But can-o-wormsy it is…


Hi Jarek - I would say, realistically, from where I sit at least, this is not likely to filter to the top of a developer’s heap any time soon - however, I may be way off base, so let’s ask @jeff

@Jarek, @Jun_Wang - add comments to my cursory bug track item as needed…


1 Like

This is a bigger can-o-worms than most of you probably realize… Jarek is on the right track, but it gets even more complicated than what he mentions. Display modes are “custom” entities… That means I could say the same thing for any of the customize-able UI settings, right? It’s just that “visually” the display modes contain quite a few “appearance” type settings, so I guess the expectations are higher with them.

This is doable, but it will require all kinds of things to get rethought, reworked, and redesigned… the material settings is probably one of the bigger issues, not to mention environments. There’s also the issue of potentially publishing proprietary images/content that users don’t want out and available for public consumption.

For right now, it’s a lot easier for us to just say “export your modes and accompanying files”…until we have time to really sit down and figure all of this out.

I think that it might seem easy for most users, and therefore wonder why we don’t “just” do this… but I assure you, it’s not easy, and there is a lot involved in this…especially if you really want the information embedded in the 3dm files, which involves other people whose time is far more valuable than mine.

There was a point early on in V6 design where display modes and their attributes were going to get completely redesigned…which obviously never happened (for similar reasons)… But, there will probably be a time where we will completely redo this area of Rhino, and it is at that point where we can start thinking about doing this typing of thing…trying to crowbar something into V6 right now is definitely not the time or place.

@pascal, please put something together in a YT and make it a 7.x wish item.


1 Like

Thanks for the quick response, totally understand the difficulty in developing something seemingly easy.

Thank you for all the hard work and looking forward to seeing Rhino getting better and better!


How about a new type of rhino file. For example .3dmx like .docx, .xlsx, etc. being in fact a zip with manifest file and some xml configuration file also containing folder with graphics, file to store current viewport and a folder for the actual 3dm in there.

A kind of a RhinoProject file. not just Rhino 3d model file.

Just an idea.

The problem is not storing the info in the file, but implementing what Rhino does with it without messing things up on the destination computer.
That needs more careful planning.

This is why there’s manifest and additional xml files in docx xlsx files to match user configuration as much as possible without messing up global application configurations.

Open docx pptx xlsx file with winzip or 7zip or whatever you will see what’s inside.

update: same goes for Dassault Systems’ 3dxml file

1 Like

Hi @jeff is there any news about this?
I just checked on YT and look like targeted to v8

I understand it is not an easy stuff but I’ll just explain my workflow if it may help.
I work on layouts where some detail views are set to a custom display mode. Everything is fine on my PC but when a colleague (which has not installed my custom display modes) save the file all detail view are reset to wireframe.
A design can have 20/30 sheets with different display modes set to the detail view. In order to fix it you will need to reassign all detail view display individually.