Change Details

See T61578 for discussions and mockups. Visibility Options ------------------ We are adding more granular control over restriction columns in the outliner, as well as a refined take on the collection (and objects) visibility options. The role of the restriction and visibility flags in the collection and view layer collections should respect the following statement: "Users should be able to setup a view layer for rendering, or to work in a viewport, and have its settings undisturbed while working in a different view layer." From that we derive the need for per-collection render visibility and per-collection instance visibility. The latter is required so we can work in a visible collection/object knowing it will be hidden when instancing it (e.g., for armatures and highpoly objects). Compositing settings such as holdout, indirect only and enable/disable are left per (view) layer collections. The option to enable/disable a collection altogether must be per view-layer, so we can compose the view layers with different valid collections. Viewport visibility is a tricky one. If/when we have per-viewport collection visibility we could have this in the collection level. Until then I'm in favour of per-(view) layer collection visibility. Selectability doesn't affect render it could either be per-collection or per (view) layer collection. I'm leaving it per-collection as it is now. That means we are splitting the visibility settings as following: Collection ========== * Render Visibility * Instance Visibility * Selectable {1} (View) Layer Collection ======================= * Enable * Holdout * Indirect Only * Viewport {2} {1} No strong reasons to have it in either group. {2} We could move viewport visibility to the Collection level if we had per viewport collection visibility. Visibility Hiearchy ------------------- (Maybe not a popular design view, but let me write it down anyways) Most of the visibility settings have a default value, and what we are really interested on are the non-conforming collections/objects. For instance, the collections with render restriction are usually hand-picked. These are the ones that should stand out when looking at the corresponding column. We can solve that with the icons. But on top of that, (in the future) we could dim the expected value, highlighting the exceptions we expect to stand out. Icons ----- Little reminder that we will need better icons for holdout, indirect only, and probably instanced (nothing wrong with the current, but it differs from the proposal when it is turned off). Todos ----- [ ] Implement Instanced visibility [ ] Do version if needed [ ] Dim the expected settings (optional, likely after commit if ever) [ ] Test all the modes, modifier, bones, ... [ ] Scissor checkbox (the checkboxes are drawn on top of the restrict column safe zone).

See T61578 for discussions and mockups. Visibility Options ------------------ We are adding more granular control over restriction columns in the outliner, as well as a refined take on the collection (and objects) visibility options. The role of the restriction and visibility flags in the collection and view layer collections should respect the following statement: "Users should be able to setup a view layer for rendering, or to work in a viewport, and have its settings undisturbed while working in a different view layer." From that we derive the need for per-collection render visibility and per-collection instance visibility. The latter is required so we can work in a outliner, visible collection/object knowing it will be hidden when instancing itexposing "indirect only" and "holdout" as options, and change the way (e.g., for armatures and highpoly objects). Compositing settings such as holdout, indirect only and enable/disable are left per (view) layer collections. The option to enable/disable a collection altogether must be per view-layer, so we can compose the view layers with different valid collections. Viewport visibility is a tricky one. If/when we have per-viewport collection visibility we could have this in the collection levelusers enable/disable collections in a viewlayer. Until then I'm in favour of per-(view) layer collection visibility. Selectability doesn't affect render it could either be per-collection or per We also rename the object viewport restriction to hide instance. (view) layer collection. I'm leaving it per-collection as it is now. That means we are splitting the visibility settings as following So the options we have are: Collection ========== * Render Visibility * Instance Visibility * Selectable {1} (View) Layer Collection ======================= * Enable * Holdout * Indirect Only * Viewport {2} {1} No strong reasons to have it in either group. {2} We could move viewport visibility to the Collection level if we had per viewport collection visibility. Visibility Hiearchy ------------------- (Maybe not a popular design view, but let me write it down anyways) Most of the visibility settings have a default value, and what we are really interested on are the non-conforming collections/objects. For instance, the collections with render restriction are usually hand-picked. These are the ones that should stand out when looking at the corresponding column. We can solve that with the icons. But on top of that, (in the future) we could dim the expected value, highlighting the exceptions we expect to stand out. Icons ----- Little reminder that we will need better icons for holdout, indirect only, and probably instanced (nothing wrong with the current, but it differs from the proposal when it is turned off). Todos ----- [ ] Implement Instanced visibility [ ] Do version if needed [ ] Dim the expected settings (optional, likely after commit if ever) [ ] Test all the modes, modifier, bones, ... [ ] Scissor checkbox (the checkboxes are drawn on top of the restrict column safe zone). [ ] Implement Ctrl+Click for visibility (isolation) column safe zone).[ ] Fix Shift+Click for the "hide_viewport" (shift+clicking in a collection eye icon doesn't hide its objects eyes)