@Dalai Felinto (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)?!
@Dalai Felinto (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

@William Reynish (billreynish) 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?

@Brecht Van Lommel (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.

@William Reynish (billreynish)
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.

@William Reynish (billreynish), 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.

@Dalai Felinto (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?

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.

@Marcus Papathoma (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?

@Dalai Felinto (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?!

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 Van Lommel (brecht) and @Dalai Felinto (dfelinto).

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

@Ludvik Koutny (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.

removed the ability here to set selectability per object type.

This is a regression imo. This is very useful.

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 T57857#556012, @William Reynish (billreynish) wrote:

@Ludvik Koutny (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.

+ 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.

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.

@Dalai Felinto (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.

@Julien Kaspar (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)

@William Reynish (billreynish)
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?

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:

1. 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
2. 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 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.

In T57857#559319, @Brecht Van Lommel (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 :)

@Andy Goralczyk (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.

@Ludvik Koutny (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.

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.

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 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 T57857#559328, @William Reynish (billreynish) wrote:

@Andy Goralczyk (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).

@William Reynish (billreynish)

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 , users coming from other software would probably recognize it a lot better with a different glyph.

@Julien Kaspar (JulienKaspar) Yes that could be one way to go, something like that maybe. I will leave it to @Brecht Van Lommel (brecht) and @Dalai Felinto (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?

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 @Julien Kaspar (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 T57857#559366, @Brecht Van Lommel (brecht) wrote:

Merging hide and viewport visibility icons as suggested by @Julien Kaspar (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.

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...

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" T57063

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

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.

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.