Discussion post! Having these three features separately has kept me frustrated for a very long time now 
Perhaps I am missing the point.
So, I totally understand why “Hide in Viewport” and “Disable in Render” are two separate features. Yet what I can’t get is why do we have Hide and Disable in Viewport as two separate options. Do you ever work with a scene where you need to keep some objects hidden in the scene, others disabled in the scene, while another unrelated set of objects is hidden from the render? Wouldn’t it be just smarter to put the forever disabled from viewport helpers into the collection and disable it once and for all, while working with hide\unhide for the important geometry?
Does anybody use all three features?
It seems you did not notice the S in “Disable in ViewportS”.
Hide is just for active Viewlayer.
Disable is relative to all Viewlayers, all Collections, all Scenes, all Files ; the object can be linked to.
But this geometry, you don’t want to see in Viewports. It still can be rendered, evaluated for animation.
When you exclude from viewlayer or scene a collection, it is not rendered or evaluated.
3 Likes
While I do make use of each of the buttons, it often does feel like a bit of cognitive load, and I’m never entirely sold that I’m making the smartest use of the toggles.
Is there a concrete example of where hide in viewport allows a particular effect that disable in viewport does not?
For example, the most frequent use case of me wanting an object hidden but still evaluated is when I’m making a collection to be referenced in geometry nodes. But I generally can still achieve this by simply toggling the entire collection off, so only it’s references are evaluated.
Another odd quirk is that toggling a collection off and on resets all the hide in viewport toggles, but none of the disable toggles. Is there a use case where this behaviour is a critical benefit?
I have often been frustrated that my hidden toggles get reset by collection toggles, but can’t think of any counter examples where I’ve been glad that’s how it worked. Again there probably could be a use case, it’s just not intuitive to me in a concrete way!
2 Likes
For what it’s worth, I do find the the combinations of display versus viewport versus what happens when it’s a collection or hierarchy… yeah, it can be a mental overhead.
Disable hides, but hide doesn’t disable…
Plus the fact that these things unhide (but don’t undisable?) themselves if you bring the item into a new scene makes it even cooler… /s
I’m not really sure there’s a great solution, but at times I feel like it offers more flexibility than could be needed, in exchange for a lot more management that I’m not sure always want to deal with.
I think that the most obvious one is when you are using several View Layers.
Imagine that you have same collection active in two different View Layers.
You can have one main window and switch active view layer.
Or you can have two main windows to display both View Layers at same time.
You want to hide only one object of the collection.
In that case, Hide will just hide the object in one window. Disable will hide it in both.
In case of linked objects between multiple scenes or multiple files, Hide may hide the object only in active scene, opened file. Disable is hiding it, in one click, for all viewports of those scenes and files, it is linked in, without excluding it of an F12 render in those scenes of files.
But when you are toggling a collection On/Off, that only applies to active View Layer. If you switch to another View Layer, collection may be in another status.
Collection is like Hide toggle relative to View Layer, that is sublevel of Scene, that is a sublevel of File. But Collection affects visibility in viewport, evaluation for animation and visibility in renders.
So, if you don’t do complex things, don’t use View Layers or don’t link assets in other files, Disable is probably a less frustrating choice than Hide.
But if things gets complicated and your work is implying different files, Hide will be less disturbing and Disable has to be used, only if you understand the consequences.
If you are working in large scenes then toggling disable in viewport can take a while. Hide is almost instantaneous.
1 Like
How the bleep do you then split out your scene for rendering and compositing??
I don’t care how many arguments people are throwing up in here, but this whole hide system in Blender is overly complex.
Having the same objects in multiple collections in multiple View layers can already be mind boggling complex when dealing with rendering issues.
And then throw in multiple Scenes.
Especially compared to, and swapping between multiple 3d applications, this makes Blender often infuriatingly annoying. 
1 Like
But do you really ever disable one object instead of the collection? I can not simply imagine the complex large scene where someone would randomly disable something from viewports keeping it in the same collection with other enabled objects. Especially in the large scenes. How will you ever find that object ever again? Could you share an example of how you organize such scenes with all three switches involved? It’s just for me disabling does not make any sense in the case of separate objects. It feels like a collection feature. But perhaps I just have never faced the case…
For example if you have a heavy object that slows down the viewport you might want to disable this object in the viewport but enable it in render while at the same time having a palceholder object in the same collection that is turned on in the viewport but disabled in render.
Or if you animate the visibility of different versions of an object you might want to animate their visibility to make them visible at different times.
Or if you are not sure yet which version to use and are making previews for the customer.
That are just a couple of reasons. I guess there are more.
So… Something like a proxy object?
It’s been requested ever since 2.8 came out.
1 Like
Yeah, I tried building one with Geonodes but it does not work. You do have the “is viewport” node which - combined with a switch - sounds like it could do the trick but unfortunately as soon as you put a collection into a geonodes tree it affects viewport performance.
It doesn’t even have to be connected to the output or in fact anything at all. It is enough to be present inside the nodetree in any kind of way.
I can, animation playback. In which case it’s not even an object but can very well just be a modifier on an object. A classic example is Geometry Nodes, which are a big processing overhead and a sure fire way to kill real-time viewport playback.
But, you still want to see the main object and have it playback and of course you still want the whole thing to render, you just don’t want it visible or being evaluated in the viewport.
So really, there are all sorts of ways to use Hide/Disable for Viewports and Renders.
That is why you cache the hell out of everything the moment you’ve set it up.
Never keep sims running when you’ve done the work. “Cache it™” and move on to the next thing.
1 Like
I did not mean “if you don’t do complex things : Don’t use View Layers !”
I meant “if you don’t use View Layers, using Disable in Viewports may be less confusing.”
There are people who don’t render stills or animation but can create Blender scenes, involving several objects, for 3D prints or blueprints of things they will build.
There are people who refuse to use View Layers to manage visibility in viewport.
First, user don’t randomly disable something.
He does it because it is meaningful to him.
Second, that is not because you are organizing your scene in collections ; that you will not give a name to objects and not be able to retrieve them in outliner.
disable_hide.blend (583.6 KB)
That is not a complex scene. It just involves view layers to show two different subjects : a Cube or a Torus under same conditions.
As you can see, Hide and Disable don’t play the same role.
You are not forced to create a collection for each object, to replace Hide toggle purpose.
Hide is used to exclude the other subject.
Disable is used to temporarily change conditions. I disabled the plane.
I could have disabled the light, instead.
It has nothing to do with sims. Just normal Nodes that change/add geometry get evaluated every frame on a deforming character mesh when you playback the animation in the viewport.
Caching would be useless, since the moment you change or add a keyframe the cache is now out of date. Hence, it’s far better to just disable the modifier (which isn’t really needed for animation or playback, only at render time) in order to hit realtime FPS playback.
That’s why I said cache it all after you set everything up…
But true, in certain cases that’s not always possible.
Peace! 