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?
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 Names||New Names|
|Show/Hide||Viewport Visibility On/Off|
|Enable/Disable||Instance Visibility On/Off|
This leaves us with the following:
- 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:
- 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.