Volatile DisplayModes


I have an issue I keep running into: Displaymodes cannot be stored on a document level.

I’m printing on an A3 paper from layouts with details in a Technical Pipeline Mode.
This requires me to maximize the line thicknesses and for this job I do not want to display crease so they are unckecked.
I print a pdf and off it goes to the client.

A week later they need a revision, so I open the document revise what’s needed and print again.

However, nothing ensures the output is the same: I might have needed a change in the displaymode for another project or a co-worker has been on my machine or…

How do others feel about this and might it be good to have a system to store displaymodes inside a document much like linetypes and hatches are stored. It seems only logical that features with such elaborate options can be stored on a document rather than application level.



As you are well aware, display modes are stored with the application and not in the file.
I have to assume you are editing these files on different computers so they do not share the same display mode customizations.

My best work-around suggestion is to export the modified display mode and keep it handy so you can import it into the Rhino installation you are using at the time.

Personally, I would not want the displaymodes to be included in every document I produce (I know storage space is cheap) I just do not have a need for it. However, I think it would be useful to have a setting similar to Adobe InDesign’s “Package” which would include display settings, render settings, render materials, Rhino settings and all other document properties when a user is saving their file. This would allow a user to go from working on one computer to another one and not lose a beat. Thoughts?


1 Like

Hi John

Why is it you assume that?

There is a tab to provide direct access to the (basic) displaymode settings.

As for your suggestion to externally store and load displaymodes, why would that need to be an external file. It’s not like the user needs to carry annotation styles or texture images around.



Something like that. I’d call it an over override.
Only if explicity set, a detail (or any other viewport for that matter ) can be set to use document display modes.

The display modes available on viewports are composed of the set defined in the application or additional modes stored in the document…

Indeed the same would go for other applications settings that influence the document behaviour in a significant way.