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.
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ā¦
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ā¦
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.
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.
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
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!