Page MenuHome

Visibility Toggles: Logic & Usability
Open, Needs Triage by DeveloperPublic

Description

The issue:

At the Blender Animation Studio we have been working with the outliner and visibility settings of Blender 2.8 for almost a year now ... and almost every person ended up using those features in a completely different way.
With the inclusion of "disable for viewports" (screen icon), exclusion & view layers and the replacement of the old layers, the visibility system beacme more complex.
Some of these toggles are never even used, by some users they are not even understood to this day.
There should be a clear understanding on how these toggles should be used and for which context but the interface and the tooltips do a very poor job at communicating this at the moment.

The current visibility system:

This is @Dalai Felinto (dfelinto) description of the current visibility system/toggles:

Collection visibility control
=========================

  • Disable for viewports/render:
    • Affects all view layers.
    • Performance efficient.
    • Allow for a collection to be only in render or only in viewports.
    • Particularly useful for collection that will be instanced (e.g., hide highpoly in viewport, show highpoly in render).
  • Exclude (disable collection for both viewport and render):
    • Per view layer.
    • Performance efficient.
    • Highly recommended for animators.
  • Hide/show in viewports:
    • Per view layer.
    • Little impact in performance.
    • Quick temporary visibiliy control.

Object visibility control
=========================

  • Disable for viewports/render:
    • Affects all view layers.
    • Useful for support objects (never to be rendered).
    • Note: You can use this for objects that are to be instanced, to separate highpoly and low poly objects, that said you can/should use collections instead.
  • Hide/show in viewports:
    • Per view layer.
    • Quick temporary visibility state.
  • Local view:
    • Per viewport.
    • Even quicker temporary visibility state.

So in most cases the user is supposed to use the eye icon for quick & easy hiding and the excluding to hide collections in a performance efficient way (similar to the old layers) and for render setups. These toggles are per view layer.
Disabling for the viewport/render are two toggles (screen/camera) that affect an object/collection throughout the entire file and should be used more sparingly for corner cases and linking setups.
Local view is an additional temporary visibility mode.

This needs to be as clear as possible in the UI & tooltips!

UI proposal:

To make the excluding feature and eye toggle the obvious choices for the user they should be front & center.

  • We add the exclusion as a checkmark to the interface on the left. This makes it one of the most obvious toggles to use.
  • When an item is toggled off, every other toggle is greyed out to clearly show the effect on the item. The greyed out toggles can still be toggled though. The icons should not be hidden when excluded like it does right now.
  • When toggling off an eye, render or selectability icon of a collection, all nested contents will have the same icon greyed out to visualise the effect of nested visibility. An exception would be if any nested object/collection is also linked to another collection and this collection does have the icon still on. Then this nested object/collection will be still visible and should not be greyed out as well. For the case that the user wants to ensure all contents (linked or not) are hidden, they can Shift click the icon instead and all nested content will be toggled off.

For now, keeping the "disabled for viewport" (screen icon) as an Alt click for the eye icon is fine. Because the screen icon is mostly used for corner cases that overrides the eye icon, this should work. It also causes less confusion since there would be 2 columns that control viewport visibility.

The tooltips for all the outliner toggles should reflect descriptions above to clear up any remaining confusion on how to use the system.
Currently the tooltips are short and just mention "disabling" and "viewports" which means very little and is confusing/misleading.

Functionality proposal:

To ensure that the eye toggle is fast, easy to use and flexible, there should be a couple of changes to the behaviour.
This is a compromise between the new behaviour of D4011 and the behaviour before those changes.

  • When unhiding an object that within a hidden collection, that collection will become shown as well. If there are more hidden collections in the hierarchy above then they will be toggled as well. This will make sure that when the user is toggling an eye icon on, that object/collection will be shown.
  • When pressing the shortcut Alt + H, either in the viewport or the outliner, it will unhide all objects and collections. Currently the behaviour is a bit inconsistent because pressing the shortcut in the viewport will only unhide all objects but not the collections.

Open questions:

  • Since the camera icon is very similar to the screen icon and the exclusion checkmark should be used for render setups, perhaps it's wise to remove that column as well by default? For users who use the screen/camera icons often, maybe there could be a filtering option in the outliner to add these as a columns. Then by default they could both be disabled to make the eye & checkmark the obvious choices. But the user could also specifically choose which columns get displayed instead of having one option "Show Restriction Columns" to disable eveything.

  • Linked objects & collections are also greyed out. Maybe they could be slightly colored red instead to not cause confusion with nested visibility visualisation?
  • Exclusion currently only works for collections. Should the checkmark be available for objects as well?
  • Any linked collection does not share the eye icon state of another linked version. Linked objects on the other hand keep the state of the eye icon in sync. To keep this behaviour consistent should the eye icon be synchronised to linked collections?
  • Originally I proposed to use the number keys to toggle the checkmark/exclusion instead of the eye. Does this sounds reasonable, since it seems closer to the way of toggling layers in 2.7x?
  • Should we display the corresponding numbers of collections in the outliner in front of collections or somewhere else (or at all)? Since it's a feature it should be communicated somewhere.

If I forgot to add anything or you have more feedback, let me know :)

Details

Type
Design

Event Timeline

The 'unlinked' viewport visibility ( T61327 ) gives you the ability to set up temporary visibility and then return to the main one. 2.79 also did it this way. On top of that, that solution also adds the ability to see different things in different viewports, which is often important in productions anyway.

To me this seems like a smarter solution that doesn't require adding lots of complexity to the Outliner.

@William Reynish (billreynish)

Makes sense but there's an issue with this:

In 2.7x the eye icon and the layers were not the same. .
I think it's generally more useful if the eye icon is used for quick & easy hiding & showing like how it used to work before D4011. Alt + H would then actually unhide everything and collcetions would toggle their own eye on/off in a smart way based on what is shown/hidden within them.
Using excluding for toggling collections in a more rigid way in this mini outliner could work instead.

Another issue is that the eye doesn't stop objects from being calculated properly, so the viewport performance stays the same even when objects are hidden with the eye icon.
This makes the menu in T61327 mostly useless for animators and when working on large scenes and those users will use the screen icon or exclusion instead (if they know about it).
I also wouldn't suggest to make the eye icon toggle if objects are being calculated, since this will involve more waiting times when hiding/showing. Keeping the eye icon as the fast visibility option is important.
Making exclusion the obvious secondary choice in the interface for managing visibility seems like the way to go in my opinion.

I hope that when using exclusion for this we can still unlink visibility between 3D viewports. Might not work with the dependency graph but specifying which 3D viewport uses which View Layer could bring multiple systems together instead of essentially creating another layer of visibility.
Then we would also need to allow user to adjust the exclusion of multiple view layers in the outliner without constantly switching the view layer on the top right corner.

The eye icons were only for objects in 2.79. Showing/Hiding layers would show all the visible objects inside. With Collections it's exactly the same (only more flexible with nesting, names etc)

@William Reynish (billreynish)
Well that sounds pretty simple. But just as food for thought:

If it is exactly like that then why do we need view layers, excluding & the screen icon that are all essentially just more layers above in the chain of viewport visibility.
If we can manage collection & object visibility all with the eye icon the way it works right now and this is similar to how it used to work in 2.7x, then why do we add more complexity on top.
For example excluding & render layers used to be a render setting in 2.7x after all, not a viewport one.

View Layers = Render Layers.

You could always set layer visibility per Render Layer - likewise for Collections and View Layers.

The difference is that View Layers are also visible in the viewport by default. In 2.79 you could do this by as an extra option, but now it is default.

Yes but by making these options affect both viewport and render visibility it makes it more confusing.

Let's say we want to get rid of these two issues:

  • The many visibility toggles and hidden visibility features are too confusing and not clear on how to use them.
  • The easiest to access visibility toggle, the eye icon, doesn't improve the viewport performance.

We could remove excluding from affecting viewport visibility and only make it be a render visibility toggle. We keep excluding as a "per view layer render toggle".
This way we have 4 distinct settings:

  • Show/Hide in the current view layer (eye)
  • Show/Hide in all view layers (screen)
  • Render/Don't Render in the current view layer (exclude)
  • Render Don't render in all view layers (camera)

We keep the changes from D4011 so that the screen icon is only accessed by Alt clicking the eye icon and the new behaviour of the eye icon.
The same can apply to the camera icon. When toggling it will disable rendering for the current view layer (excluding) and when Alt clicking it will disable rendering for all view layers.

I can also see all 4 toggles being exposed as 4 columns in the outliner since it makes the available options more obvious and clear. If the tooltips describe the 4 toggles like explained above, it should be easier to understand for the user.

When hiding individual objects it could work as usual but when hiding collections it will remove its contents from being calculated to improve viewport performance.
This way the user doesn't need the screen icon or exclusion to improve framerates on playback.

If the user wants to see in the viewport what will be visible in the render, there could be a "Show rendered" option to use the render visibility settings for the viewport visibility.
This could be a useful feature for multiple cases.

To me the confusing part is the difference between hidden (eye) and disabled (screen) state. The way it's resented was confusing before, and now it's still confusing - just more hidden.

Here's an illustration of how I would solve it:

The idea here is to:

  • Make enabled/disabled apply to both viewport and render
  • Turn it into a checkmark

If we did this, the difference IMO becomes a lot more clear. If we present it like this, it's obvious that completely disabling something has a bigger effect than hiding it. Then it starts to make more intuitive sense that disabling affects the depsgraph evaluation, whereas the hidden state just affects visibility.

It also gives us an easier way to make something invisible in both viewport and render. So it's both clearer and more practical, and eliminates the need for hidden Alt-clicking.

An additional beneficial side-effect of this is that, if you hide the toggles by hiding the Restriction Columns to gain more space, the Outliner is still fully useable:

I agree with William I believe it is just a miscommunication issue, more specifically a matter of using the correct icon and label.
As I have mentioned before, if we named it something along the lines of "Freezing" and changed the icon to a snowflake or similar (if copyright doesn't get in the way) it would solve most confusions

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 Freezing or Locking and generally as a snowflake glyph for icon.

I like that solution; that would certainly make it a lot clearer. The only issue I see is it still steals precious horizontal space in the outliner.
Since a disabled object can't really be visible or selected, we could just make the visibility icon a three way toggle between three states Visible (open eye icon) > Hidden (closed eye icon) > Disabled (snowflake or lock)

@Duarte Farrajota Ramos (duarteframos) In a way it steals horizontal space, but in another way you actually gain space, because you can often times disable the restriction columns. They would not be needed, unless you want to set viewport visibility to be different from render visibility, or to set selectability. All these things are secondary.

At the Blender Animation Studio we have been working with the outliner and visibility settings of Blender 2.8 for almost a year now ... and almost every person ended up using those features in a completely different way.

I hope to address this with the following. I believe it may be time to update our documentation on the different visibility settings (@Pablo Vazquez (pablovazquez) maybe we could do a new illustrated blogpost?).
Meanwhile this is how I see the differences and their different uses (@Brecht Van Lommel (brecht) agree?)

Collection visibility control

  • Disable for viewports/render:
    • Affects all view layers.
    • Performance efficient.
    • Allow for a collection to be only in render or only in viewports.
    • Particularly useful for collection that will be instanced (e.g., hide highpoly in viewport, show highpoly in render).
  • Exclude (disable collection for both viewport and render):
    • Per view layer.
    • Performance efficient.
    • Highly recommended for animators.
  • Hide/show in viewports:
    • Per view layer.
    • Little impact in performance.
    • Quick temporary visibiliy control.

Object visibility control

  • Disable for viewports/render:
    • Affects all view layers.
    • Useful for support objects (never to be rendered).
    • Note: You can use this for objects that are to be instanced, to separate highpoly and low poly objects, that said you can/should use collections instead.
  • Hide/show in viewports:
    • Per view layer.
    • Quick temporary visibility state.
  • Local view:
    • Per viewport.
    • Even quicker temporary visibility state.

@William Reynish (billreynish) I have some questions about your proposal.

  • How can the user disable something from the viewport without it being disabled from the rendering? That is still an essential feature.
  • Is the checkmark disable toggle per view layer or global?
  • If it's global, disabling for rendering with the checkmark not just exactly the same as toggling the camera icon?
  • If it's per view layer, isn't it exactly like the exclusion? In that case we would still need to have something like the screen icon to disable an item globally for the viewport.

Having the visibility toggles in terms of functionality like this would be the clearest thing I could think of:

  • Show/Hide in the current view layer (eye)
  • Show/Hide in all view layers (screen)
  • Render/Don't Render in the current view layer (exclude)
  • Render Don't render in all view layers (camera)

@Dalai Felinto (dfelinto) This is a great overview on how the visibility options work but wouldn't my proposal of the 4 toggles not clearer?
I'm just wondering if we need a full wiki documentation to understand how visibility toggles work, is that the right way?

@William Reynish (billreynish) I have some questions about your proposal.

  • How can the user disable something from the viewport without it being disabled from the rendering? That is still an essential feature.

Why? To me this seems fundamentally confusing, to have two competing visibility states that only affect the viewport, whose difference is so subtle that most users will never understand it.

  • Is the checkmark disable toggle per view layer or global?

Could be either. The per-view layer thing is a marginal difference IMO. View Layers/Render Layers are an advanced feature that we obviously should support well, but not be an excuse to make using the Outliner normally a PITA.

Disabling something would disable it from the depsgraph, so I suppose it would have to be global? So in that sense it's really the same as the screen icon, but in a clearer way.

  • If it's global, disabling for rendering with the checkmark not just exactly the same as toggling the camera icon?

It would be an easier way for users to make sure the viewport and render visibility are in sync. Currently, it's a pain because you have to manually make sure you set the eye and the camera the same. With the above change, you can just use the enable/disable toggle to control both viewport and render visibility.

  • If it's per view layer, isn't it exactly like the exclusion? In that case we would still need to have something like the screen icon to disable an item globally for the viewport.

Having the visibility toggles in terms of functionality like this would be the clearest thing I could think of:

  • Show/Hide in the current view layer (eye)
  • Show/Hide in all view layers (screen)
  • Render/Don't Render in the current view layer (exclude)
  • Render Don't render in all view layers (camera)

I really think this is too much. For most users, they don't have multiple View Layers, and adding all this complexity for everybody, for a marginal advanced use-case seems like a poor compromise. I would rather try and find something that is more understandable, clear and simple.

@William Reynish (billreynish)

Why? To me this seems fundamentally confusing, to have two competing visibility states that only affect the viewport

It would be an easier way for users to make sure the viewport and render visibility are in sync.

I really think this is too much. For most users, they don't have multiple View Layers, and adding all this complexity for everybody, for a marginal advanced use-case seems like a poor compromise.

We need viewport and render visibility to be not the same thing.
And without per view layer visibility, view layers have no purpose anymore.
Without global visibility toggles, linking becomes a massive PITA.

Without some level of depth we cannot work anymore ...

Hang on, I think you misunderstand. I don't propose to get rid of eye or camera toggles for per-view layer visibility. As in the mockup above, you can see they are still present.

Here it should be clearer what I'm proposing:

I short, this is essentially merging the Exclude and Disabled states. They functionally very similar anyway.

  • Change screen icon to a checkmark toggle
  • Make it affect both viewport and render
  • Make the UI nicer
    • Greying out the entire line
    • A visual way to re-enable

This solves a number of problems:

  • Both the Exclude state and the Disable states are currently completely hidden
  • it's absolutely not clear which toggles only apply to the view layer and which toggles are global
  • The difference between the various states we have is so unclear that it's basically impossible to work out. The invisible vs disabled vs excluded states have completely non-obvious and subtle differences
  • The Exclude and Disabled states have no obvious visual ways to re-enable or re-include. How do you un-disable or un-exclude? You can't, in an obvious way.

@William Reynish (billreynish) I like the proposal but I think we still need to be careful how to implement it exactly. The current visibility system is at least usable in a lot of ways but when attempting to simplify the complexity we could lose important functionality.
When thinking longer about it, I can see one big issue with the proposal as an example:

When linking a collection/object, how does Blender know if the Eye or Camera is toggled off or on.
Since these 2 icons would be per view layer toggles, a collection/object could be seen as hidden in one view layer while shown in another. Because of this, would the icons be always toggled on when linked into another file instead of inheriting the setting?
In the current system they inherit the screen and camera icons since they are constants for the entire file. That system is predictable in terms of linking and very useful when creating assets that will be linked, animated, rendered, etc.
A lot of Spring production files depend on this feature.

And I wouldn't suggest that they instead inherit the state of the checkmark since this disables both viewport and render visibility. There should be the option to define how linked assets will be visible in the viewport and the render separately.

We chatted earlier about implementing an extra feature to this proposal to "lock" the eye icon and/or render icon. By implementing this the user can define collections/objects that they don't want to accidentally toggle by hitting Alt + H, by click & dragging over a row of items in the outliner or clicking on an eye icon while holding Shift (or even more cases). Since the eye & camera icons would be used for view layer management, this will be an important feature.

But maybe this "locking" could instead lock the visibility states of an object/collection for all view layers so that the state of the icon can be used when linking it?
This would be similar to how the screen and camera icons are used right now.
Another would be to split the checkmark into "disable for render" & "disable for viewport" and make those states be linked to other files ... but then we add more complexity back.

But all these solutions sounds like a slightly different way of how it works right now so I'm really not sure at this point how to fix this issue ...
Maybe you have an idea?

Ok how about this:

Because of linking we need 2 toggles that act global throughout the file and because of view layers we need at the very least 1 toggle that is per view layer.

So we could instead go for something like this:

So we essentially get rid of the screen icon and make the eye icon a global toggle without affecting the depsgraph when toggling it. Also this way both eye and camera icons are global.

In terms of usability there would be another useful toggle. This is the "lock feature I mentioned.
I'm finally going to give names to this theory since it's long to explain every time: A "soft" and a "hard" viewport visibility toggle.
Because of the potential increasing complexity, amount & nesting of collections there should be a "hard" toggle that is not easy to revert with Alt + H, click, drag & Shift click, etc like locking the eye icon.
And because of the need of general quick & easy hiding/showing of objects/collections there should be a "soft" visibility toggle like the eye icon.
Perhaps the exclusion could be this hard visibility toggle but exclusion changes from view layer to view layer and it affects both viewport and render visibility.
It's best if both the soft & hard toggle is global and closely tied together.

Since the "locking" feature is more of a corner case it can be put in the right click menu while keeping the main 3 toggles (eye, camera & excluding) front & center to keep everything clear and easy to understand.

@William Reynish (billreynish) I like the proposal but I think we still need to be careful how to implement it exactly. The current visibility system is at least usable in a lot of ways but when attempting to simplify the complexity we could lose important functionality.
When thinking longer about it, I can see one big issue with the proposal as an example:

When linking a collection/object, how does Blender know if the Eye or Camera is toggled off or on.
Since these 2 icons would be per view layer toggles, a collection/object could be seen as hidden in one view layer while shown in another. Because of this, would the icons be always toggled on when linked into another file instead of inheriting the setting?

The way I see it, the linked visibility issue is something different. It could be solved in a few ways, without needing the previous clumsy column of screen icons.

  • Ideally, we could make it so it the linked visibility is set in the scene you link TO, not FROM.
    • This gives added flexibility, for animators to turn on high-res meshes for playblasting
    • Would be conceptually much more simple and logical
  • We could set the linked visibility inside the Object > Collections panel

We chatted earlier about implementing an extra feature to this proposal to "lock" the eye icon and/or render icon. By implementing this the user can define collections/objects that they don't want to accidentally toggle by hitting Alt + H, by click & dragging over a row of items in the outliner or clicking on an eye icon while holding Shift (or even more cases). Since the eye & camera icons would be used for view layer management, this will be an important feature.

But maybe this "locking" could instead lock the visibility states of an object/collection for all view layers so that the state of the icon can be used when linking it?
This would be similar to how the screen and camera icons are used right now.
Another would be to split the checkmark into "disable for render" & "disable for viewport" and make those states be linked to other files ... but then we add more complexity back.

Then we start going down confusing territory again by having two toggles for each visibility type that nobody will understand how to use. It's not necessary to make it this complex. The difference between the old eye icon and screen icons are very academic and subtle. That was why nobody could figure out the difference.
We can get away with one toggle to completely enable or disable items, and the other sub-toggles to enable/disable in the viewport or render. That is a simple paradigm that is easy to grasp and communicate.

All this stuff with link visibility is a red herring. It's a marginal feature that could easily be solved without needing a whole row of confusing screen icons.

@Julien Kaspar (JulienKaspar): Posted at the same time :)

Yes, the visibility locking would be a way to prevent alt-H from showing everything. Although for most things like helper objects you could just disable them with the checkmark and they would stay off.

@William Reynish (billreynish)

  • Ideally, we could make it so it the linked visibility is set in the scene you link TO, not FROM

    ...
  • We could set the linked visibility inside the Object > Collections panel

The first option can be very useful either way but if it's the only way to define what it hidden for linked assets then it will be a big hassle to always set up the visibility again & again for every time the asset is being linked. The tree assets in Spring have dozens upon dozens of collections that are set to be always hidden in the viewport and equally as many that are set to be always hidden in the render.

The second option could leave to a confusing interface separated from the outliner. If this information should be accessible then it should be directly in the outliner.
I'm not really a fan of either option as a solution.

What do you think of making the eye icon global instead of the checkmark (excluding) ?
As far as I can see right now this could solve the issue with linking visibility.

Damnit ... in a lot of cases when keeping collections or objects always hidden in the viewport, either in the current file or for linking, is to hide high res geometry that will be used for rendering but is too taxing for the viewport performance. But since the eye icon doesn't improve performance, this becomes impossible.
With view layers and checkmark setups this can still be achieved in my version of the proposal but this setup couldn't be linked over to other files and needs to be set up every time.
Neither of these solutions with 3 toggles and locking can work for these cases.

In your version, setting up the eye icon for linking or within linked-to files would become meaningless for the same performance reasons but using the checkmark takes collections/objects out of both the viewport and rendering globally. So the user ends up with an always slow viewport or objects that are supposed to be rendered being always disabled for rendering.
So there absolutely needs to be an a global toggle to put an object/collection out of viewport calculations without hiding it in the rendering as well = The screen icon.

Maybe it is best to go for something similar to my previous proposal of having 4 toggles by splitting the checkmark in 2:

  • Toggle viewport visibility for current view layer (Eye, no performance changes)
  • Toggle render visibility for current view layer (Exclude, but only for render)
  • Toggle viewport visibility globally (Screen, improves performance)
  • Toggle render visibility globally (Camera)

So there are 2 toggles to make sure linking and viewport performance both work (global) and 2 toggles for view layer management and render setups (per view layer).
I really see this as the bare minimum for visibility toggles without outright breaking all production files for Spring and making certain use cases a lot harder for the user.

If the screen icon could be toggle-able on linked objects/collections then there's theoretically no need for something like excluding to affect the viewport since the user can always use the screen icon instead ... I hope.

This comment was removed by Albert (wevon).

I'm going full circle. The current way the visibility system works is the most functional for all cases. If we attempt to simplify, remove or merge any of the toggles we would need to make certain use cases still possible by introducing hidden features like locking, more options in object/collection tabs in the properties, leaving the user to do a lot more collection management & potentially more.

@Dalai Felinto (dfelinto) This is a great description of how and why the toggles work like they do.
The best we can do now is to make the tooltips and outliner interface communicate this in a better way than it does now. I don't even see an issue with copying these descriptions mostly word for word (at best a bit shorter) into the tooltips of each icon.
The measurement tool in the 3D View for example has a bigger & thorough tooltip as well and I love that one :D

Collection visibility control
=========================

  • Disable for viewports/render:
    • Affects all view layers.
    • Performance efficient.
    • Allow for a collection to be only in render or only in viewports.
    • Particularly useful for collection that will be instanced (e.g., hide highpoly in viewport, show highpoly in render).
  • Exclude (disable collection for both viewport and render):
    • Per view layer.
    • Performance efficient.
    • Highly recommended for animators.
  • Hide/show in viewports:
    • Per view layer.
    • Little impact in performance.
    • Quick temporary visibiliy control.

Object visibility control
=========================

  • Disable for viewports/render:
    • Affects all view layers.
    • Useful for support objects (never to be rendered).
    • Note: You can use this for objects that are to be instanced, to separate highpoly and low poly objects, that said you can/should use collections instead.
  • Hide/show in viewports:
    • Per view layer.
    • Quick temporary visibility state.
  • Local view:
    • Per viewport.
    • Even quicker temporary visibility state.

The current system 'works' but is very confusing if you factor in the Include/exclude and enable/disable states.

They way those states relate to the other features are and presented in the UI is so hidden and confusing that very few people will find them, and if they do, it's completely non-obvious how they work, and what their purposes are, as well as the complex ways in which the different states affect linked visibility.

I am adamant that there are ways to give the user all the same power, but in a less confusing way.

@William Reynish (billreynish)

They way those states relate to the other features are and presented in the UI is so hidden and confusing that very few people will find them, and if they do, it's completely non-obvious how they work,

Adding the checkmark for excluding, way better tooltips and greying out icons based on how they affect each other would help.

But if there is a better solution on how to change the system to a clear and uncomplicated one then I'm all for it. Our attempted solutions still have a lot of holes in them though.
I'll keep thinking about different ideas as well and if something comes to mind I'll share it, we can discuss and we can continue to try & find a better solution :)
Polishing the tooltips and interface for the system we got sounds somewhat good enough for now.

I'm a bit new to Blender but couldn't you just merge everything into the eye icon? Surely if you're disabling it from the viewport you would probably want to disable it from rendering as well? I don't see when you would need to do one or the other. I understand the disable collection from viewport selection but couldn't everything else could be merged into one?

@Ali (Ali6): That's why I proposed to promote the hidden exclude/disable toggle as a checkmark to disable visibility in both the viewport and render. In many many cases, disabling for both is exactly what you want - it's the WYSIWYG philosophy.

Only in rare edge-cases do you want things to only be visible in either the viewport or render only, but we've made this the main way to toggle visibility, which is confusing.

With the old layers, changing visibility would affect both the viewport and the render result. Now you have to remember to toggle both the eye and the camera icon all the time.

We can make this easier by using the exclude/disable checkbox

@William Reynish (billreynish)
I absolutely agree. The eye and checkmark/excluding should be front and center to make clear what should be used the most. Good tooltips can clear up any remaining confusion.

If the main icons/columns in the outliner are the checkmark (excluding) the eye and the render icon, then the screen icon can still be an alternative state for the eye icon if it shouldn't be taking up space or being always visible is to confusing for people.
But all these visibility states need to exist either way so why not keep them in the outliner for a good overview.

Another solution to keep the outliner clean and clear is my previous proposal of adding the visibility toggles to the filtering options instead of just "Show all restriction columns" ;)
If certain users don't care about disabling for render or disabling for viewport they can get rid of those columns to clear up space and only use the eye & checkmark.

This confused me a bit:

With the old layers, changing visibility would affect both the viewport and the render result. Now you have to remember to toggle both the eye and the camera icon all the time.
We can make this easier by using the exclude/disable checkbox

But that's how it works already ...
Just that it's not a checkbox in the interface yet.

this section could help to separate things a bit from the viewer / render

@carlos (c17vfx) It's an interesting proposal but this kind of menu would be a nightmare to manage.
Imagine having to click through potentially hundreds of collections and objects to change these settings. Keeping this in the outliner makes it very easy to manage.

I would oppose removing the ability to set renderabilty and viewport visibility independently.
It is one of the current strengths of Blender and one of the things I really like about it.
There are several cases where you want objects visible in the viewport but not renderable. Here are a few:

  • Guide or reference objects
  • Helpers and Images
  • Grids and empties
  • Snapping guides
  • Boolean volumes and operands
  • Shrinkwrap surfaces
  • Any objects set as Maximum draw type: Wireframe

And the opposite is also true, there are at times objects that should always be rendered, but are undesirable in the viewport.

  • Particle systems and heavy objects that slow down the viewport
  • Scene background objects and environments
  • Very large objects that go beyond viewport clipping limits
  • Uneditable linked libraries and objects

@Julien Kaspar (JulienKaspar): Yes, that was simply my point too. The checkmark makes the feature more obvious and clear.

@Duarte Farrajota Ramos (duarteframos) I don't think anyone is seriously proposing to get rid of viewport/render visibility. But it *is* strange as the main way to toggle items on or off. It was not the case in 2.79 and earlier. There, enabling or disabling layers would affect both the viewport and renderer. Viewport/render visibility was a secondary toggle.

In conclusion, I think a few things are becoming clear:

  • The Include/Exclude feature should be promoted via a checkbox, so that users can use it to easily enable or disable items in the Outliner, without worrying about viewport vs render visibility, which are secondary
    • This allows users to optionally hide the Restriction Columns to gain more space & simplify the Outliner.
  • We should add improved greying out to the visibility toggles. If you hide a parent collection via the eye or the camera toggles, the children toggles should be greyed out too.
    • Currently it's not always clear if the eye/camera will apply, because the parent collection overrides it

The screen icon toggle for linked visibility still seems like a weak solution, but we could keep it for now, as it doesn't interfere with most common use-cases. We could perhaps think about giving it a different icon, such as a link with a cross over it?

The above changes are actually just very small UI-level changes that don't require any underlying changes in behavior.

I have no read all of this task yet. But I think an important missing piece is improving the dependency graph so that hidden objects are never evaluated, while keeping toggling visibility fast. Users shouldn't have to worry about the distinction.

Once this works, it may be possible to eliminate one of the collection visibilities. Or leave exclude/include as purely a render layer setup setting.

Great. I largely agree with the updated task description here. To me this sounds like a nice list of small improvements to make the UI clearer for this.