Collections, objects visibility and local view #57857

New Issue

In Blender, we have various levels of visibility. We already have a toggle for viewport visibility per view layer {F5575043, size=full}

We then have a layer on top, which is the Hidden toggle:

{F5575075, size=full}

This is already quite confusing. Even though there is a difference between them that users can learn, in practice it's simply not clear enough which one to use when.

Next, the question is, how to handle the / key Local View feature, as well as per viewport visibility? How can we add these features without adding even more layers of visibility and complexity?

Proposal

In the outliner we only keep the screen and render visibility option (hide_render, hide_viewport).
We move the collections and objects visibility to be per-viewport.
In the viewport collection popover we control only the per-viewport collection visibility (we can still indicate if there is any object in this collection that is invisible).
With / we control localview, like in 2.79a.

For now we don't change the way per-object visibility is handled. So outliner still shows them, and users can use H, Alt + H to control them.

Viewport visibility UI

Currently, we have two popovers to control viewport visibility:
{F5585664, size=full}

We can optimize this UI by combining them into one popover, as we do in other editors. Our 3D View header is getting very crowded, and there's no need for two separate ones, and we already have the Outliner visible by default to organize scenes.

Inside, we should mirror the same order and layout as the Outliner. Otherwise, users will have no way of relating to the hierarchy of Collections.

The section in the bottom allows users to disable visibility or selectability per object type:

The hierarchy here is communicated just like hierarchy in the Properties Editor, using background darkness as opposed to indentation. This allows us to see many levels deep without requiring a wide panel to fit all the indentations.

The numbers refer to the shortcut keys one can hit from 1-9 to solo top level Collections.

The filled vs empty Collections show you which Collections are empty.

The yellow highlighted Collections are the ones with the selected items inside it.

In Blender, we have various levels of visibility. We already have a toggle for viewport visibility per view layer {[F5575043](https://archive.blender.org/developer/F5575043/Screen_Shot_2018-11-15_at_23.12.01.png), size=full} We then have a layer on top, which is the Hidden toggle: {[F5575075](https://archive.blender.org/developer/F5575075/Screen_Shot_2018-11-15_at_23.12.03.png), size=full} This is already quite confusing. Even though there is a difference between them that users can learn, in practice it's simply not clear enough which one to use when. Next, the question is, how to handle the `/ key` Local View feature, as well as per viewport visibility? How can we add these features without adding even more layers of visibility and complexity? # Proposal - In the outliner we only keep the screen and render visibility option (hide_render, hide_viewport). - We move the collections and objects visibility to be per-viewport. - In the viewport collection popover we control only the per-viewport collection visibility (we can still indicate if there is any object in this collection that is invisible). - With `/` we control localview, like in 2.79a. For now we don't change the way per-object visibility is handled. So outliner still shows them, and users can use `H`, `Alt + H` to control them. # Viewport visibility UI Currently, we have two popovers to control viewport visibility: {[F5585664](https://archive.blender.org/developer/F5585664/Screen_Shot_2018-11-16_at_15.23.35.png), size=full} We can optimize this UI by combining them into one popover, as we do in other editors. Our 3D View header is getting very crowded, and there's no need for two separate ones, and we already have the Outliner visible by default to organize scenes. Inside, we should mirror the same order and layout as the Outliner. Otherwise, users will have no way of relating to the hierarchy of Collections. The section in the bottom allows users to disable visibility or selectability per object type: ![Screenshot 2018-11-21 at 15.17.26.png](https://archive.blender.org/developer/F5666401/Screenshot_2018-11-21_at_15.17.26.png) The hierarchy here is communicated just like hierarchy in the Properties Editor, using background darkness as opposed to indentation. This allows us to see many levels deep without requiring a wide panel to fit all the indentations. The numbers refer to the shortcut keys one can hit from 1-9 to solo top level Collections. The filled vs empty Collections show you which Collections are empty. The yellow highlighted Collections are the ones with the selected items inside it.

Added subscribers: @dfelinto, @WilliamReynish, @pablovazquez, @brecht

This all sounds good to me.

@dfelinto and I discussed various option on IRC on how best to add local view (/ key) and per-viewport visibility in a way that doesn't add even more complexity, and this seemed like probably the simplest way.

Part of this idea is that / key local view actually sets the same visibility flag as H / alt-H.

@dfelinto and I discussed various option on IRC on how best to add local view (/ key) and per-viewport visibility in a way that doesn't add even more complexity, and this seemed like probably the simplest way. Part of this idea is that `/ key` local view actually sets the same visibility flag as `H` / `alt-H`.

Added subscriber: @augustina12345

Added subscriber: @machieb

The local view (isolate selected) feature is very important!
Please make the visibility/local view setting as it is useful! When you have lots of geometry in the scene you often need to just focus on one object.
Make it at least like in Blender 2.79 where hitting the / key sets the object to local view, when you hit the / key you get out of local view. Objects that were hidden in the viewport remain hidden.
In the moment in blender 2.80 you have to unhide everything (alt h) to get out of local view, which ruins the scene configuration.

In my opinion local view should be independent from all the viewport/viewlayer visibilities! Its only a way to isolate one object to concentrate on.

In very large scenes with 10000+objects we often have the case that we have to hide many objects. Is there a way to find these hidden objects again, without unhiding everything? In the outliner there is sadly no filter for hidden objects, only visible objects.

The local view (isolate selected) feature is very important! Please make the visibility/local view setting as it is useful! When you have lots of geometry in the scene you often need to just focus on one object. Make it at least like in Blender 2.79 where hitting the / key sets the object to local view, when you hit the / key you get out of local view. Objects that were hidden in the viewport remain hidden. In the moment in blender 2.80 you have to unhide everything (alt h) to get out of local view, which ruins the scene configuration. In my opinion local view should be independent from all the viewport/viewlayer visibilities! Its only a way to isolate one object to concentrate on. In very large scenes with 10000+objects we often have the case that we have to hide many objects. Is there a way to find these hidden objects again, without unhiding everything? In the outliner there is sadly no filter for hidden objects, only visible objects.

@machieb, when you disable objects or collections for the viewport in the outliner (the screen icon), they are not unhidden on Alt+H. Not saying this is exactly what you are asking for, but there is a mechanism to hide objects more permanently.

@brecht, thanks for your advice. Will the screen icon in the outliner be available if the proposal in this thread is realized? Would it be hard to implement a search option for hidden/invisible objects in the outliner. In the moment there are only search options for visible, all, active and selected objects?

@machieb yes, the screen icon will be available. Indeed it is the first point of this proposal: "1. In the outliner we only keep the screen and render visibility option (...)"

@machieb yes, the screen icon will be available. Indeed it is the first point of this proposal: "1. In the outliner we only keep the **screen** and render visibility option (...)"

@dfelinto, thanks for you answer, I trust your proposal to be useful in every days work. Thanks for you your hard work! Can you implement the search option for hidden/invisible objects in the outliner, or is it a paper cut? In the moment there are only search options for visible, all, active and selected objects.

One thing that I'm not sure is the / key behaviour. My suggestion would be to not work as a toggle, instead to simply work as a contrived Ctrl+I followed by H. Otherwise what will be the difference between Alt+H and the second time you press the / key?

One thing that I'm not sure is the `/ key` behaviour. My suggestion would be to not work as a toggle, instead to simply work as a contrived `Ctrl+I` followed by `H`. Otherwise what will be the difference between `Alt+H` and the second time you press the `/ key`?

If the / key would work as a toogle wouldn´t it be more effective in case of performance? I don´t know how blender is handling this. Doing an inverse selection operation followed by a hide operation sounds compute intensive, if you have lots of objects in the scene. I work in the automobile industrie where I have 10000+ geometries in blender. In my opinion local view should be with good performance.

If the **/ key** would work as a toogle wouldn´t it be more effective in case of performance? I don´t know how blender is handling this. Doing an inverse selection operation followed by a hide operation sounds compute intensive, if you have lots of objects in the scene. I work in the automobile industrie where I have 10000+ geometries in blender. In my opinion local view should be with good performance.

@dfelinto, I guess the difference would be in resetting the view matrix, which is part of local view. We could also make it so / only changes visibility for the current viewport, and H/Shift+H/Alt+H do it for all viewports.

@dfelinto, I guess the difference would be in resetting the view matrix, which is part of local view. We could also make it so `/` only changes visibility for the current viewport, and H/Shift+H/Alt+H do it for all viewports.

Sounds good, maybe you can then add a button somewhere in the viewport for new users (like the aktive camera icon in the top right)?!
@dfelinto: As I understand the prosal, the visibility of objects in viewlayers would then be controlled by the set exclude/dynamic override of collections?

Sounds good, maybe you can then add a button somewhere in the viewport for new users (like the aktive camera icon in the top right)?! @dfelinto: As I understand the prosal, the visibility of objects in viewlayers would then be controlled by the set exclude/dynamic override of collections?

After reading the proposal carfully I now have some questions.

"1. In the outliner we only keep the screen and render visibility option (hide_render, hide_viewport)."
Will there be a shortcut for disabling objects (screen icon in the outliner) in the viewport, because in the moment as I know there is no such shortcut?
As I understand, the visibility switch (screen icon) in the outliner is for all viewports?!

In the outliner, there is then no way to see, if objects are hidden per viewport.
Then it would be very important to have at least a viewmode per viewport, to see all its hidden objects, where you can select and unhide them independently.
There are lots of 3D programs out there, having this "Show Hidden" viewmode, showing all hidden objects, which is very usefull!
This "Show Hidden" viewmode could be activated by an icon on the top of the viewport next to collection visibility.

There could also be other usefull viewmodes like:
Show visible
Show hidden
Show selected
Show Unselected
Show all

After reading the proposal carfully I now have some questions. "1. In the outliner we only keep the screen and render visibility option (hide_render, hide_viewport)." Will there be a shortcut for disabling objects (screen icon in the outliner) in the viewport, because in the moment as I know there is no such shortcut? As I understand, the visibility switch (screen icon) in the outliner is for all viewports?! In the outliner, there is then no way to see, if objects are hidden per viewport. Then it would be very important to have at least a **viewmode** per viewport, to **see all its hidden objects**, where you can select and unhide them independently. There are lots of 3D programs out there, having this "Show Hidden" viewmode, showing all hidden objects, which is very usefull! This "Show Hidden" viewmode could be activated by an icon on the top of the viewport next to collection visibility.![viewmodes.JPG](https://archive.blender.org/developer/F5584701/viewmodes.JPG) There could also be other usefull viewmodes like: Show visible Show hidden Show selected Show Unselected Show all

Added subscriber: @jendrzych

@WilliamReynish You were faster than me - I was about to write a similar proposal (combining the Collection and Object visibility popovers)...
Anyway it's nice to be able to hide all items with exception for the one which name was clicked. Brilliant, but there’s no easy and similar way to unhide all, except the key shortcut. User has to close the popover to use the key shortcut, which is a pain in... You know where. Maybe a double click or aclick + a key modifier could be used to bring back previous visibility pattern? Not simple unhide all, but restore previous set of hidden and visible Collections/Objects. Or simple Ctrl+Z would do the job?

@WilliamReynish You were faster than me - I was about to write a similar proposal (combining the Collection and Object visibility popovers)... Anyway it's nice to be able to hide all items with exception for the one which name was clicked. Brilliant, but there’s no easy and similar way to unhide all, except the key shortcut. User has to close the popover to use the key shortcut, which is a pain in... You know where. Maybe a double click or aclick + a key modifier could be used to bring back previous visibility pattern? Not simple unhide all, but restore previous set of hidden and visible Collections/Objects. Or simple Ctrl+Z would do the job?

Added subscriber: @JulienKaspar

@brecht

I guess the difference would be in resetting the view matrix, which is part of local view. We could also make it so / only changes visibility for the current viewport, and H/Shift+H/Alt+H do it for all viewports.

I agree. This would make the local view feature different enough from the normal hiding and very useful on it's own, just like in 2.79.

@WilliamReynish
In the beginning of the Task you wrote while showing the screen icon:

In Blender, we have various levels of visibility. We already have a toggle for viewport visibility per view layer

Just a correction here: That is actually not true. The screen icon is for a viewport visibility across the entire file and when being linked to other files. Excluding and Including is used for view layer specific visibility for both the viewport and render.
But the eye icon is also used per view layer.

@brecht > I guess the difference would be in resetting the view matrix, which is part of local view. We could also make it so / only changes visibility for the current viewport, and H/Shift+H/Alt+H do it for all viewports. I agree. This would make the local view feature different enough from the normal hiding and very useful on it's own, just like in 2.79. @WilliamReynish In the beginning of the Task you wrote while showing the screen icon: > In Blender, we have various levels of visibility. We already have a toggle for viewport visibility per view layer Just a correction here: That is actually not true. The screen icon is for a viewport visibility across the entire file and when being linked to other files. Excluding and Including is used for view layer specific visibility for both the viewport and render. But the eye icon is also used per view layer.

@WilliamReynish, you ok with We could also make it so / only changes visibility for the current viewport, and H/Shift+H/Alt+H do it for all viewports. ?
This would still give an extra level of visibility. Not literally as Julien have pointed out, but the mental model of it.

Either way, in terms of implementation I will go like this:

Implement per-viewport collection visibility.
Move object visibility to be per-viewport.
(?) Local view as suggested by brecht.

Since local view is the last thing technically, we have some more time to discuss it thoroughly.

@WilliamReynish, you ok with `We could also make it so / only changes visibility for the current viewport, and H/Shift+H/Alt+H do it for all viewports.` ? This would still give an extra level of visibility. Not literally as Julien have pointed out, but the mental model of it. Either way, in terms of implementation I will go like this: * Implement per-viewport collection visibility. * Move object visibility to be per-viewport. * (?) Local view as suggested by brecht. Since local view is the last thing technically, we have some more time to discuss it thoroughly.

@dfelinto: Yes that sounds reasonable overall I think. It’s just that it should be clear which features apply to the current viewport and which apply to all viewports.

I take that having per-viewport collection visibility is unanimous, good.

As for H/Shift+H/Alt+H changing all viewports ... would it be per view-layer then? Just like we have now?

I take that having per-viewport collection visibility is unanimous, good. As for H/Shift+H/Alt+H changing all viewports ... would it be per view-layer then? Just like we have now?

As they are called viewlayer now, maybe you wish some sort of visibility per viewlayer?! Otherwise it woulf only be a renderlayer as in Blender 2.79.

@machieb there are viewlayers because the concept of render itself is confusing when it comes to realtime rendering. If you have a different view layer to show a subset of objects you want to work with the workbench engine, do you call it render?

@dfelinto, Isn't it the concept of viewlayers to show diffrent subsets of object? So you can deflect what will be renfered from what you see in the viewport. So I think the visibility which is changing all viewports, should be per viewlayer.

But maybe it becomes too complex, if you have visibility per viewport and visibility per viewlayer? And you also have the Collection viewlayer exclude/include option.
To make it less complex, maybe you only want to allow to exclude/include etc. collections in viewlayers?!

But maybe it becomes too complex, if you have visibility per viewport and visibility per viewlayer? And you also have the Collection viewlayer exclude/include option. To make it less complex, maybe you only want to allow to exclude/include etc. collections in viewlayers?!

Added subscriber: @DuarteRamos

Added subscriber: @sozap

It's going in the right direction ! sounds much simpler now !

I removed the ability here to set selectability per object type. I think this is not needed, and is easy to do in the Outliner anyway. Setting selectability per object type is too obscure and specialised, and something I think should be reserved for addons

That looked like a quite handy feature to me. When working on a team , layout artist tends to have all objects selectable , when going to animation , animators tends to make everything unselectable except armatures. And when it goes to rendering, people often re-enable the selectability.

Having a dedicated workspace for each one where layout and render artists have all selectable, and animator only armature , could have been a great use of 2.8 features. But indeed this can be solved with a custom script :/
Maybe the popover can have two colums, one for collections and one for visibility and selectability ?

Also, something that I miss from 2.79 that is related to visibility, is when working with dupli-group you could have hidden layers on the group . So the rig, lattices, meshdeform where always hidden in the shots, but in the original file you could display whatever you need without messing something.
Now there is the viewport visibility that replace this feature, but if I want to tweak the rig, I need to switch viewport visibility on objects that I need (rig, lattices) do the tweak, and finally re-switch visibility when leaving the file.
It's not a big issue but as this whole operation can be done several times a day, there will be mistakes...

I don't know how to adress that in a simple way, maybe having some extra visibility option when a collection is intended to be instanced ?
I've tried to override the visibility of some objects inside dupli when opening a shot (with python) , but that doesn't seems to work ...

It's going in the right direction ! sounds much simpler now ! > I removed the ability here to set selectability per object type. I think this is not needed, and is easy to do in the Outliner anyway. Setting selectability per object type is too obscure and specialised, and something I think should be reserved for addons That looked like a quite handy feature to me. When working on a team , layout artist tends to have all objects selectable , when going to animation , animators tends to make everything unselectable except armatures. And when it goes to rendering, people often re-enable the selectability. Having a dedicated workspace for each one where layout and render artists have all selectable, and animator only armature , could have been a great use of 2.8 features. But indeed this can be solved with a custom script :/ Maybe the popover can have two colums, one for collections and one for visibility and selectability ? Also, something that I miss from 2.79 that is related to visibility, is when working with dupli-group you could have hidden layers on the group . So the rig, lattices, meshdeform where always hidden in the shots, but in the original file you could display whatever you need without messing something. Now there is the viewport visibility that replace this feature, but if I want to tweak the rig, I need to switch viewport visibility on objects that I need (rig, lattices) do the tweak, and finally re-switch visibility when leaving the file. It's not a big issue but as this whole operation can be done several times a day, there will be mistakes... I don't know how to adress that in a simple way, maybe having some extra visibility option when a collection is intended to be instanced ? I've tried to override the visibility of some objects inside dupli when opening a shot (with python) , but that doesn't seems to work ...

I have nothing particular against the per object visibility, other than it seems like feature-creep to me, when we already have several ways to sets electability in the Outliner. I'll leave it up to @brecht and @dfelinto.

Added subscriber: @Rawalanche

I am a bit confused as to why do we now have two places in close proximity to do the same thing?

I am a bit confused as to why do we now have two places in close proximity to do the same thing? ![image.png](https://archive.blender.org/developer/F5640418/image.png)

@Rawalanche: If you read the proposal, this is about exactly that - changing that to make it more sensible so they are not the same. The thing in the viewport would then set the visibility in that viewport, and remove the eye icon in the Outliner which is redundant anyway.

@Rawalanche: If you read the proposal, this is about exactly that - changing that to make it more sensible so they are *not* the same. The thing in the viewport would then set the visibility in that viewport, and remove the eye icon in the Outliner which is redundant anyway.

If possible I'd rather keep per object type selectability in the popover, instead of per object type visibility, if only one can be kept.
Reasoning is that we already have lots of ways to control visibility, but selectability can only be set from the outliner.

Certain object types do get in the way in complex scenes some times, like lights, or you may only want to set active cameras without risking changing the scene, or move only armatures without selecting meshes.

If possible I'd rather keep per object type selectability in the popover, instead of per object type visibility, if only one can be kept. Reasoning is that we already have lots of ways to control visibility, but selectability can only be set from the outliner. Certain object types do get in the way in complex scenes some times, like lights, or you may only want to set active cameras without risking changing the scene, or move only armatures without selecting meshes.

Added subscriber: @Regnas

removed the ability here to set selectability per object type.

This is a regression imo. This is very useful.

> removed the ability here to set selectability per object type. This is a regression imo. This is very useful.

Added subscriber: @Znio.G

i think removing “hide toggle” is fine as it has hotkeys for it (H,Alt+H…etc) this make outliner cleaner , but restrict selection per object should be kept, as there is no other way to do it, and object type/collection popovers are nice especially if you work in full screen mode, u can move objects to collections with 'M', maybe make all these in one instead of the popover,so u won't need the outliner in full-screen.

In #57857#556012, @WilliamReynish wrote:
@Rawalanche: If you read the proposal, this is about exactly that - changing that to make it more sensible so they are not the same. The thing in the viewport would then set the visibility in that viewport, and remove the eye icon in the Outliner which is redundant anyway.

Ah, yes, sorry. Indeed I have not read the proposal, just skimmed over the pictures. I think it makes sense. At the same time it's kinda difficult to imagine there no longer being any central place that defines object visibility properties. For example, when creating a new viewport, if I wanted my collection visibilities to remain the same, would I have to re-setup them all over again? What if I wanted my collection visibilities to be in sync in multiple viewports?

For example when doing scene assembly, I often have one viewport that's camera, and other one from top view for better placement. I'd expect my visibilities to be in sync in both.

> In #57857#556012, @WilliamReynish wrote: > @Rawalanche: If you read the proposal, this is about exactly that - changing that to make it more sensible so they are *not* the same. The thing in the viewport would then set the visibility in that viewport, and remove the eye icon in the Outliner which is redundant anyway. Ah, yes, sorry. Indeed I have not read the proposal, just skimmed over the pictures. I think it makes sense. At the same time it's kinda difficult to imagine there no longer being any central place that defines object visibility properties. For example, when creating a new viewport, if I wanted my collection visibilities to remain the same, would I have to re-setup them all over again? What if I wanted my collection visibilities to be in sync in multiple viewports? For example when doing scene assembly, I often have one viewport that's camera, and other one from top view for better placement. I'd expect my visibilities to be in sync in both.

Added subscriber: @zeauro

1 to keep Object Type Selectability in popover.

In one of his videos, Pitiwazou showed visibility/selectability popover and explained that he wanted to be able to make a Ctrl click on one type to disable all the others.
He was talking about doing one Ctrl click on light selectability icon to disable all other object types. That way, he could manage lighting of his scene very quickly.

That will be interesting to add that to this new popover.

+ 1 to keep Object Type Selectability in popover. In one of his videos, Pitiwazou showed visibility/selectability popover and explained that he wanted to be able to make a Ctrl click on one type to disable all the others. He was talking about doing one Ctrl click on light selectability icon to disable all other object types. That way, he could manage lighting of his scene very quickly. That will be interesting to add that to this new popover.

Initial local view support: D3973.

Initial local view support: [D3973](https://archive.blender.org/developer/D3973).

Not sure if this is technically feasible, or even desirable, since we don't have multi-state buttons anywhere else in Blender.
We could save a lot of space in the collections popover if we combined the visibility and selectability buttons into a single multi-state toggle.

Since selectable invisible objects don't seem to make much sense, it could toggle between three states Disabled > Visible > Selectable,
One possible issue with this is making click-drag behavior predictable. Maybe the state of the first button you click is propagated to others(?).

See animated mockups bellow

Regardless of this proposal has already suggested here, Ctrl + Click on one of the icons would ideally disable all others, making it a quick way to invert state. For multi state multiple Ctrl + Click would toggle all others in sync.
Bonus points if this also worked in the outliner, for example Ctrl-clicking the visibility icon of a collection would isolate it, om the selection icon it would make all others unselectable.

Not sure if this is technically feasible, or even desirable, since we don't have multi-state buttons anywhere else in Blender. We could save a lot of space in the collections popover if we combined the visibility and selectability buttons into a single multi-state toggle. Since selectable invisible objects don't seem to make much sense, it could toggle between three states **Disabled > Visible > Selectable**, One possible issue with this is making click-drag behavior predictable. Maybe the state of the first button you click is propagated to others(?). See animated mockups bellow |![DEV_CollectionsPopoverCompact.gif](https://archive.blender.org/developer/F5683222/DEV_CollectionsPopoverCompact.gif)|![DEV_CollectionsPopover_Toggle.gif](https://archive.blender.org/developer/F5683221/DEV_CollectionsPopover_Toggle.gif)| | -- | -- | Regardless of this proposal has already suggested here, `Ctrl` + `Click` on one of the icons would ideally disable all others, making it a quick way to invert state. For multi state multiple `Ctrl` + `Click` would toggle all others in sync. Bonus points if this also worked in the outliner, for example `Ctrl`-clicking the visibility icon of a collection would isolate it, om the selection icon it would make all others unselectable.

Added subscriber: @frameshift

This comment was removed by @frameshift

*This comment was removed by @frameshift*

@dfelinto We're all very confused and helpless at the studio to be honest :D
The changes that we're commited made it much harder to use the hiding functionality in Blender and as far as I can see the way the proposal is described does not line up with how it works right now or how I can see it working in the future.

Hiding objects is not a per viewport function so why is the mini outliner still in every viewport? How will per object hiding now work when you can effectively only hide and show collections in the outliner? Is there going to be an additional shortcut introduced to unhide the selection to bring back some functionality that is missing now?

As far as I can see this feature seems half baked and very confusing and does not improve the hiding workflow in the current commits to Blender 2.8.
I would personally like to see this be a separate branch for the time until it's more complete and usable.

@dfelinto We're all very confused and helpless at the studio to be honest :D The changes that we're commited made it much harder to use the hiding functionality in Blender and as far as I can see the way the proposal is described does not line up with how it works right now or how I can see it working in the future. Hiding objects is not a per viewport function so why is the mini outliner still in every viewport? How will per object hiding now work when you can effectively only hide and show collections in the outliner? Is there going to be an additional shortcut introduced to unhide the selection to bring back some functionality that is missing now? As far as I can see this feature seems half baked and very confusing and does not improve the hiding workflow in the current commits to Blender 2.8. I would personally like to see this be a separate branch for the time until it's more complete and usable.

@JulienKaspar: Can you not use the viewport toggle (screen icon) to toggle visibility?

The problem we had, was that we were getting countless of reports about the eye vs the screen toggles. Nobody could figure out what to use when.

The idea here is that to set visibility normally in the Outliner, you use the viewport toggle, which toggles items in all viewports.

In each viewport you can also use the H-key, which toggles each item independently for each viewport. This is good for temporarily hiding things, like the local view.

We could have a shortcut also to toggle viewport visibility (screen icon)

@JulienKaspar: Can you not use the viewport toggle (screen icon) to toggle visibility? The problem we had, was that we were getting countless of reports about the eye vs the screen toggles. Nobody could figure out what to use when. The idea here is that to set visibility normally in the Outliner, you use the viewport toggle, which toggles items in all viewports. In each viewport you can also use the H-key, which toggles each item independently for each viewport. This is good for temporarily hiding things, like the local view. We could have a shortcut also to toggle viewport visibility (screen icon)

@WilliamReynish
Usually we don't use the screen icon because it affect the entire file and the files that it's linked to. When we toggle the viewport visibility (screen icon) we want it to stay that way. It's more rigid like the render visibility, which is the advantage of this way of hiding.
Using it for frequent hiding and unhiding is slower than the H shortcut and eye as well.

The eye icon visibility is not per viewport, at least for now. But I also don't think it should be to be honest.
It's useful as a fast and frequent way of hiding objects but also with the option to quickly toggle them individually on/off in the outliner if needed. It's much more flexible, frequent and easily reversible when unhiding all.

Local view on the other hand is a much more temporary way of hiding. It's more restrictive but also way simpler. It's also per viewport, which gives it extra distinction between the other visibility options.

@WilliamReynish Usually we don't use the screen icon because it affect the entire file and the files that it's linked to. When we toggle the viewport visibility (screen icon) we want it to stay that way. It's more rigid like the render visibility, which is the advantage of this way of hiding. Using it for frequent hiding and unhiding is slower than the H shortcut and eye as well. The eye icon visibility is not per viewport, at least for now. But I also don't think it should be to be honest. It's useful as a fast and frequent way of hiding objects but also with the option to quickly toggle them individually on/off in the outliner if needed. It's much more flexible, frequent and easily reversible when unhiding all. Local view on the other hand is a much more temporary way of hiding. It's more restrictive but also way simpler. It's also per viewport, which gives it extra distinction between the other visibility options.

The object / collection hiding should not become per-viewport, at least not without an option like 2.7 to lock/unlock things. The collection hiding is intended to only affect 3D viewports, and be quickly switchable similar to the old layer buttons in the header. So these changes were intended to bring us closer to that again.

As far as I can tell the underlying hiding logic is something we can agree on. The contentious issue is the user interface, do we show the eye icon in the outliner or not? Can we make it more clear to users somehow? Should it be an outliner option?

The object / collection hiding should not become per-viewport, at least not without an option like 2.7 to lock/unlock things. The collection hiding is intended to only affect 3D viewports, and be quickly switchable similar to the old layer buttons in the header. So these changes were intended to bring us closer to that again. As far as I can tell the underlying hiding logic is something we can agree on. The contentious issue is the user interface, do we show the eye icon in the outliner or not? Can we make it more clear to users somehow? Should it be an outliner option?

Added subscriber: @thornydre

As Julien said, the "screen icon" is not used that often, so maybe it could but in the right click menu only, an not in directly in the outliner, it would make the outliner a bit clearer as well, and it would avoid missclicking on it, and having this object disappear in all the linked files :/

I can think of a few alternative solutions:

We could make it so you only see the eye in the Outliner. The linked visibility is then something more specialized - perhaps something you can enable with right-click on item, which then shows an indicator. If we do this, the behaviour of the eye icon toggle needs to be better, so that you can properly hide a Collection without toggling the collection contents, for example
Keep as-is, but show an indicator in Outliner next to items that are hidden, but not an actual toggle, to make it so users will use the screen icon, but can still see which items are hidden

Basically, I could go either way - the main issue was that we had two toggles that did almost the same thing, and nobody could figure out what to do. Either we should promote the use of the hide/unhide toggle (eye), or the viewport on/off toggle (screen).

I can think of a few alternative solutions: - We could make it so you *only* see the eye in the Outliner. The linked visibility is then something more specialized - perhaps something you can enable with right-click on item, which then shows an indicator. If we do this, the behaviour of the eye icon toggle needs to be better, so that you can properly hide a Collection without toggling the collection contents, for example - Keep as-is, but show an indicator in Outliner next to items that are hidden, but not an actual toggle, to make it so users will use the screen icon, but can still see which items are hidden Basically, I could go either way - the main issue was that we had two toggles that did almost the same thing, and nobody could figure out what to do. Either we should promote the use of the hide/unhide toggle (eye), or the viewport on/off toggle (screen).

Added subscriber: @eyecandy

I agree having two hiding options in the outliner is in fact confusing. however, I really miss the eye icon hiding per object (as opposed to H/ALT+H/SHIFT+H) because it was a very quick and powerful way of isolating a bunch of objects quickly, add or remove objects to that isolation on the go, then jump back to it's default state with ALT+H. In the studio we treat the screen icon hiding as a more permanent way, since it does transfer to linked subcollections.

I'm really in favor of bringing this behavior back. maybe not via the outliner, maybe there should be a way to access a list of objects/outliner per 3d view. Currently the 'collection visibility' popover is highly confusing in its sorting though, and adding objects to it would bloat it to the point of unusability.

I agree having two hiding options in the outliner **is** in fact confusing. however, I really miss the eye icon hiding per object (as opposed to H/ALT+H/SHIFT+H) because it was a very quick and powerful way of isolating a bunch of objects quickly, add or remove objects to that isolation on the go, then jump back to it's default state with ALT+H. In the studio we treat the screen icon hiding as a more permanent way, since it does transfer to linked subcollections. I'm really in favor of bringing this behavior back. maybe not via the outliner, maybe there should be a way to access a list of objects/outliner per 3d view. Currently the 'collection visibility' popover is **highly** confusing in its sorting though, and adding objects to it would bloat it to the point of unusability.

Added subscriber: @ThinkingPolygons

In #57857#559319, @brecht wrote: do we show the eye icon in the outliner or not?

Please bring it back.
This is literally the most used and useful feature of any outliner. I can't even imagine an outliner without it.

> In #57857#559319, @brecht wrote: do we show the eye icon in the outliner or not? Please bring it back. This is literally the most used and useful feature of any outliner. I can't even imagine an outliner without it.

I am just adding my vote that I also find Screen and Eye icons in the outliner confusing. I did not yet bring myself to look up and figure how it works. I did not understand it but with a few test clicks, I noticed that the screen icon appears to be a superset of the eye icon, so I just adapted the habit of always using the screen icon, as it does what I need it to do.

That being said, I really don't think that Outliner visibility toggle should be something user needs to study and figure out. It's a nobrainer in other 3D packages :)

I am just adding my vote that I also find Screen and Eye icons in the outliner confusing. I did not yet bring myself to look up and figure how it works. I did not understand it but with a few test clicks, I noticed that the screen icon appears to be a superset of the eye icon, so I just adapted the habit of always using the screen icon, as it does what I need it to do. That being said, I really don't think that Outliner visibility toggle should be something user needs to study and figure out. It's a nobrainer in other 3D packages :)

@eyecandy What if there was only the eye toggle in the Outliner, and then the screen icon toggle is something you can do elsewhere, or simply a section you can enable if you are working with linked files?

This way users will just use the eye toggle normally in normal scenes, and then if you want special visibility for linked objects you can set that in a more deliberate way.

@eyecandy What if there was only the eye toggle in the Outliner, and then the screen icon toggle is something you can do elsewhere, or simply a section you can enable if you are working with linked files? This way users will just use the eye toggle normally in normal scenes, and then if you want special visibility for linked objects you can set that in a more deliberate way.

@Rawalanche: Yes this was the issue - the differences between eye and screen toggles were/are too obscure. Most users will never figure out the difference. So we thought, we could just have one in the Outliner, so users just use one of them.

Just like in Edit Mode, where H key hides vertices without an eye icon in the Outliner, there's some sense in doing the same for objects too.

But, one could also do the opposite - only have the eye in the Outliner, and then make the viewport toggle more hidden for specialized cases such as controlling visibility in linked files.

@Rawalanche: Yes this was the issue - the differences between eye and screen toggles were/are too obscure. Most users will never figure out the difference. So we thought, we could just have one in the Outliner, so users just use one of them. Just like in Edit Mode, where H key hides vertices without an eye icon in the Outliner, there's some sense in doing the same for objects too. But, one could also do the opposite - only have the eye in the Outliner, and then make the viewport toggle more hidden for specialized cases such as controlling visibility in linked files.

Added subscriber: @Rusculleda

How about a toggle to show/hide the viewport visibility column in the outliner? Similar to the after effects toggles for showing/hidding blend modes columns and others. Hidden by default.

We move the collections and objects visibility to be per-viewport.

In the viewport collection popover we control only the per-viewport collection visibility (we can still indicate if there is any object in this collection that is invisible).

Are this features of the above proposal still coming??

This way users will just use the eye toggle normally in normal scenes, and then if you want special visibility for linked objects you can set that in a more deliberate way.

That would be a good idea! Not everyone uses linked objects.

> 2. We move the collections and objects visibility to be per-viewport. > 3. In the viewport collection popover we control only the per-viewport collection visibility (we can still indicate if there is any object in this collection that is invisible). Are this features of the above proposal still coming?? > This way users will just use the eye toggle normally in normal scenes, and then if you want special visibility for linked objects you can set that in a more deliberate way. That would be a good idea! Not everyone uses linked objects.

Yep, I am fine with just the one in outliner, and other one being somewhere else :)

I strongly believe the eye icon should remain in the outliner for all objects, ideally along viewport visibility functionality.

This seems to be just a matter of miscommunication.
As far as I understood the viewport visibility icon works across all viewports, and prevents Alt+H from unhiding.
In other software the equivalent of this functionality is often called Freezingor Locking and generally as a snowflake glyph {F5745887, layout=inline, size=full} for icon.

If we make this slight cosmetic change and replace the current "monitor" icon with some other clearer glyph, I believe it will go a long way to solve most issues and misunderstandings.

If we do end up keeping only one type of visibility in the outliner, which I feel is a step back, I believe the eye glyph should be the one used regardless of what it does, for clarity sake.

I strongly believe the eye icon should remain in the outliner for all objects, ideally along viewport visibility functionality. This seems to be just a matter of miscommunication. As far as I understood the viewport visibility icon works across all viewports, and prevents Alt+H from unhiding. In other software the equivalent of this functionality is often called Freezingor Locking and generally as a snowflake glyph {[F5745887](https://archive.blender.org/developer/F5745887/Snowflake.png), layout=inline, size=full} for icon. If we make this slight cosmetic change and replace the current "monitor" icon with some other clearer glyph, I believe it will go a long way to solve most issues and misunderstandings. If we do end up keeping only one type of visibility in the outliner, which I feel is a step back, I believe the eye glyph should be the one used regardless of what it does, for clarity sake.

One thing is the icon itself (the glyph) the other is the functional difference between hiding/unhiding (H/alt-H) and viewport visibility (affects linked assets) and how to control those things.

In #57857#559328, @WilliamReynish wrote:
@eyecandy What if there was only the eye toggle in the Outliner, and then the screen icon toggle is something you can do elsewhere, or simply a section you can enable if you are working with linked files?

This way users will just use the eye toggle normally in normal scenes, and then if you want special visibility for linked objects you can set that in a more deliberate way.

This could work. as long as there is an easy way of figuring out the visibility/renderability of an object at first glance. E.g. you don't want to hide something and then inexplicably have it turn up in renders without giving the user feedback to its cause... this could lead to more confusion.

I know our animators exclusively use the Screen icon because it excludes hidden rigs to be evaluated (makes things faster).

> In #57857#559328, @WilliamReynish wrote: > @eyecandy What if there was only the eye toggle in the Outliner, and then the screen icon toggle is something you can do elsewhere, or simply a section you can enable if you are working with linked files? > > This way users will just use the eye toggle normally in normal scenes, and then if you want special visibility for linked objects you can set that in a more deliberate way. This could work. as long as there is an easy way of figuring out the visibility/renderability of an object at first glance. E.g. you don't want to hide something and then inexplicably have it turn up in renders without giving the user feedback to its cause... this could lead to more confusion. I know our animators exclusively use the Screen icon because it excludes hidden rigs to be evaluated (makes things faster).

@WilliamReynish

We could make it so you only see the eye in the Outliner. The linked visibility is then something more specialized - perhaps something you can enable with right-click on item, which then shows an indicator.

I have a proposal that kind of builds on this idea:

So what if we merge the eye and screen icon in a way that you can "lock" the eye icon to be hidden.
So you can still easily hide and unhide objetcs via the outliner and if you want the visibility to be fixed as hidden you will be able to for example Ctrl click the eye icon and it adds a lock icon to the corner of a closed eye (or even just a lock icon?).
This way the visibility of this item is no longer affected by H, Alt + H and Shift + H.

For this to be obvious maybe the Tooltip when hovering over the eye icon can explain that you can use Ctrl for this purpose.

There are some problems that I can see though when merging the icons since they did have different behaviours. As far as I can tell they were:

When hiding a collection with the eye icon it hides all the contents, even when they are linked. When hiding a collection with the screen icon it only affects the collection itself.
the eye icon is view layer specific. The screen icon is global throughout the file.
The screen icon affects if the objects/collections are being calculated in the 3d view. The eye icon less so. That's probably why the screen icon hiding is slower.

So how wold we address those when merging the 2 icons? My suggestions would be

When locking the eye icon to be hiden on a collection it will only affect the collection itself. When just toggling the eye icon it will hide all contents instead.
Both the hiding and locking could be made global. Or the locking is global while the hiding is view layer specific. This needs to be explained in the tooltip I guess.
Either both the hiding and locking affects the objects being calculated or it will only happen when locking an object or collection.

@WilliamReynish > We could make it so you *only* see the eye in the Outliner. The linked visibility is then something more specialized - perhaps something you can enable with right-click on item, which then shows an indicator. I have a proposal that kind of builds on this idea: So what if we merge the eye and screen icon in a way that you can "lock" the eye icon to be hidden. So you can still easily hide and unhide objetcs via the outliner and if you want the visibility to be fixed as hidden you will be able to for example Ctrl click the eye icon and it adds a lock icon to the corner of a closed eye (or even just a lock icon?). This way the visibility of this item is no longer affected by H, Alt + H and Shift + H. For this to be obvious maybe the Tooltip when hovering over the eye icon can explain that you can use Ctrl for this purpose. There are some problems that I can see though when merging the icons since they did have different behaviours. As far as I can tell they were: - When hiding a collection with the eye icon it hides all the contents, even when they are linked. When hiding a collection with the screen icon it only affects the collection itself. - the eye icon is view layer specific. The screen icon is global throughout the file. - The screen icon affects if the objects/collections are being calculated in the 3d view. The eye icon less so. That's probably why the screen icon hiding is slower. So how wold we address those when merging the 2 icons? My suggestions would be - When locking the eye icon to be hiden on a collection it will only affect the collection itself. When just toggling the eye icon it will hide all contents instead. - Both the hiding and locking could be made global. Or the locking is global while the hiding is view layer specific. This needs to be explained in the tooltip I guess. - Either both the hiding and locking affects the objects being calculated or it will only happen when locking an object or collection.

Yes, I meant the glyph, I apologize, I lacked the proper lingo. Edited comment above for clarity.

Viewport visibility is functionally often called freezing {F5745887, layout=inline, size=full} , users coming from other software would probably recognize it a lot better with a different glyph.

Yes, I meant the glyph, I apologize, I lacked the proper lingo. Edited comment above for clarity. Viewport visibility is functionally often called freezing {[F5745887](https://archive.blender.org/developer/F5745887/Snowflake.png), layout=inline, size=full} , users coming from other software would probably recognize it a lot better with a different glyph.

@JulienKaspar Yes that could be one way to go, something like that maybe. I will leave it to @brecht and @dfelinto to think about.

The terms "freezing" and "locking" would make it more obvious what the visibility option is for.

I can also see the option be available through the RMB menu but we could enable both. Maybe the option in the RMB menu can show a shortcut like the exclusion does?
Maybe "locking" can be done via hitting "L" on selected items?

The terms "freezing" and "locking" would make it more obvious what the visibility option is for. I can also see the option be available through the RMB menu but we could enable both. Maybe the option in the RMB menu can show a shortcut like the exclusion does? Maybe "locking" can be done via hitting "L" on selected items?

I will bring back the eye icon in the outliner, so Spring artists and other users can continue working.

After that, we can experiment with better solutions. Merging hide and viewport visibility icons as suggested by @JulienKaspar seems promising.

Eventually using the eye icon should also work to improve performance with animation playback, but this requires some deep changes in the depsgraph.

I will bring back the eye icon in the outliner, so Spring artists and other users can continue working. After that, we can experiment with better solutions. Merging hide and viewport visibility icons as suggested by @JulienKaspar seems promising. Eventually using the eye icon should also work to improve performance with animation playback, but this requires some deep changes in the depsgraph.

In #57857#559366, @brecht wrote:
Merging hide and viewport visibility icons as suggested by @JulienKaspar seems promising.

That sounds like a good compromise, we keep functionality while decluttering the UI.
Here are two a possible mockups of how it could look.
{F5746133, size=full}

> In #57857#559366, @brecht wrote: > Merging hide and viewport visibility icons as suggested by @JulienKaspar seems promising. That sounds like a good compromise, we keep functionality while decluttering the UI. Here are two a possible mockups of how it could look. {[F5746133](https://archive.blender.org/developer/F5746133/DEV_CollectionVisibility.gif), size=full}

But, one could also do the opposite - only have the eye in the Outliner, and then make the viewport toggle more hidden for specialized cases such as controlling visibility in linked files.

That would be awesome !

When do you want objects not to be visible ?

bollean objects
lattices, mesh deform
helpler objects ( an empty that is used for an array or a mirror)
a rig on a linked collection

all these objects, you want them to be hidden, especially when you work with linked files.

But you also want to unhide them so you can tweak them, but without messing visibility when they are linked.

Maybe we could have :

1/ A way to lock visibility : equivalent of the hide viewport

          maybe that can be achieved with hide icon + selectability icon, even if you do alt-h , it stays hidden

2/ A way to quickly hide/unhide stuff -> H / alt-H

3/ A way to keep objects hidden when linked, but visible in the original file (equivalent to old hidden group layers)
That can be a more specific / not in the outliner option , because you want that only on helper objects, or armature , lattices, mesh deform...

> But, one could also do the opposite - only have the eye in the Outliner, and then make the viewport toggle more hidden for specialized cases such as controlling visibility in linked files. That would be awesome ! When do you want objects not to be visible ? - bollean objects - lattices, mesh deform - helpler objects ( an empty that is used for an array or a mirror) - a rig on a linked collection all these objects, you want them to be hidden, especially when you work with linked files. But you also want to unhide them so you can tweak them, but without messing visibility when they are linked. Maybe we could have : 1/ A way to lock visibility : equivalent of the hide viewport ``` maybe that can be achieved with hide icon + selectability icon, even if you do alt-h , it stays hidden ``` 2/ A way to quickly hide/unhide stuff -> H / alt-H 3/ A way to keep objects hidden when linked, but visible in the original file (equivalent to old hidden group layers) That can be a more specific / not in the outliner option , because you want that only on helper objects, or armature , lattices, mesh deform...

Added subscriber: @Northsteel

Added subscriber: @DanielPaul

Excuse me if this was mentioned before.
How will the viewport and render visibility toggles be used in the future?

What if I want to animate the visibility of many objects by the outliner.
Do I have to animate viewport visibility and render visibility separately,
so I have feedback in the viewport what I am doing?
Or is a shortcut for (change render/view visibility simultaneously) planed?

In 2.7 animating the scale was the easiest way of animating visibility,
unfortunately, objects and their shaders are calculated even when they are scaled to 0.
In big scenes with complex shaders, this is a problem, especially in eevee.

A viewport mode for seeing the actual renderstate could also help here.
Something like "show viewport as render view" #57063

I think this is really important to avoid wrong renderings.
Happens really often to me with 2.8 at the current state.

Excuse me if this was mentioned before. How will the viewport and render visibility toggles be used in the future? What if I want to animate the visibility of many objects by the outliner. Do I have to animate viewport visibility and render visibility separately, so I have feedback in the viewport what I am doing? Or is a shortcut for (change render/view visibility simultaneously) planed? In 2.7 animating the scale was the easiest way of animating visibility, unfortunately, objects and their shaders are calculated even when they are scaled to 0. In big scenes with complex shaders, this is a problem, especially in eevee. A viewport mode for seeing the actual renderstate could also help here. Something like "show viewport as render view" #57063 I think this is really important to avoid wrong renderings. Happens really often to me with 2.8 at the current state.

Added subscriber: @tgarriott

Added subscriber: @Mets

What if, in both the outliner and mini-outliner, the Enabledness/Visibility/Selectability would only appear when the one before it is ON?

A disabled object would look like this:

If the object is enabled, the visibility shows up:

And if the object is visible, the selectability shows up:

The render icon is now the first in the list, because it would be odd to make new buttons appear in the middle of the list. Ofc the render icon wouldn't exist in the mini-outliner.

Maybe this could work somewhat well with click+drag? But since the buttons are aligned to the right, and the icons pop up on the right, the newly popped up icons would pop right under the mouse. So maybe the order would need to be flipped for the sake of click+drag.

What if, in both the outliner and mini-outliner, the Enabledness/Visibility/Selectability would only appear when the one before it is ON? A disabled object would look like this: ![u7D71el.png](https://archive.blender.org/developer/F6555167/u7D71el.png) If the object is enabled, the visibility shows up: ![G1rFSdo.png](https://archive.blender.org/developer/F6555230/G1rFSdo.png) And if the object is visible, the selectability shows up: ![TxRIzcQ.png](https://archive.blender.org/developer/F6555343/TxRIzcQ.png) The render icon is now the first in the list, because it would be odd to make new buttons appear in the middle of the list. Ofc the render icon wouldn't exist in the mini-outliner. Maybe this could work somewhat well with click+drag? But since the buttons are aligned to the right, and the icons pop up on the right, the newly popped up icons would pop right under the mouse. So maybe the order would need to be flipped for the sake of click+drag.

Added subscriber: @DasCoont

Using blender feb 14 nightly build, currently un-hiding objects selected in local view also globally unhides all objects, can this be reverted back to 2.79 functionality? I want to be able to hide/unhide objects in local view while having objects hidden in global view still remain hidden and unnaffected.

Changed status from 'Open' to: 'Archived'

Archiving in favor of #61578 (Outliner Visibility Update), which contains the latest version of the proposed design (to be further updated after discussion at homestretch workshop).

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Collections, objects visibility and local view #57857

Proposal

Viewport visibility UI