Visibility Toggles: Logic & Usability #61361
Labels
No Label
Priority
High
Priority
Low
Priority
Normal
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Content
Type
Design
Type
Report
Type
To Do
Type
Web Development
No Milestone
No project
No Assignees
12 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: studio/blender-studio#61361
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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 @dfelinto description of the current visibility system/toggles:
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.
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.
Open questions:
If I forgot to add anything or you have more feedback, let me know :)
Added subscriber: @JulienKaspar
Added subscribers: @WilliamReynish, @dfelinto, @brecht, @pablovazquez, @NachoConesa, @frameshift
Added subscriber: @SteffenD
Added subscriber: @DuarteRamos
The 'unlinked' viewport visibility ( blender/blender#61327 ) 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.
@WilliamReynish
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 blender/blender#61327 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)
@WilliamReynish
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:
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:
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:
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
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)
@DuarteRamos 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.
I hope to address this with the following. I believe it may be time to update our documentation on the different visibility settings (@pablovazquez maybe we could do a new illustrated blogpost?).
Meanwhile this is how I see the differences and their different uses (@brecht agree?)
Collection visibility control
Object visibility control
@WilliamReynish I have some questions about your proposal.
Having the visibility toggles in terms of functionality like this would be the clearest thing I could think of:
@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?
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.
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.
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.
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.
@WilliamReynish
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.
This solves a number of problems:
@WilliamReynish 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?
Added subscriber: @Xury46
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.
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.
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.
@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.
@WilliamReynish
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:
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.
Added subscriber: @wevon-2
This comment was removed by @wevon-2
Added subscriber: @jendrzych
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.
@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
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.
@WilliamReynish
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.
Added subscriber: @Ali6
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?
@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
@WilliamReynish
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:
But that's how it works already ...
Just that it's not a checkbox in the interface yet.
Added subscriber: @carlossifuentes
this section could help to separate things a bit from the viewer / render
@carlossifuentes 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:
And the opposite is also true, there are at times objects that should always be rendered, but are undesirable in the viewport.
Added subscriber: @0o00o0oo
@JulienKaspar: Yes, that was simply my point too. The checkmark makes the feature more obvious and clear.
@DuarteRamos 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 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.
Changed status from 'Open' to: 'Archived'
Archiving in favor of blender/blender#61578 (Outliner Visibility Update), which contains the latest version of the proposed design (to be further updated after discussion at homestretch workshop).