Collections, objects visibility and local view #57857
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
23 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#57857
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?
In Blender, we have various levels of visibility. We already have a toggle for viewport visibility per view layer {F5575043, size=full}
We then have a layer on top, which is the Hidden toggle:
{F5575075, size=full}
This is already quite confusing. Even though there is a difference between them that users can learn, in practice it's simply not clear enough which one to use when.
Next, the question is, how to handle the
/ keyLocal View feature, as well as per viewport visibility? How can we add these features without adding even more layers of visibility and complexity?Proposal
/we control localview, like in 2.79a.For now we don't change the way per-object visibility is handled. So outliner still shows them, and users can use
H,Alt + Hto control them.Viewport visibility UI
Currently, we have two popovers to control viewport visibility:
{F5585664, size=full}
We can optimize this UI by combining them into one popover, as we do in other editors. Our 3D View header is getting very crowded, and there's no need for two separate ones, and we already have the Outliner visible by default to organize scenes.
Inside, we should mirror the same order and layout as the Outliner. Otherwise, users will have no way of relating to the hierarchy of Collections.
The section in the bottom allows users to disable visibility or selectability per object type:
The hierarchy here is communicated just like hierarchy in the Properties Editor, using background darkness as opposed to indentation. This allows us to see many levels deep without requiring a wide panel to fit all the indentations.
The numbers refer to the shortcut keys one can hit from 1-9 to solo top level Collections.
The filled vs empty Collections show you which Collections are empty.
The yellow highlighted Collections are the ones with the selected items inside it.
Added subscribers: @dfelinto, @WilliamReynish, @pablovazquez, @brecht
This all sounds good to me.
@dfelinto and I discussed various option on IRC on how best to add local view (/ key) and per-viewport visibility in a way that doesn't add even more complexity, and this seemed like probably the simplest way.
Part of this idea is that
/ keylocal view actually sets the same visibility flag asH/alt-H.Added subscriber: @augustina12345
Added subscriber: @machieb
The local view (isolate selected) feature is very important!
Please make the visibility/local view setting as it is useful! When you have lots of geometry in the scene you often need to just focus on one object.
Make it at least like in Blender 2.79 where hitting the / key sets the object to local view, when you hit the / key you get out of local view. Objects that were hidden in the viewport remain hidden.
In the moment in blender 2.80 you have to unhide everything (alt h) to get out of local view, which ruins the scene configuration.
In my opinion local view should be independent from all the viewport/viewlayer visibilities! Its only a way to isolate one object to concentrate on.
In very large scenes with 10000+objects we often have the case that we have to hide many objects. Is there a way to find these hidden objects again, without unhiding everything? In the outliner there is sadly no filter for hidden objects, only visible objects.
@machieb, when you disable objects or collections for the viewport in the outliner (the screen icon), they are not unhidden on Alt+H. Not saying this is exactly what you are asking for, but there is a mechanism to hide objects more permanently.
@brecht, thanks for your advice. Will the screen icon in the outliner be available if the proposal in this thread is realized? Would it be hard to implement a search option for hidden/invisible objects in the outliner. In the moment there are only search options for visible, all, active and selected objects?
@machieb yes, the screen icon will be available. Indeed it is the first point of this proposal: "1. In the outliner we only keep the screen and render visibility option (...)"
@dfelinto, thanks for you answer, I trust your proposal to be useful in every days work. Thanks for you your hard work! Can you implement the search option for hidden/invisible objects in the outliner, or is it a paper cut? In the moment there are only search options for visible, all, active and selected objects.
One thing that I'm not sure is the
/ keybehaviour. My suggestion would be to not work as a toggle, instead to simply work as a contrivedCtrl+Ifollowed byH. Otherwise what will be the difference betweenAlt+Hand the second time you press the/ key?If the / key would work as a toogle wouldn´t it be more effective in case of performance? I don´t know how blender is handling this. Doing an inverse selection operation followed by a hide operation sounds compute intensive, if you have lots of objects in the scene. I work in the automobile industrie where I have 10000+ geometries in blender. In my opinion local view should be with good performance.
@dfelinto, I guess the difference would be in resetting the view matrix, which is part of local view. We could also make it so
/only changes visibility for the current viewport, and H/Shift+H/Alt+H do it for all viewports.Sounds good, maybe you can then add a button somewhere in the viewport for new users (like the aktive camera icon in the top right)?!
@dfelinto: As I understand the prosal, the visibility of objects in viewlayers would then be controlled by the set exclude/dynamic override of collections?
After reading the proposal carfully I now have some questions.
"1. In the outliner we only keep the screen and render visibility option (hide_render, hide_viewport)."
Will there be a shortcut for disabling objects (screen icon in the outliner) in the viewport, because in the moment as I know there is no such shortcut?
As I understand, the visibility switch (screen icon) in the outliner is for all viewports?!
In the outliner, there is then no way to see, if objects are hidden per viewport.
Then it would be very important to have at least a viewmode per viewport, to see all its hidden objects, where you can select and unhide them independently.
There are lots of 3D programs out there, having this "Show Hidden" viewmode, showing all hidden objects, which is very usefull!
This "Show Hidden" viewmode could be activated by an icon on the top of the viewport next to collection visibility.
There could also be other usefull viewmodes like:
Show visible
Show hidden
Show selected
Show Unselected
Show all
Added subscriber: @jendrzych
@WilliamReynish You were faster than me - I was about to write a similar proposal (combining the Collection and Object visibility popovers)...
Anyway it's nice to be able to hide all items with exception for the one which name was clicked. Brilliant, but there’s no easy and similar way to unhide all, except the key shortcut. User has to close the popover to use the key shortcut, which is a pain in... You know where. Maybe a double click or aclick + a key modifier could be used to bring back previous visibility pattern? Not simple unhide all, but restore previous set of hidden and visible Collections/Objects. Or simple Ctrl+Z would do the job?
Added subscriber: @JulienKaspar
@brecht
I agree. This would make the local view feature different enough from the normal hiding and very useful on it's own, just like in 2.79.
@WilliamReynish
In the beginning of the Task you wrote while showing the screen icon:
Just a correction here: That is actually not true. The screen icon is for a viewport visibility across the entire file and when being linked to other files. Excluding and Including is used for view layer specific visibility for both the viewport and render.
But the eye icon is also used per view layer.
@WilliamReynish, you ok with
We could also make it so / only changes visibility for the current viewport, and H/Shift+H/Alt+H do it for all viewports.?This would still give an extra level of visibility. Not literally as Julien have pointed out, but the mental model of it.
Either way, in terms of implementation I will go like this:
Since local view is the last thing technically, we have some more time to discuss it thoroughly.
@dfelinto: Yes that sounds reasonable overall I think. It’s just that it should be clear which features apply to the current viewport and which apply to all viewports.
I take that having per-viewport collection visibility is unanimous, good.
As for H/Shift+H/Alt+H changing all viewports ... would it be per view-layer then? Just like we have now?
As they are called viewlayer now, maybe you wish some sort of visibility per viewlayer?! Otherwise it woulf only be a renderlayer as in Blender 2.79.
@machieb there are viewlayers because the concept of render itself is confusing when it comes to realtime rendering. If you have a different view layer to show a subset of objects you want to work with the workbench engine, do you call it render?
@dfelinto, Isn't it the concept of viewlayers to show diffrent subsets of object? So you can deflect what will be renfered from what you see in the viewport. So I think the visibility which is changing all viewports, should be per viewlayer.
But maybe it becomes too complex, if you have visibility per viewport and visibility per viewlayer? And you also have the Collection viewlayer exclude/include option.
To make it less complex, maybe you only want to allow to exclude/include etc. collections in viewlayers?!
Added subscriber: @DuarteRamos
Added subscriber: @sozap
It's going in the right direction ! sounds much simpler now !
That looked like a quite handy feature to me. When working on a team , layout artist tends to have all objects selectable , when going to animation , animators tends to make everything unselectable except armatures. And when it goes to rendering, people often re-enable the selectability.
Having a dedicated workspace for each one where layout and render artists have all selectable, and animator only armature , could have been a great use of 2.8 features. But indeed this can be solved with a custom script :/
Maybe the popover can have two colums, one for collections and one for visibility and selectability ?
Also, something that I miss from 2.79 that is related to visibility, is when working with dupli-group you could have hidden layers on the group . So the rig, lattices, meshdeform where always hidden in the shots, but in the original file you could display whatever you need without messing something.
Now there is the viewport visibility that replace this feature, but if I want to tweak the rig, I need to switch viewport visibility on objects that I need (rig, lattices) do the tweak, and finally re-switch visibility when leaving the file.
It's not a big issue but as this whole operation can be done several times a day, there will be mistakes...
I don't know how to adress that in a simple way, maybe having some extra visibility option when a collection is intended to be instanced ?
I've tried to override the visibility of some objects inside dupli when opening a shot (with python) , but that doesn't seems to work ...
I have nothing particular against the per object visibility, other than it seems like feature-creep to me, when we already have several ways to sets electability in the Outliner. I'll leave it up to @brecht and @dfelinto.
Added subscriber: @Rawalanche
I am a bit confused as to why do we now have two places in close proximity to do the same thing?
@Rawalanche: If you read the proposal, this is about exactly that - changing that to make it more sensible so they are not the same. The thing in the viewport would then set the visibility in that viewport, and remove the eye icon in the Outliner which is redundant anyway.
If possible I'd rather keep per object type selectability in the popover, instead of per object type visibility, if only one can be kept.
Reasoning is that we already have lots of ways to control visibility, but selectability can only be set from the outliner.
Certain object types do get in the way in complex scenes some times, like lights, or you may only want to set active cameras without risking changing the scene, or move only armatures without selecting meshes.
Added subscriber: @Regnas
This is a regression imo. This is very useful.
Added subscriber: @Znio.G
i think removing “hide toggle” is fine as it has hotkeys for it (H,Alt+H…etc) this make outliner cleaner , but restrict selection per object should be kept, as there is no other way to do it, and object type/collection popovers are nice especially if you work in full screen mode, u can move objects to collections with 'M', maybe make all these in one instead of the popover,so u won't need the outliner in full-screen.
Ah, yes, sorry. Indeed I have not read the proposal, just skimmed over the pictures. I think it makes sense. At the same time it's kinda difficult to imagine there no longer being any central place that defines object visibility properties. For example, when creating a new viewport, if I wanted my collection visibilities to remain the same, would I have to re-setup them all over again? What if I wanted my collection visibilities to be in sync in multiple viewports?
For example when doing scene assembly, I often have one viewport that's camera, and other one from top view for better placement. I'd expect my visibilities to be in sync in both.
Added subscriber: @zeauro
In one of his videos, Pitiwazou showed visibility/selectability popover and explained that he wanted to be able to make a Ctrl click on one type to disable all the others.
He was talking about doing one Ctrl click on light selectability icon to disable all other object types. That way, he could manage lighting of his scene very quickly.
That will be interesting to add that to this new popover.
Initial local view support: D3973.
Not sure if this is technically feasible, or even desirable, since we don't have multi-state buttons anywhere else in Blender.
We could save a lot of space in the collections popover if we combined the visibility and selectability buttons into a single multi-state toggle.
Since selectable invisible objects don't seem to make much sense, it could toggle between three states Disabled > Visible > Selectable,
One possible issue with this is making click-drag behavior predictable. Maybe the state of the first button you click is propagated to others(?).
See animated mockups bellow
Regardless of this proposal has already suggested here,
Ctrl+Clickon one of the icons would ideally disable all others, making it a quick way to invert state. For multi state multipleCtrl+Clickwould toggle all others in sync.Bonus points if this also worked in the outliner, for example
Ctrl-clicking the visibility icon of a collection would isolate it, om the selection icon it would make all others unselectable.Added subscriber: @frameshift
This comment was removed by @frameshift
@dfelinto We're all very confused and helpless at the studio to be honest :D
The changes that we're commited made it much harder to use the hiding functionality in Blender and as far as I can see the way the proposal is described does not line up with how it works right now or how I can see it working in the future.
Hiding objects is not a per viewport function so why is the mini outliner still in every viewport? How will per object hiding now work when you can effectively only hide and show collections in the outliner? Is there going to be an additional shortcut introduced to unhide the selection to bring back some functionality that is missing now?
As far as I can see this feature seems half baked and very confusing and does not improve the hiding workflow in the current commits to Blender 2.8.
I would personally like to see this be a separate branch for the time until it's more complete and usable.
@JulienKaspar: Can you not use the viewport toggle (screen icon) to toggle visibility?
The problem we had, was that we were getting countless of reports about the eye vs the screen toggles. Nobody could figure out what to use when.
The idea here is that to set visibility normally in the Outliner, you use the viewport toggle, which toggles items in all viewports.
In each viewport you can also use the H-key, which toggles each item independently for each viewport. This is good for temporarily hiding things, like the local view.
We could have a shortcut also to toggle viewport visibility (screen icon)
@WilliamReynish
Usually we don't use the screen icon because it affect the entire file and the files that it's linked to. When we toggle the viewport visibility (screen icon) we want it to stay that way. It's more rigid like the render visibility, which is the advantage of this way of hiding.
Using it for frequent hiding and unhiding is slower than the H shortcut and eye as well.
The eye icon visibility is not per viewport, at least for now. But I also don't think it should be to be honest.
It's useful as a fast and frequent way of hiding objects but also with the option to quickly toggle them individually on/off in the outliner if needed. It's much more flexible, frequent and easily reversible when unhiding all.
Local view on the other hand is a much more temporary way of hiding. It's more restrictive but also way simpler. It's also per viewport, which gives it extra distinction between the other visibility options.
The object / collection hiding should not become per-viewport, at least not without an option like 2.7 to lock/unlock things. The collection hiding is intended to only affect 3D viewports, and be quickly switchable similar to the old layer buttons in the header. So these changes were intended to bring us closer to that again.
As far as I can tell the underlying hiding logic is something we can agree on. The contentious issue is the user interface, do we show the eye icon in the outliner or not? Can we make it more clear to users somehow? Should it be an outliner option?
Added subscriber: @thornydre
As Julien said, the "screen icon" is not used that often, so maybe it could but in the right click menu only, an not in directly in the outliner, it would make the outliner a bit clearer as well, and it would avoid missclicking on it, and having this object disappear in all the linked files :/
I can think of a few alternative solutions:
Basically, I could go either way - the main issue was that we had two toggles that did almost the same thing, and nobody could figure out what to do. Either we should promote the use of the hide/unhide toggle (eye), or the viewport on/off toggle (screen).
Added subscriber: @eyecandy
I agree having two hiding options in the outliner is in fact confusing. however, I really miss the eye icon hiding per object (as opposed to H/ALT+H/SHIFT+H) because it was a very quick and powerful way of isolating a bunch of objects quickly, add or remove objects to that isolation on the go, then jump back to it's default state with ALT+H. In the studio we treat the screen icon hiding as a more permanent way, since it does transfer to linked subcollections.
I'm really in favor of bringing this behavior back. maybe not via the outliner, maybe there should be a way to access a list of objects/outliner per 3d view. Currently the 'collection visibility' popover is highly confusing in its sorting though, and adding objects to it would bloat it to the point of unusability.
Added subscriber: @ThinkingPolygons
Please bring it back.
This is literally the most used and useful feature of any outliner. I can't even imagine an outliner without it.
I am just adding my vote that I also find Screen and Eye icons in the outliner confusing. I did not yet bring myself to look up and figure how it works. I did not understand it but with a few test clicks, I noticed that the screen icon appears to be a superset of the eye icon, so I just adapted the habit of always using the screen icon, as it does what I need it to do.
That being said, I really don't think that Outliner visibility toggle should be something user needs to study and figure out. It's a nobrainer in other 3D packages :)
@eyecandy What if there was only the eye toggle in the Outliner, and then the screen icon toggle is something you can do elsewhere, or simply a section you can enable if you are working with linked files?
This way users will just use the eye toggle normally in normal scenes, and then if you want special visibility for linked objects you can set that in a more deliberate way.
@Rawalanche: Yes this was the issue - the differences between eye and screen toggles were/are too obscure. Most users will never figure out the difference. So we thought, we could just have one in the Outliner, so users just use one of them.
Just like in Edit Mode, where H key hides vertices without an eye icon in the Outliner, there's some sense in doing the same for objects too.
But, one could also do the opposite - only have the eye in the Outliner, and then make the viewport toggle more hidden for specialized cases such as controlling visibility in linked files.
Added subscriber: @Rusculleda
How about a toggle to show/hide the viewport visibility column in the outliner? Similar to the after effects toggles for showing/hidding blend modes columns and others. Hidden by default.
Are this features of the above proposal still coming??
That would be a good idea! Not everyone uses linked objects.
Yep, I am fine with just the one in outliner, and other one being somewhere else :)
I strongly believe the eye icon should remain in the outliner for all objects, ideally along viewport visibility functionality.
This seems to be just a matter of miscommunication.
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 Freezingor Locking and generally as a snowflake glyph {F5745887, layout=inline, size=full} for icon.
If we make this slight cosmetic change and replace the current "monitor" icon with some other clearer glyph, I believe it will go a long way to solve most issues and misunderstandings.
If we do end up keeping only one type of visibility in the outliner, which I feel is a step back, I believe the eye glyph should be the one used regardless of what it does, for clarity sake.
One thing is the icon itself (the glyph) the other is the functional difference between hiding/unhiding (H/alt-H) and viewport visibility (affects linked assets) and how to control those things.
This could work. as long as there is an easy way of figuring out the visibility/renderability of an object at first glance. E.g. you don't want to hide something and then inexplicably have it turn up in renders without giving the user feedback to its cause... this could lead to more confusion.
I know our animators exclusively use the Screen icon because it excludes hidden rigs to be evaluated (makes things faster).
@WilliamReynish
I have a proposal that kind of builds on this idea:
So what if we merge the eye and screen icon in a way that you can "lock" the eye icon to be hidden.
So you can still easily hide and unhide objetcs via the outliner and if you want the visibility to be fixed as hidden you will be able to for example Ctrl click the eye icon and it adds a lock icon to the corner of a closed eye (or even just a lock icon?).
This way the visibility of this item is no longer affected by H, Alt + H and Shift + H.
For this to be obvious maybe the Tooltip when hovering over the eye icon can explain that you can use Ctrl for this purpose.
There are some problems that I can see though when merging the icons since they did have different behaviours. As far as I can tell they were:
So how wold we address those when merging the 2 icons? My suggestions would be
Yes, I meant the glyph, I apologize, I lacked the proper lingo. Edited comment above for clarity.
Viewport visibility is functionally often called freezing {F5745887, layout=inline, size=full} , users coming from other software would probably recognize it a lot better with a different glyph.
@JulienKaspar Yes that could be one way to go, something like that maybe. I will leave it to @brecht and @dfelinto to think about.
The terms "freezing" and "locking" would make it more obvious what the visibility option is for.
I can also see the option be available through the RMB menu but we could enable both. Maybe the option in the RMB menu can show a shortcut like the exclusion does?
Maybe "locking" can be done via hitting "L" on selected items?
I will bring back the eye icon in the outliner, so Spring artists and other users can continue working.
After that, we can experiment with better solutions. Merging hide and viewport visibility icons as suggested by @JulienKaspar seems promising.
Eventually using the eye icon should also work to improve performance with animation playback, but this requires some deep changes in the depsgraph.
That sounds like a good compromise, we keep functionality while decluttering the UI.
Here are two a possible mockups of how it could look.
{F5746133, size=full}
That would be awesome !
When do you want objects not to be visible ?
all these objects, you want them to be hidden, especially when you work with linked files.
But you also want to unhide them so you can tweak them, but without messing visibility when they are linked.
Maybe we could have :
1/ A way to lock visibility : equivalent of the hide viewport
2/ A way to quickly hide/unhide stuff -> H / alt-H
3/ A way to keep objects hidden when linked, but visible in the original file (equivalent to old hidden group layers)
That can be a more specific / not in the outliner option , because you want that only on helper objects, or armature , lattices, mesh deform...
Added subscriber: @Northsteel
Added subscriber: @DanielPaul
Excuse me if this was mentioned before.
How will the viewport and render visibility toggles be used in the future?
What if I want to animate the visibility of many objects by the outliner.
Do I have to animate viewport visibility and render visibility separately,
so I have feedback in the viewport what I am doing?
Or is a shortcut for (change render/view visibility simultaneously) planed?
In 2.7 animating the scale was the easiest way of animating visibility,
unfortunately, objects and their shaders are calculated even when they are scaled to 0.
In big scenes with complex shaders, this is a problem, especially in eevee.
A viewport mode for seeing the actual renderstate could also help here.
Something like "show viewport as render view" #57063
I think this is really important to avoid wrong renderings.
Happens really often to me with 2.8 at the current state.
Added subscriber: @tgarriott
Added subscriber: @Mets
What if, in both the outliner and mini-outliner, the Enabledness/Visibility/Selectability would only appear when the one before it is ON?
A disabled object would look like this:
If the object is enabled, the visibility shows up:
And if the object is visible, the selectability shows up:
The render icon is now the first in the list, because it would be odd to make new buttons appear in the middle of the list. Ofc the render icon wouldn't exist in the mini-outliner.
Maybe this could work somewhat well with click+drag? But since the buttons are aligned to the right, and the icons pop up on the right, the newly popped up icons would pop right under the mouse. So maybe the order would need to be flipped for the sake of click+drag.
Added subscriber: @DasCoont
Using blender feb 14 nightly build, currently un-hiding objects selected in local view also globally unhides all objects, can this be reverted back to 2.79 functionality? I want to be able to hide/unhide objects in local view while having objects hidden in global view still remain hidden and unnaffected.
Changed status from 'Open' to: 'Archived'
Archiving in favor of #61578 (Outliner Visibility Update), which contains the latest version of the proposed design (to be further updated after discussion at homestretch workshop).