Page MenuHome

Outliner Visibility Update
Open, NormalPublic

Tokens
"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.
Assigned To
None
Authored By

Description

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.

Issues

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:

Emphasis

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:

Naming

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
Include/ExcludeEnable/Disable

This leaves us with the following:

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

Icons

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.

Details

Type
Design

Event Timeline

Instance visibility UI

If we hide instance and render visibility by default, I think we should still communicate to the users when these settings are off. When instance visibility is off we can replace the viewport visibility icon as we do already.

I'm not sure that should be a read-only thing or if alt+click should be kept (might as well?). For instancing the instance visibility is still an important setting, and it's not that advanced a use case. So hiding it entirely by default is not ideal.

At least it should be clear that toggling the viewport visibility is not possible in that case.

Render/viewport visibility distinction

The main thing that bothers me still is render visibility. The distinction between viewport and render is a common source of confusion for users. It doesn't work well in a workflow where you do a lot of viewport rendering and then do F12 at the end, only to get a different result. Currently I'm thinking we can make instance visibility affect both viewport and render.

Render visibility could remain as an object only (not collection) option, equivalent to disabling all Cycles ray visibility options and available in the same place in the properties editor. This option would affect both Cycles/Eevee viewport and final renders, but not workbench. That render visibility would be for helper objects that are never useful in renders, like physics or rigging helper objects. Basically to make a mesh have visibility like a lattice or armature.

One use case that current render/viewport visibility distinction can serve is level of detail, to have a low and high poly version of a mesh. Maybe for faster animation playback, or to do layout with a low poly version or even bounding boxes. I suspect the right distinction there is not between viewport and final render however. But rather between workbench/rendered display mode and different view layers. With simplify settings, bounds/wire display for workbench and per-view layer collection exclude I think level of detail distinction between viewport and final render are already covered.

I would add to it an option to hide the disabled collections in the filter.
I second what @Brecht Van Lommel (brecht) said, we need a way to tell that a collection (and object?) is not rendered since this is a big deal.

Should we make it possible to Include & exclude items (check mark) on the object level too?

I would say, no. The least options we have per object the better I think.

@Brecht Van Lommel (brecht)

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.

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

@Dalai Felinto (dfelinto)

I would say, no. The least options we have per object the better I think.

I agree. We don't really need exclusion for objects so I think it can stay this way. Also if the eye improves the performance then there is really no need to add the checkmark for objects.

@William Reynish (billreynish) @Brecht Van Lommel (brecht)

I really like the idea to make the screen icon a kinda "instanced viewport visibility" toggle. It makes it clear what it's supposed to be used for. While thinking longer about it I have some questions/concerns though:

  • Currently in Blender the screen icon (disable for viewport) & the camera icon (disable for render) are counterparts because they work very similarly (global & used for linking/instancing). If the eye & camera are supposed to be counterparts in this proposal then won't their different behaviour make things confusing? The eye is per view layer and is not used for linking to other files & instancing ... but the camera is.

The more I think about it, the Instanced Visibility toggle should not actually make something invisible, unless it's being instanced.

  • I was thinking a lot over this one. There will need to be some restructuring of the Spring production files but only because a lot of the setups we use become a bit redundant. I think this might change things for the better.

In the asset files for Spring, this is a common setup right now (not the actual naming conventions):

We often keep the collections that we work on and the collections that we link/instance to other files separate. There are specific collections that we set to be disabled for the viewport or disabled for the render and we link the appropriate collections within them.
This way if you want to see how the asset will look when linked you can make the "Asset (for linking/instancing) visible and when you want to see or render the disabled collections you can make the "Asset (for working) visible.

If the screen is not overriding the eye icon anymore then it could become something more like this:

The only concern I have left about this change is the WYSIWYG. It's easy to know what will be disabled for the viewport when you already can't see it anymore.

  • I think the link icon for "instanced visibility" is a bit confusing. What this icon tells me at a first glance is: "This object/collection won't be linked", instead of "This object/collection won't be visible in the viewport when used for instancing". The name "instanced visibility" at least implies the use for instancing but it doesn't specify that it will only hide things for the viewport and not the render. But this is more of a minor concern. Naming it something like "Instanced Viewport Visibility" might be long but more accurate. Good tooltips could also lift some confusion. I also don't know of a better icon so the link could be the best choice right now.


Because all the options of the collections are transferred to the objects inside, I suggest contrasting them with respect to the rest of the objects, and indicating their effect on their contents.
I guess the video is sufficiently explanatory. Although it is only a visual effect, I understand that it helps to understand the hierarchy of effects.

@Albert (wevon) Yes, we should do proper greying out for all the toggles to help communicate the hierarchy. There are so many little details like this we should add.

I like the way this is going.

One big problem for most of the users is the "Unlink" collection/object from the Scene. It is like delleting it without a warning. You don't now to where it goes when unlinked, unless you have a deep understanding of Blender's data structure (most don't).

Unlink and Exclude are confusiong concepts too. I would prefere they are the same thing. I would prefere that an unlinked item from a Scene just shows in Outliner as Diseble.

If it is not possible, I would show a warning when a user tries to Unlink an item, like: "You are about to unlink this from the Scene. Are you shure?". Or a simple one, like when you are about to Delete.

As a nitpic, I really don't like the way that the tree reads when you place the disabling checkmarks to the left of the branch arrows, as it muddles the visual relationships a bit. It would have to be thought through but I think you can get a more logical read by, in essence, making the checkmark the collection parent as far as the list is concerned.

Hard to explain in words. The following image shows your earlier example on the left and a quick reshuffling on the right. I find the left side inscrutable and the right side readable.

Agree, a lot more readable. Additionally with your proposed layout we gain collection icons aligned with child objects which also looks tidier and easier to follow.

If we could somehow combine the checkbox with the collection icon design such that the icon itself could alone clearly and unequivocally communicate the enabled/disabled state we could even ditch the checkbox altogether.

we gain collection icons aligned with child objects

That's technically a fault of my idea, in that the children icons are aligned with the icon of the parent. But they are still visually below the checkmark so it seems okay to me.

What I mostly like is that it looks we have "branches that can be disabled", which is actually what we are looking for I think.

Just a bit more tidying to that quick mockup to make it a bit more consistent and clearer.

@Harley Acheson (harley)
Your proposal looks tidier, but it loses the Collection's enabled/disabled state at-a-glance readability in my eyes. I'd put all the checkmark icons in the straight vertical collumn on the left - just like the rest of the visibility restriction icons are organized on the right side of he Outliner. This way the relations tree won't be messed with visually strong checkmarks.

I'd put all the checkmark icons in the straight vertical collumn on the left

I tried that, but couldn't make it look okay.

Another simpler thought that keeps the relationships a bit tighter. But might be a bit too whimsical...


What's wrong with this?


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.