Page MenuHome

Outliner Visibility Update
Closed, ResolvedPublicTO DO

Authored By
William Reynish (billreynish)
Feb 15 2019, 2:33 PM
"Love" token, awarded by sebastian_k."Love" token, awarded by machieb."Love" token, awarded by MaferM."Love" token, awarded by DotBow."Love" token, awarded by AlphaVDP2."Love" token, awarded by plundh."Love" token, awarded by Shimoon."Like" token, awarded by 0o00o0oo."Party Time" token, awarded by DaPaulus."Yellow Medal" token, awarded by amonpaike."Love" token, awarded by JulienKaspar."Love" token, awarded by wo262.


Note: This topic is only about visibility toggling. The Outliner as a whole could use a lot of other improvements, but those are outside the scope of this task.

We have just concluded a UI-meeting in which we discussed the topic of the visibility states and how they relate to the Outliner in Blender 2.8. This task will attempt to communicate our conclusions.


We started by identifying the biggest current problems related to visibility states:

  • It’s still not clear enough when to use our various visibility states
    • (Show/Hide vs Enable/Disable vs Include/Exclude vs Local View)
  • Some useful toggles are too difficult to find
    • Namely how to set instanced visibility and how to include & exclude Collections)
  • It’s too much of a hassle to make sure the viewport visibility matches the render visibility.
    • Users who just use the eye toggle are surprised when they hit Render, and they see a totally different list of items.’
  • Some toggles affect the depsgraph performance and some not.
    • This is not clear, and should this even be the case?
Starting with the last issue related to the depsgraph: This can be solved in the depsgraph itself, so that using show/hide (eye icon) is as performant as when disabling(screen icon). It turns out this is not a fundamental problem, but simply something to be added to the depsgraph evaluation

The rest of the issues, we think we can solve them by making a few changes only on the UI layer:


Most of the issues can be solved simply by slightly changing the emphasis of which features we make more or less prominent for users. For example, the ability to completely enable or disable collections (include/exclude) is very generally useful. It’s akin to using the old layers in 2.7x and earlier, where toggling layers would affect both the viewport and the renderer. However, it's completely hidden behind the shortcuts E and Alt-E.

An opposite example would be the instanced visibility feature (Currently represented by the screen icon). This is a very obscure, advanced feature that is only applicable in in certain projects which make heavy use of linking.

We want to make sure Blender is clear and easy to use out of the box for simpler projects, while still including advanced features that more advanced users or complex projects.

Here’s what we would like to change:

  • Make the Include/Exclude state discoverable and obvious. Currently the only way to use this is via the hidden shortcuts E and Alt-E.
  • Add a more granular way to filter which restriction columns you see in the Outliner
    • By default, only show the most basic ones (probably Include/exclude (checkbox), selectability(cursor) and show/hide (eye)

In the Filter popover, we could add settings to enable each restriction column separately, like so:

Alternate, clearer popover UI:

By default, this is what we expect you will see in the Outliner:

The checkmarks (include/exclude) for enabling or disabling Collections completely. Selectability toggles and viewport toggles. This is all the vast majority of users will need to worry about.

However, you could enable all the restriction columns and get this:


A big part of what is confusing about the current system, is that the naming is unclear. Show/Hide only applies to the viewport, and the enabled/disabled states have to do with instancing, which is not communicated. Here are the name changes that should clarify what they do:

Old NamesNew Names
Show/HideViewport Visibility On/Off
Enable/DisableInstance Visibility On/Off

This leaves us with the following:

  • Enabled/Disabled
  • Selectable On/Off
  • Viewport Visibility On/Off
  • Render Visibility On/Off
  • Instance Visibility On/Off


To go with the above name clarifications, the icons should go along with those too. Here are some examples:
The only needed differences is the use of the checkmark for include/Exclude, and the link icon for instanced visibility:

Open questions:

  • Should we make it possible to Include & exclude items (check mark) on the object level too?
  • Instanced Visibility (previously Enable/Disable) currently affects both the instanced visibility, AND the local, non-instanced visibility too. This is actually a problem if you use it for its intended purpose, such as hiding an Armature in the instance but not in the source Collection. More appropriate would probably be to make it ONLY affect visibility in the instance, not the source.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

What's wrong with this?

As far as I know the gutter is generally reserved as place to start box select, if we start cluttering it in with new features it defeats its purposed

If the UI team deems this clear and self explanatory enough I would go with something along those lines. It is very compact, uses no additional space, and turns the otherwise mostly decorative icon into something functional

What's wrong with this?

Probably nothing wrong with it.

But for my brain it ends up looking odd with a straight vertical column of checkmarks, then a ragged tree (where it is the raggedness itself that tells the story), followed by a straight vertical column of visibility icons. The two straight columns on each side acting as bookends to the tree in middle make it hard to tell the relationships.

Or in a nutshell, the crap on the right that is not shown screws it all. LOL

I think we're overcomplicating the outliner for options that seem and feel far more advanced than what the common user will understand, I dont think they should be taken away they are all stuff i believe i would use one way or an other but in the outliner I would only keep one or two options visible as previously suggested like selectability and visibility, but I'd make visibility affect be for both viewport and render (by default).

Then under the object properties, I'd have a sort of "advanced panel" or "overrides" or something of sorts where you can find, disable / enable, renderable / non, (maybe something similar to the Cycles "ray visitibility" settings panel.

Also I would by default make that an invisible object, Isnt calculated nor rendered (because it's expected), but with the possibility of bringing this back, so you can turn the eye off but then override whether this will still be calculated, or rendered.

An other thing regarding this, when hiding a collection have it affect it's children but not turn off their eyes, it's really hard then to turn them back on if say you have only 3 on out of 10, because now blender has forgotten which ones were on and off inside that collection, have the collection be a master visibility that overrides whatever visibility of the objects inside it no matter if they're on or off that way as a user you dont end up having to manually go back and change the visibility for each one again.

that's my two cents, I also believe all these options shouldnt be shared by both collections and objects, I still dont exactly know which one should have em all and which one shouldnt, probably the collection only should have visibility and selectability and linkedability (?).

As a side note please make sure that turning off selectability doesnt turn selectability via the outliner, it makes no sense, the idea is that you turn of selectability so you dont screw up in the viewport, but in the outliner then it becomes a problem.

yes i think those are my two cents.

I think visibility and render should be visible all the time,
but we could toggle both of them with alt+click.

Moreover, we could inherit the status to the hierarchy by holding shift or ctrl.
So by holding shift+alt+click, I can hide the complete hierarchy for visibility and render.

Overall we should also consider a display-toggle for showing the "parent child" hierarchy in collections too.
It's really difficult to work with collections when one is used to group objects under other objects or emptys.
In this case, it is required to use two outliners at the same time to see what is happening.

I think, that visibility restriction icons need some improvement in the style department.
Proposals: LINK.

@Harley Acheson (harley) @Duarte Farrajota Ramos (duarteframos) @Andrzej Ambroz (jendrzych)

I updated the mockups in the original post with the checkmarks after the disclosure triangles. I think this is the nicest solution among the ones discussed.

The Collection icon-as-checkmark idea is neat but too inconsistent. Users expect to be able to click the icon without toggling it on or off.

@Luciano Muñoz Sessarego (looch) re. moving the toggles to the Properties:
We thought of this solution too. I wouldn't mind adding it there as well, but the reason we ended up with the solution described, is that in productions you'll often want to get an overview of many items at once. Inside the Properties, you'll only see the Properties for the active object or collection.

As for the the issue you describe with nested visibility, we have discussed a solution for it, which is: If you toggle visibility on a child item that is being toggled off by its parent, the parents should then be toggled back on. Otherwise users will have to manually make sure all parents are turned on.

It's on the (long!) list of improvements needed in the Outliner.

@Andrzej Ambroz (jendrzych) Thanks - these look great to me (the ones on the right).

For nested visibility, a third state could make objects globally visible,
even when parent objects or collections aren't visible.

There is a good solution to this in c4d, it's also color-coded,
red for invisible, green for globally visible and grey for neutral behavior(Visible but can be overridden by a parent)

Another thought, here exaggerated for effect. Rather than show the right-side icons as enabled or disabled, we could show them as regular or restricted. Give prominence to the states that are exceptional, rather than see a sea of bright icons indicating the normal state.

@Harley Acheson (harley)
Well, it's just a question what do You want to underline. A matter of preference I'd say - You may say the glass is half full or half empty, but both of the statements re true. Here we have similar situation. Current design makes enabled states strong, that's true, but most of software I work with does it this way. Lack of information is an information as well, so both states are noticeable and easy to identify. Moreover devs could colour code the states (green = ON / red = OFF, or so).
BTW - restriction icons have three states actually ON / OFF / INACTIVE (greyed out), but Your mockup doesn't take this into account. Moreover it uses badly designed Linked Visibility icons that make it kinda messy (weak difference between ON and OFF states).

I think we should discuss this in the icons thread on the devtalk forum.

@Andrzej Ambroz (jendrzych)

but most of software I work with does it this way

For sure. It was just a thought. While making the mockup I was trying to make sure that each side showed the same items restricted, and just doing that it was easy to miss some. I really have to scan the left side very carefully, while the right jumps out. Of course this is with old eyes that need reading glasses. LOL

ON / OFF / INACTIVE (greyed out), but Your mockup doesn't take this into account.

Yes, I couldn't find three states in the icon sheet so I just used the "On" version. And swapped the link one horizontally so it would work with my slash.

I think we should talk about this in the icons thread on the devtalk forum.

For sure. I got all excited and cross-posted. Any excuse to make a mock up. LOL

@Harley Acheson (harley)
I appreciate and enjoy Your contribution! It makes me move instead of resting on my laurels. I bet, that better icons (check out my latest proposal) will make it easier to distinguish ID states and spot the proper information.

@Andrzej Ambroz (jendrzych) @William Reynish (billreynish) Actually there may have to be 4 states. In the current outliner when a screen/cursor/camera icon is greyed out it means that it cannot be toggled because it is linked.
So there should be a representation for: On, Off, inactive (greyed out) & linked (cannot be toggled).
Using greyed out icons for 2 different states is probably an issue.
Maybe the linked state could have a slightly red circle behind it, similarly to how selected items get a white or orange circle behind them. Or the icon itself could be slightly red.
Do you have any ideas for a solution?

I probably don't understand the issue. But if something is in a state where it "cannot be toggled" shouldn't the toggle icons be completely hidden?

@Harley Acheson (harley) It's necessary to still be able to see if it is on, off and maybe even inactive. So I think a backdrop would be best because it doesn't change the style of the icon itself.

Oh I see. So it can be on, off, or inactive while ALSO being unchangeable. Yikes. I think I'll just back away slowly... LOL

At first glance, Harley's solution seems reasonable - turning off the opportunity to toggle, by hiding toggle icons.

@Andrzej Ambroz (jendrzych) I was waiting for the "... but when looking at the issue further" :D
Well if the icons are completely hidden when linked then the user would be blind to what state the toggles are in. The only way to find out in that case would be to load the file it is linked from.
But once Overrides get implemented it should be possible to override these states so an indication of what the state is is necessary.
If we would use a slightly red backdrop for linked toggles then the backdrop could change to cyan when overridden (I believe that is the planned color for overridden values/sliders/icons/etc) or yellow when keyed (if that feature returns) and purple when driven.

@Julien Kaspar (JulienKaspar)
Sorry - I didn't reload the browser and missed some responses.
I don't like the backdrop solution, since it's not elegant and will introduce unnecessary muddle in the space that already is overloaded with information.
In my opinion, dimming icons that are inactive or ineditable will be sufficient, because the effect for the end user will be identical - no possibility to change the state of the icon. The burden of information about whether the ID is linked should be transferred to the object's pictogram - I would try to change the color of the linked object's icon from warm yellow to light gray, as indication of the lack of editing.

I tried to back away... LOL.

Since we use changes of opacity in the icons themselves to help differentiate between on and off, it can be ambiguous to use lowered opacity for disabled (unchangeable) as well.

Is it a thought to manufacture a "disabled" state for the icons on demand? Old-school style by drawing it twice with an offset?

@Andrzej Ambroz (jendrzych)

In my opinion, dimming icons that are inactive or ineditable will be sufficient, because the effect for the end user will be identical - no possibility to change the state of the icon.

Fair enough.

I would try to change the color of the linked object's icon from warm yellow to light gray, as indication of the lack of editing.

But they already have an additional link icon next to their own icon. That is a much clearer indication that the object/collection is linked (although maybe a bit confusing once the link toggle on the right gets added).
Changing object color from orange to light grey sounds fine otherwise, but collection icons would then change from white to light grey, right? That is a lot more subtle than a link icon next to it.

nice, thanks mate!
i think you guys are doing a great job, keep it up!

I like this! The right design makes the icon usable and clear what to expect when selected or deselected. And yeah, saves UI space.

I hate to add more options here but in my opinion C4D has one of the best outliners of any DCC app. They use the traffic light icons as mentioned above which I great once you learn it :). I’m only here to say that green/red icon states are pretty unfair IF you resort to colours. Blue and Yellow are the safest pairing I believe unless you add a colour blind toggle in the preferences as well. Otherwise, personally I think I like where this is all going.

@Julien Kaspar (JulienKaspar)
Ha! Linked Objects have a link icon next to them indeed. Can't help feeling that all the stuff gets more and more crowded.

Love the quick availability and read of "enable/disable" in this suggestion, but where does the ability to use "set indirect only" come in? It would be strange if that was still hidden in a menu.

Additionally, I found it weird that "indirect" is currently only visible when you have Cycles picked as a renderer, even if it only takes effect there. Most of the time I use Eeevee as a preview while working, and then only switch to Cycles at the very end. It would be nice to adjust the "indirect" setting at any time.

@Andrei Nadin (AnadinX) Yes! I also think that this is the best way I have encountered in DDC apps so far.

Especially with ctrl and alt modifier, it's really easy to use.
Safes space, has a lot of functionality.

Additionally, the color makes the reading super easy.

In this case Alt + click toggles both at the same time
Ctrl + click inherits through the hierarchy.
Ctrl + Alt + click toggles all and also the hierarchy.
Super eazy.

In general, I think blender should copy more from other DDCs what is already good and enhance it from there even more. Like the c4d outliner, or at least use other DDCs more for inspiration. Maxon did the same, they took blenders node Editor as a model. (not talking from CyclesToC4D, I mean the new native node system in c4d) They copied almost every function I love blenders node editor for.

re. the render/viewport thing: That was also what the checkmark should solve - this applies to both the viewport and the render.
We can also just show the render visibility toggle by default, which will make the distinction clearer. Perhaps we should show check mark, viewport visibility and render visibility by default. Selectability and Instance visibility can then be hidden by default.

My point was that render vs. viewport visibility as a concept is problematic, that this is actually the wrong distinction to make. Showing the checkmark does not solve that problem.

The more I think about it, the Instanced Visibility toggle should not actually make something invisible, unless it's being instanced. In the common use-cases of boolean objects and armatures, you want to be able to select and manipulate them inside the source Collection, but not be visible when instanced.

I agree it's not ideal to have to toggle this every time you want to edit the original asset. But making this only affect instances means it can't be used anymore in other cases without instancing. When you are not making an asset to be instanced elsewhere but just locally in a file you still want to be able to hide objects in a more permanent way like this. Further, this is also the property that would be used for animation.

There could be an additional option but that makes the UI even more cluttered.

AlphaVDP2 added a subscriber: AlphaVDP2.

Regarding something I posed earlier, it looks like I could manufacture a "disabled" state for icons that works across different themes. It could just draw this way if uiBut has UI_BUT_DISABLED in flag. Is this worth pursuing?

What's wrong with this?

Looking nice, but there is infinite collections count with ifinite cout of insets.
Personally I would like to propose to duplicate it, in a dopesheet style.

do I gather from this thread that it is currently not possible to keyframe the render icon to affect the visibility of objects during animation, as we can do in 2.79? If it's not currently possible, is that likely the change? It's an extremely helpful and time-saving feature in my work.

@Jack Schaberg (JaySchay) I do agree that there are some things that need to be considered like keying/driving render and viewport visibility. Right now it's not possible for viewport visibility, which is a big issue.
@William Reynish (billreynish) @Brecht Van Lommel (brecht) @Dalai Felinto (dfelinto)
If the screen icon gets replaced by the instanced visibility then it needs to be possible to key/drive the eye icon, which means that the eye needs to become global instead of per viewlayer.
That's something to consider.

@Julien Kaspar (JulienKaspar) Agree with all. Adding to it, in my work, the ability to control keying of the camera/render visibility of an object is even more important than viewport visibility. Hopefully, both are something that can be addressed.

I too rely on viewport visibility for my rigs. Allowing me to use drivers to control from within the Armature things like outfits, hiding, showing different object parts

I don't think anyone has ever disputed the need for animating viewport visibility. No need to pile on - it is only a technical issue to do with the depsgraph, nothing to do with the UI or overall paradigm.

Ability to animate any kind of UI gives sence of power)
I think, that Visibility button binar paradigm is not designed for animation yet
(three states needed instead of two for this ability - non-animated, animated, animated, but not at current frame),
as far as outliner is hierarcial viewing/editing tool, so it have to be animation-independent in order to be in the TOP of hierarchy, to provide ability to view full of it.

Animating Outliner will place Animation of Outliner higher in hierarchy, than Outliner itself.
This will require to rewrite a lot, starting from depsgraph.
So it is a nice but laborious and time-consuming idea.

Or maybe not. I don't know why it was possible in 2.79

What if "visibility, excludility and rendereability" are by default just one button, so if the object is visible, is included, and rendereable, if the visibility is off, its excluded, not rendereable, not visible not even calculated in the depthsgraph, unless you want to have it invisible in the viewport but want it rendereable then you can override that "manually" I think it would be much simpler to use for starters and would make more sense.

My meeting notes from discussion at homestretch workshop. No decisions taken yet, a more concrete proposal that further changes the design in this task is to be worked out still.

Types of Settings

  • Viewport vs. render
  • Per-view layer local and per-datablock global (instances and linking)
  • Temporary for working or more permanent and rarely touched
  • Animateable and non-animatable
  • For beginners or more advanced use cases


  • Large number of visibility settings is hard to understand
  • Viewport and render visibility distinction is useful but also causes confusion for cases where new or experienced users do not care about the distinction. Ideally user would only have to worry about this in cases where they actually want there to be distinction instead of keeping both in sync.
  • It’s not clear which settings are per-viewlayer and which are global.
  • Instanced / linked visibility does not have a clear name.
  • When hiding the original object for duplicators, it’s not obvious that the right way to do it is to put them in a hidden collection.
  • Not obvious which visibility settings can be animated. Not all settings useful to animate currently can be animated.
  • Number keys do not obviously map to a collection hierarchy.
  • Debugging why an object is or is not visible is hard.
  • Not all hiding options improve performance.
  • No good solution for quick visibility toggling in the 3D viewport, popover not popular, want something more permanent to work fullscreen without outliner.
  • Holdout, indirect only not available as columns in outliner.
  • No way to view objects with final render visibility in the viewport.


  • Filter out advanced visibility columns by default, and add holdout and indirect only columns.
  • Filter out selectability column by default. Instead do it through right click menu or shortcut, and show icon indicating when objects are not selectable. Not so important for new users, and object type selectability in viewport often replaces this.
  • Change instanced and render visibility settings to two other settings: global visibility, and an enum with “both, viewport only, render only". The global visibility would be an icon column that is visible by default. The latter two states would not have a column, but if viewport only or render only is set there would be an icon indicating that state.
  • Try to separate per-viewlayer and per-datablock settings visually somehow.
  • Put 3D viewport panel with collections in sidebar instead of header popover, make usable enough so animators can hide outliner.

@Luciano Muñoz Sessarego (looch), we discussed something like this, see notes above.

@Luciano Muñoz Sessarego (looch), we discussed something like this, see notes above.

yeah i just noticed, i think i posted that just before you did ?, very nice, I'm excited! great job and good luck with the homestretch!

Debugging why an object is or is not visible is hard.

I remember Revit hint about "Why object is hidden", with the instruction to search in 9 different places in program (visibility states, sections, classic hiding, structural class hiding, building state, building variations, etc.)
Yep, that was time consuming)

i would personaly keep it very simple for ech option just make icon and that is all.. very easy to use and check. also would be nice if there would be option to just filter thru those.

Also - important - fuction to inverse visibility is needed.
That will split scene into two global "slots" (visible vs invisible) with ability to switch between them.

Maybe Alt+Ctrl click on any eye sign in outliner.
That will give full fast control over hidden objects in entire scene.

  • It’s too much of a hassle to make sure the viewport visibility matches the render visibility.

The same switch can be made between render visibility and viewport visibility, to view what actually will be rendered as visible objects, control it with visibility switch from picture, and then switch back.
This way visibility can be the map for displaying different unobvious properties like render visibility.
Can be the solution for an issue.

We made such switch system for AutoCAD, and it is nice if it properly marked, we have full control over visibility and plottable state of thousands of layers.
We can switch in, edit plottability as visibility, and switch back.

In the Eisenhower matrix, this is how the switch looks like.

Not by inverse, but the same purpose in Revit:

Part of the issue for me is that we don't do a good job of indicating the relationship between collection restrictions and object restrictions. It is difficult to tell the story of why there are multiple levels and which one takes precedence.

For example, take a look at the object "Schrodinger" below. It is not visible on the left because its local "visibility" is turned off, despite the parent collection visibility turned on. Therefore you might conclude that the object setting overrides the parent setting.

However, on the right it is still invisible despite the local setting. So the parent setting is more important in this case, but not in the other.

One idea to make that relationship more clear and remove some of the visual confusion of having a million icons in rows. Give the collection restrictions a third state:

So by default we only show restriction icons on the collections, and therefore allow those to control the children. As shown on the left it becomes clear that collection icons are controlling everything in a very big and simple way.

But the collection's "eye" goes from on, to off, and then to looking disabled. At that point we show all the children's restriction icons as shown on the right. These two captures seem to tell the story for me in a straightforward way and with minimum clutter. It is obvious in both why Schrodinger is invisible. And this requires minimal changes in how this all works under the hood, mostly to how it is shown to users.

Here is an example of swap/invert modes

First button inverts visibility state
Second - swaps visibility and renderability

Object visibility can be inverted or swapped, that gives ability to view/edit rendederability of objects as visibility.
Personally, I would like to prefer columns switching, to define mode
(declaring first column for changing value by visibility when swapping columns), that will make things more clean.
But it is already useful concept.

Update with icons, (instead of possible columns changing) that depicts current mode.
Allow to recognize what mode of visibility is currently on.

Here on GIF I making column of unrenderable objects and row of invisible objects, controlling their states as visibility with 2 buttons, having full control over their states.

Super great improvement! Thanks for your hard work!

About the check boxes for collections, I think the idea of this has been that it works like the arrange in boxes for view layers that we have in 2.79 at bottom. What I do not understand is why when you disable a collection the content disappears from outliner. I imagine that for better organization you will always want to see the content of the collections even though it is disabled. I’m not sure if grayed out the content can be confused with disabling viewport view, but perhaps there should be another way to indicate that it is disabled but without the elements disappear from outliner (strikethrough text, color change, a mark, etc). Or perhaps none of the buttons on the right should grayed out the collection/content, and reserve grayed out text only for disabled/unchecked collections and its content.

What I do not understand is why when you disable a collection the content disappears from outliner. I imagine that for better organization you will always want to see the content of the collections even though it is disabled.

Or it can be separate mode, that depends on orkflow demand with outliner visibility control.

Dalai Felinto (dfelinto) changed the task status from Unknown Status to Resolved.May 15 2019, 12:09 AM

Implemented on b1af6820015, with updates in subsequent commits (5f84e2d732c, 9b80318a284, 903041e1c0e, 777a546c0c7).