Hi, I noticed that changing the Display Mode for objects only affects the current working viewport. Can we make it so that it does not depend on the viewport please? I need this object to remain wireframe no matter the viewport…
2 Likes
I have requested this long time ago. I think there may be mixed opinions about it, but for me it’s +1.
2 Likes
It is incredibly incoherent to have it be any other way.
It is a per object display mode, not a per object per viewport display mode.
The same way object display color works…It is globally applied to the object no matter the view. Imagine if the color of an object was actually dependent of the viewport and you could have the same objects displayed in 4 different colors across your different viewports. 
Rhino files be like: 
I agree, it just hasn’t evolved enough yet. I have a script for this and I made my own toolbar with some “standard” modes
This one will throw up a list of all the display modes you have set up and allow you to choose, then it applies it to all selected objects in all viewports.
SetObjDisplayModeAllViewports.py (1.8 KB)
This one is for hard-coding a specific display mode for use with aliases/buttons. You need to edit the script for each button and put in the local language name of the display mode you want to set with that alias/button.
2 Likes
Glad we agree! Thanks for kindly sharing your workarounds and scripts.
The counter-argument to this could be what if you need the opposite? What if you’d want an object in a shaded perspective view to be displayed as eg. ghosted but remain wireframe in all the wireframe parallel views? If you change the property to be always global, then you won’t be able to do this anymore.
With the way it is now, there’s at least the “Multiple Viewports…” option where you can set it for all available views in one place, although you have to set it for each individually, so it takes a few clicks. Maybe adding some “Set globally” checkbox into this window could be a decent compromise? Just figuring out some logical GUI for it would be needed.
Alternatively, I’m also thinking if it would make sense to have it “per object per display mode” instead of the current “per object per viewport”. So for example in any viewport set to shaded, an object would appear ghosted but if you switched one of the viewports to wireframe, it would apppear wireframe too (unless you overrode it again).
It really depends on your workflow and what you are trying to achieve with this property. The use case may vary.
First of all, not everything needs to be possible in a software. That is just not an argument.
Secondly, software needs to be consistent across itself. You cannot have a few settings change only in a single viewport while other settings change in all viewports, specially when both settings are object settings.
Thirdly, you need to consider the percentage of users expecting a function to work x way versus y percentage of users expecting it to work another way. And how many would find the alternative useful. 99% of users do not need to have an object have a different display mode in each viewport.
That would actually be more confusing and less intuitive for users.
Changing the display mode of an object to not depend on current display mode is similar to changing the color of an object to not depend on layer color. So far so good.
Now, imagine if moving the object from its current layer to another layer would change the color property you just set back to per layer? No, you want your object to remain the color you set it, even after moving it from layer. It is madness otherwise.
for me the the object display mode is usually for perspective only or 3d generally to get things aside in context and work on inner parts, but for a orthogonal view i feel this these modes dont add anything, for these very rare cases where i would need that in an ortho view i dont need it in perspective either… so having this global can also get in the way.
what might make sense is to have a command option like “global” which you can select, then you can macro these shortcuts yourself
if you are working on such files and need a global mode i think you are just plain childish now be honest 
But you can just set perspective to shaded and all other viewports to wireframe and that be the end of it…
It seems you might not have a strong grasp of English because what you said just doesn’t make any sense.
This is a file I made in grasshopper by copying multiple blocks and coloring them randomly to showcase the mess that would mean to have each object display a different color depending on viewport, which is analogous to having each object display mode be dependent on viewport as it currently is.
And you know that how? Have you done a survey? What if it’s the other way around and you’re in the minority? I mean based on this thread it’s either 50% or 60% depending on how you interpret Helvetosaur’s comment. But 5 people is obviously not enough data.
Sure, but the current implementation means that both use cases can be met (even if one means more clicks), meanwhile your proposal erases one option completely. You’re basically saying “I don’t need this feature, therefore (almost) no-one needs it, therefore I wish it was removed”. By that logic you could remove half of the functions in Rhino.
Again, that’s just your opinion. You’d need to survey users to figure out what they find more intuitive.
I don’t think that comparison is as good as you make it. Object color and display modes have somewhat different uses.
Now that is your only good argument. I agree that all the other properties in the same window are not viewport dependend. But if the viewport independency is deemed useful, then rather than removing the feature, figuring out how to change the GUI to a) clearly communicate to the user that the function is viewport dependend and b) make setting it as global easily possible is the better way forward in my opinion.
All I am saying is it should be global by default. If enough people need to change to per viewport display, then that can be an additional option that the user has to explicitly change.
That is strawman. That is not my argument.
My argument sounds more like this:
Object display mode dependent on viewport is a mistep and the option should be global by default affecting the object by itself across all viewports. Going from general to specific, it follows that by default all objects display the same way in all viewports (1). This is Rhino’s default for a reason. A step further in customization would mean changing a single object to another display mode across all viewports (2). And even a step further in customization would mean changing a single object to another display mode in one viewport and another display mode in another viewport (3). This is simple logic. We are skipping directly into step 3 with no real reason. Completely skipping (2), which logic dictates is more applicable to the general public as it is closer to the Rhino Default.
On the other hand, all other object settings are not dependent on viewport which makes this an exception, again with no good reason or justification. It is incoherent. As an user, you expect similar functions to work the same way, this creates predictability. Imagine my suprise when I changed an object display mode and I did not see the change reflected in other viewports. It is as crazy as modelling something in Persepctive and not having it sync to Front View.
And this takes me to the next point, which is efficiency.
Currently, if you want an object to have a custom display mode across all viewports, you need to change the settings across all of them, and closing and opening new viewports aswell.
On the other hand, if the option was global, you could just change it once, and if you need further customization on a given viewport, you can set it to viewport dependent on that single viewport.
It is very unlikely that you will need the same object with 4 different display modes (one for each viewport).
So not only does it make sense to go from global to particular in logical terms, coherence, etc. but also in terms of usability and user efficiency.
Common sense and 10 years working in Rhino and 3D, CAD and drafting software.
But I guess we could also add color dependency on viewport too. Makes me wonder why that was never added.
It also makes me wonder why the default Rhino option is to display all objects in the same display mode when you first open an empty file. I wish it was always different, like random 
i believe you misunderstood what i am using object display modes for. i am using these to set geometry that obstructs my view to wireframe leaving other parts shaded… for instance.
my english may not be perfect, but i can assure you that english is partially native to me, so my english can not be that bad.
i am not here to offend you, yet you do nothing else than opposing everybody trying to prove something to yourself. if enemies you are looking for enemies you will find, if friends you are looking for… friends you shall find.
I don’t see why you can’t do that with global per object settings.
Dude, you labeled me as childish without any valid reason. Just because I have a different opinion? All over a humorous screenshot of a fake working file… Don’t try to portray yourself as the victim or act morally superior now.
It’s called making a point. 
It’s unfortunate that consensus on everything is not possible, but that’s just the nature of things. There’s nothing inherently bad about it.
hmm… what now, victim or superior?
are you trying to be superior?
and for whom?
i was trying to be humorous. that is what i meant, you are looking for enemies too much.
because in other views i personally dont need a change. i like to have several options of getting to geometry. maybe you have a different work flow, thats why i suggested to have an option in the command, but you are battling with red eyes so hard ignoring all the the hands reaching towards you. sad
What I propose is for global to be default and if needed add the option to make it per viewport also.
This way if you want to change a single object in a single view you can, and I don’t have to be forced to change the setting on an object 4 times for the 4 views.
I still don’t think that with all objects shaded, having an object wireframe in 4 views vs having it only in 1 view is a really big deal. It won’t break your workflow. You can always change the object back to what you need depending on the view you are going to work on. It is not like you can draw in multiple views simultaneously anyways. And for this specific case, you can always ExtractWireframe. Or you can explode the object in faces and have each face have a different display mode.
Let’s keep it objective. No need for a heated argument.
I vote for global. I draw in only one viewport anyway and change with “strg+shift” and a floating cplane.
I only need it to be different in layouts/details.
The best way to make everyone happy is to make an alternative RMB command that will set the object display mode to all viewports, while the existing LBM command will remain the same.
I have another proposal 
Add a new option in the viewport modes to respect or ignore the object display mode. That way, when I set my Shaded or any custom display mode to ignore the object display mode and switch to it, Rhino will show every object with shaded display settings, even though some object may have been assigned to a different object display modes. Once I switch to another display mode that respects the object display modes, those objects will be displayed with the corresponding display modes they were assigned to.
1 Like
That’s actually a great idea, I could use it very often. As for the “Global” per display mode setting, we can make-do with scripted solutions I think as the per-viewport settting we have now is much more helpful/flexible.
1 Like
Proposal #3: Add a button to turn the object display mode on and off for all objects that were assigned to it. One press of the button will turn off the custom object display modes, next press of the button will turn them on again. No need to select objects, just press a single button and all the magic happens in a split second.
1 Like
