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.

2 Likes

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.

ā€“jarek

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ā€¦

-Pascal

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ā€¦

ā€“jarek

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ā€¦

https://mcneel.myjetbrains.com/youtrack/issue/RH-47650

@Jarek, @Jun_Wang - add comments to my cursory bug track item as neededā€¦

-Pascal

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.

Thanks,
-Jeff

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!

@pascal,

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.
Thanks!