I have a wish that I really want you to consider:
One problem with Rhino for drafting right now is that we have to make custom display modes to get descent output results, but these display modes are NOT stored in the file. So if I want to send my Rhino file, or store it for backup, then I have to export the display mode used as a unique name and store it together with the file and instruct any new users to install that display mode IF they want to view the files as intended (Which is cruzial if changes are going to be made and updated drawings are to be outputted).
New proposal:
Make Rhino’s default display modes hard coded so changes to them are stored in Rhino as alternatives.
And if these are used in the file then they are stored in the file too.
These variations are shown in the pull down menu for display modes alphabetically under each main display mode.
Challenges:
Finding a good way to organize them and to handle how they are stored in the file.
Why is it important?
Being able to open a file on your laptop and continue to work with the SAME looking display mode as you used when the file was built on an other machine is much more important than you think.
We have just started using display modes in Layout Details in real projects now, and this situation pops up all the time, and dealing with different versions of same named display modes are cumbersome and a problem when we quickly want to make changes to a layout if we are not on the correct machine.
And when we send the Rhino file to a client then we just can’t instruct them to install display modes etc. for it to be shown correctly.
So to sum it up:
I want the default display modes to look the same on ALL machines, and if you make changes to them then those changes are stored as a new sub-name/alteration to the original and saved IN the Rhino file (and in your Rhino app for use in other files too if you want that)
Hope this all makes sense and please ask if there is anything not clear.
Good idea to store such fundamental settings in the model file.
I think that Layers should be used more often for “extra” info in a model.
Why not make a “SettingsBlock” or “ConfigBlock” (to fake a geometry thingy) and stuff it with the Display Mode info, and place the block on a Layer in the model. Then it’s clear that the model has some “extras” which doesn’t have to be distributed or installed separately. And then it would be easy to see what has been added / modified or a model.
On startup when loading the model, Rhino can detect that a SettingsBlock exist on a layer, then examine it and - drumbeats - automagically install it on the client machine where it can be read as any other display mode.
(If the (file) same name already exist, a dialog can ask if it should be overwritten, renamed_01, or dismissed)
Other kinds or extras could be managed in a similar manner. GH Definitions for example…
Thinking about it, the above idea to Detect and Install extra stuff stored in CustomBlock on a Layer (with address to Mcneel; the Layer idea is not about a technical bright idea, "Its about the User, ") could also use a temporary plugin/settings directory for whatever settings i represents, meaning that - if a user picks that alternative in the dialog - an extra setting (like a custom Display Mode) will be installed only during the session in which a Rhino model is open, and when the model is closed the extra stuff is (optionally) removed again.
So, extra temp directories (flr different stuff) into which Rhino can “install” any custom stuff, and then delete it when closing down the model. Example:
Ditto for Grasshopper plugins, and whatever. Perhaps even Materials which you don’t want to spread around to the whole world so it follows only the individual model and is no longer available (directly on disk) when the model isn’t open.
And so on an so fourth. Temp-extensions in short. Of all kinds.
I think this is really, really neccessary. I am opening a file from cloud and it looks completely different than on my other PC (we know why). Display modes are not stored in the file.
@jeff knows best, I really have no idea what all the complexities are that might arise, either at the typing stage or for the user, but I can imagine some complications such as, (currently present in other areas like blocks and materials ) - naming collisions - that would need to be handled; I do not know how hard that would be, but it is a little messy in those cases.
I agree with Ivan’s here, and difficult is what drives you guys, isn’t it?
IMO it should have been solved and integrated when layouts were added to Rhino, as this is where it is most critical. Layouts turn to prints and are produce of Rhino, thus it is important that multiple users can open the same file and deliver the same result.
Why not make a “SettingsBlock” or “ConfigBlock” (to fake a geometry thingy) and stuff it with the Display Mode info, and place the block on a Layer in the model. Then it’s clear that the model has some “extras” which doesn’t have to be distributed or installed separately. And then it would be easy to see what has been added / modified or a model.
