View layer and collection editing - Design Task #53495

New Issue

Dalai Felinto · 2017-12-07T01:20:39+01:00

Dalai Felinto commented

2017-12-07 01:20:39 +01:00

Introduction

There are a few actions that we need to cover for collection editing and daily work:

Hide/unhide collections
Manage F12 view layer without the hassle of rendering while doing so
Add/remove objects
Add/remove overrides
Edit overrides
Add/remove collections

Enable/disable overrides

Collection editing design

Reinforce a separation between organizing the scene, and the view layer

Organizing the scene includes:

Move objects from/to different collections
Create and delete collections
Change collection hierarchy

Organizing the view layer includes:

Link collections
Add/remove overrides
Collection visibility

To change the scene organization we can use:

Shortcuts (change objects collections).
Outliner when seeing the scene tree.
Properties editor
- Object: collections

To change the view layer we can use:

Shortcuts (hide/show collections)
Viewport header (compact hide/show collections and overrides)
Viewport properties (hide/show collections and overrides, edit overrides)
Properties editor
- Scene: hide/show/link render (F12) view layer, add/remove/hide/edit overrides
- Workspace: add/remove/edit overrides, hide/show/selectability/link view layer
- Collection: edit overrides

To change the groups we have two ways:

Properties editor (minimized layer/overrides visibility control in the group panel for objects)
Outliner (visibility, hierarchy and add/remove objects and collections for groups)

Scene organization

Following that idea, let's dig further into scene organization.

Outliner

Outliner "Collections"
- Rename current outliner display mode from Master Collection Tree to Collections
Auto-incremental collection names
- No more "Default Collection" or "New Collection"
- By default when adding a collection we will have a suffix based on the collection "index" in relation to its parent, and a prefix based on the parent collection name.
  - For collections nested under the Master Collection we use "Collection 1", "Collection 2", ..., if one rename the last collection from "Collection 5" to "House" and add a new collection, the new collection will be "Collection 6"
  - For collection nested under any other collection we use the parent collection name as prefix, so by default when adding collections to a collection named "House" we get "House 1", "House 2",
Support non-sibling collections to share the same name
- This way we can have a Rig collection under "Boris", and "Agent" collections.
- We will need to expose the full "path" (characters ➜ Boris ➜ Rig) for tooltips or UI.
Master Collection always expanded
- And really #53340 (collections are always collapsed) should be fixed yesterday.
Deleting a collection moves its objects to Master Collection
- This reinforces the mental model of all the objects are in the Master Collection as presented in the View Layers and Collections document .
- We can still add an option with a shift modifier to delete a collection and not move objects to master collection
No operator buttons there (e.g., add / remove collection)
Menu with these operators to control collection and objects
- X: delete collection (Delete collection and move its objects to the master collection)
- C: add new nested collection
- ?: add selected objects
- ?: remove selected objects
Re-order and moving objects and collections working via drag & drop

Viewport

Move to collection: This replaces the old "move to layer" operator. This mockup is literally using menus for this. The final solution needs to let users know if a collection already contains the object (or if a nested collection from it has it). As well as supporting clicking and shift+clicking without closing the menus.

Object Properties

Collections: Similar to how we handle groups, we list all the collections (of the current scene) an object is linked to. That also allows for quickly remove the object from a collection. In this case, when clicking "Add to Collection" we don't use the same popup as the "Move to Collection". Instead, we use the search template.

Note: This is no longer part of the design. It will be implemented as an addon for now. But this should be solved by the outliner, via a bottom-up mode. Also this would be potentially slow on playback.

Organizing View Layers

View layers organization happens in a few places. They all share some elements in common. This example you see the workspace view layer editor which is the most complete one.

For the render panel, we don't need to expose selectability.
For the viewport properties area, we won't have this panel - even if initially we planned to have. The idea is to reduce redundancy. So we give users one good way of doing something, and stick to it.

Mockups

P573 Object Properties.
P574 Viewport.

Introduction **** There are a few actions that we need to cover for collection editing and daily work: - Hide/unhide collections - Manage F12 view layer without the hassle of rendering while doing so - Add/remove objects - Add/remove overrides - Edit overrides - Add/remove collections # Enable/disable overrides Collection editing design **** Reinforce a separation between organizing the scene, and the view layer Organizing the scene includes: - Move objects from/to different collections - Create and delete collections - Change collection hierarchy Organizing the view layer includes: - Link collections - Add/remove overrides - Collection visibility To change the scene organization we can use: - Shortcuts (change objects collections). - Outliner when seeing the scene tree. - Properties editor - Object: collections To change the view layer we can use: - Shortcuts (hide/show collections) - Viewport header (compact hide/show collections and overrides) - Viewport properties (hide/show collections and overrides, edit overrides) - Properties editor - Scene: hide/show/link render (F12) view layer, add/remove/hide/edit overrides - Workspace: add/remove/edit overrides, hide/show/selectability/link view layer - Collection: edit overrides To change the groups we have two ways: - Properties editor (minimized layer/overrides visibility control in the group panel for objects) - Outliner (visibility, hierarchy and add/remove objects and collections for groups) Scene organization **** Following that idea, let's dig further into scene organization. Outliner ---------- - Outliner "Collections" - Rename current outliner display mode from `Master Collection Tree` to `Collections` - Auto-incremental collection names - No more "Default Collection" or "New Collection" - By default when adding a collection we will have a suffix based on the collection "index" in relation to its parent, and a prefix based on the parent collection name. - For collections nested under the `Master Collection` we use "Collection 1", "Collection 2", ..., if one rename the last collection from "Collection 5" to "House" and add a new collection, the new collection will be "Collection 6" - For collection nested under any other collection we use the parent collection name as prefix, so by default when adding collections to a collection named "House" we get "House 1", "House 2", - Support non-sibling collections to share the same name - This way we can have a Rig collection under "Boris", and "Agent" collections. - We will need to expose the full "path" (characters ➜ Boris ➜ Rig) for tooltips or UI. - Master Collection always expanded - And really #53340 (collections are always collapsed) should be fixed yesterday. - Deleting a collection moves its objects to `Master Collection` - This reinforces the mental model of all the objects are in the `Master Collection` as presented in the [View Layers and Collections document ](https://code.blender.org/2017/09/view-layers-and-collections/). - We can still add an option with a shift modifier to delete a collection and not move objects to master collection - No operator buttons there (e.g., add / remove collection) - Menu with these operators to control collection and objects - X: delete collection (Delete collection and move its objects to the master collection) - C: add new nested collection - ?: add selected objects - ?: remove selected objects - Re-order and moving objects and collections working via drag & drop Viewport ----------- ![collection_editing.jpg](https://archive.blender.org/developer/F1348574/collection_editing.jpg) **Move to collection**: This replaces the old "move to layer" operator. This mockup is literally using menus for this. The final solution needs to let users know if a collection already contains the object (or if a nested collection from it has it). As well as supporting clicking and shift+clicking without closing the menus. Object Properties --------------------- ![babershop_chair.png](https://archive.blender.org/developer/F1376271/babershop_chair.png) **Collections**: Similar to how we handle groups, we list all the collections (of the current scene) an object is linked to. That also allows for quickly remove the object from a collection. In this case, when clicking "Add to Collection" we don't use the same popup as the "Move to Collection". Instead, we use the search template. Note: This is no longer part of the design. It will be implemented as an addon for now. But this should be solved by the outliner, via a bottom-up mode. Also this would be potentially slow on playback. Organizing View Layers **** View layers organization happens in a few places. They all share some elements in common. This example you see the workspace view layer editor which is the most complete one. ![view_layer_workspace.jpg](https://archive.blender.org/developer/F1378419/view_layer_workspace.jpg) * For the render panel, we don't need to expose selectability. * For the viewport properties area, we won't have this panel - even if initially we planned to have. The idea is to reduce redundancy. So we give users one good way of doing something, and stick to it. Mockups **** * [P573](https://archive.blender.org/developer/P573.txt) Object Properties. * [P574](https://archive.blender.org/developer/P574.txt) Viewport.

Dalai Felinto self-assigned this 2017-12-07 01:20:39 +01:00

Dalai Felinto commented

2017-12-07 01:20:39 +01:00

Changed status to: 'Open'

Dalai Felinto commented

2017-12-07 01:20:40 +01:00

Added subscriber: @dfelinto

Danrae Pray commented

2017-12-07 02:52:21 +01:00

Added subscriber: @spockTheGray-4

Bastien Montagne commented

2017-12-07 15:35:24 +01:00

Added subscriber: @mont29

Bastien Montagne commented

2017-12-07 15:35:24 +01:00

Don’t see anything to add here off hands, all proposed tools look reasonable to me.

Dalai Felinto commented

2017-12-08 22:07:59 +01:00

Added subscriber: @PawelLyczkowski-1

Dalai Felinto commented

2017-12-08 22:24:35 +01:00

Added subscribers: @pablovazquez, @ideasman42

Duarte Farrajota Ramos commented

2017-12-11 17:40:10 +01:00

Added subscriber: @DuarteRamos

Duarte Farrajota Ramos commented

2017-12-11 17:40:10 +01:00

Really like the direction this is taking. :) A few thoughts from a user point of view:

What purpose does the Master Collection serve? I understand it currently acts as "scene root" of sorts where all objects fall in by default, but it just seems like a redundant and needless step. Why not just make objects belong in the "Current Scene" instead by default, no explicit collection needed? Basically from the UI point of view only thing that would changed is that the master collection wouldn't have an explicit name, it would just be represented by the current scene name instead. It seems less confusing to new users, one less thing to learn/manage, and the tree would potentially be represented with one step less like just:

Scene Name
- Collection 1
- Collection 2
- Collection 3

What does `Ctrl+X don't move objects to master collection` do? Does it remove objects from the scene too? Does it move them to a parent Collection? Will it leave them in some sort of limbo? Might just need some rewording so it is clear what it does, especially if it does delete objects.

For collection management we might need some sort of operator to match the selected objects collections to the active object ones, useful for complex scene structures. Lets say the active object already belongs to a bunch of randomly nested collections like "Collection 2", "Set", "Set 3" and "Furniture 5", and we want to bring all selected objects to these same collections. We could have something akin to the current `Ctrl` + `L` Make Links menu with an entry to match collections.

I understand this can probably be easily implemented by addons later, but are you considering having some sort of "Active Collection Set" instead of a single active collection? This would work so that any newly created objects at a certain moment would be added to a bunch of predefined collections by default instead of just one. Or maybe have this read from the active scene object automatically?

Similarly having some sort of "Saved Collection States" could be very useful. Say you want to work on your outdoors scene props. You may want to turn off any "Characters" and "Interior Props" collections, make any "Environment" and "Buildings" layers visible but unselectable, and turn on all and make selectable all your "Outdoors Props" collections. Toggling this manually every time may be cumbersome and time consuming, so having the possibility to save a current state to a certain list (like "Outdoors Props" or "Posing") would be very useful in the long run. Again this probably falls into the category of things that could be easily implemented by addons later.

Really like the direction this is taking. :) A few thoughts from a user point of view: # What purpose does the *Master Collection* serve? I understand it currently acts as "scene root" of sorts where all objects fall in by default, but it just seems like a redundant and needless step. Why not just make objects belong in the "Current Scene" instead by default, no explicit collection needed? Basically from the UI point of view only thing that would changed is that the master collection wouldn't have an explicit name, it would just be represented by the current scene name instead. It seems less confusing to new users, one less thing to learn/manage, and the tree would potentially be represented with one step less like just: - Scene Name - Collection 1 - Collection 2 - Collection 3 # The move to layer menu might either need checkboxes (if feasible) or independently clickable expand arrows to the right, or both; so one can either click the arrow to expand the child collections, or click the name/checkbox to actually move/copy selected objects to the clicked collection. Checkboxes+Arrows might be more versatile since it would also allow adding one object to multiple collections at once, at the expense of having to "click away" after finishing, to close the menu. ![BlenderMenus_Mockup.png](https://archive.blender.org/developer/F1377553/BlenderMenus_Mockup.png) # What does `Ctrl+X don't move objects to master collection` do? Does it remove objects from the scene too? Does it move them to a parent Collection? Will it leave them in some sort of limbo? Might just need some rewording so it is clear what it does, especially if it does delete objects. # For collection management we might need some sort of operator to match the selected objects collections to the active object ones, useful for complex scene structures. Lets say the active object already belongs to a bunch of randomly nested collections like "Collection 2", "Set", "Set 3" and "Furniture 5", and we want to bring all selected objects to these same collections. We could have something akin to the current `Ctrl` + `L` *Make Links* menu with an entry to match collections. # I understand this can probably be easily implemented by addons later, but are you considering having some sort of "Active Collection Set" instead of a single active collection? This would work so that any newly created objects at a certain moment would be added to a bunch of predefined collections by default instead of just one. Or maybe have this read from the active scene object automatically? - Similarly having some sort of "Saved Collection States" could be very useful. Say you want to work on your outdoors scene props. You may want to turn off any "Characters" and "Interior Props" collections, make any "Environment" and "Buildings" layers visible but unselectable, and turn on all and make selectable all your "Outdoors Props" collections. Toggling this manually every time may be cumbersome and time consuming, so having the possibility to save a current state to a certain list (like "Outdoors Props" or "Posing") would be very useful in the long run. Again this probably falls into the category of things that could be easily implemented by addons later.

Dalai Felinto commented

2017-12-11 18:36:18 +01:00

@DuarteRamos: Thanks for your feedback.

What purpose does the Master Collection serve?

It allows for the user to link all the scene objects at once into a view layer. You won't have this if we "hide" the master collection from the users.

The move to layer menu (...)

Agree with that. And on top of this we probably need to add a "Header" to the nested panels, to be more clear what we are exploring. That said, there is a chance that the object properties panel is enough. I think that an operator like this that gives you a full view of the scene tree in relation to the object is powerful on its own way. But whether or not we should prioritize its implementation is a the matter at hand.

What does X: delete collection (Ctrl+X don't move objects to master collection)

Technically this would be the operator:
Label: "Delete Collection", Shortcut: X, Tooltip: "Delete collection and move its objects will be moved to the master collection"

However if we have this exposed in the UI as a button, we can also implement the "ctrl" modifier to remove the objects together with the collection.

(...) Match selected objects collection to active object

Sure, I will add this to the document.

(...) Active Collection Set

That won't happen. Blender has the concept of active everyone, and we should stick to this. What we could have is the concept of "Selected collections" if we want the behavior you describe. Or even a option in the collection the marks it as the collection(s) where new objects will automatically be added. I would like examples of production-like scenarios before contemplating this alternative though.

Similarly having some sort of "Saved Collection States" could be very useful (...)

What you are asking is basically what we support by having different "view layers" with the same collections. Are you familiar with the "view layers and collections" design doc ?

@DuarteRamos: Thanks for your feedback. > 1. What purpose does the Master Collection serve? It allows for the user to link all the scene objects at once into a view layer. You won't have this if we "hide" the master collection from the users. > 2. The move to layer menu (...) Agree with that. And on top of this we probably need to add a "Header" to the nested panels, to be more clear what we are exploring. That said, there is a chance that the object properties panel is enough. I think that an operator like this that gives you a full view of the scene tree in relation to the object is powerful on its own way. But whether or not we should prioritize its implementation is a the matter at hand. > 3. What does X: delete collection (Ctrl+X don't move objects to master collection) Technically this would be the operator: Label: "Delete Collection", Shortcut: X, Tooltip: "Delete collection and move its objects will be moved to the master collection" However if we have this exposed in the UI as a button, we can also implement the "ctrl" modifier to remove the objects together with the collection. > 4. (...) Match selected objects collection to active object Sure, I will add this to the document. > 5. (...) Active Collection Set That won't happen. Blender has the concept of active everyone, and we should stick to this. What we could have is the concept of "Selected collections" if we want the behavior you describe. Or even a option in the collection the marks it as the collection(s) where new objects will automatically be added. I would like examples of production-like scenarios before contemplating this alternative though. > 6. Similarly having some sort of "Saved Collection States" could be very useful (...) What you are asking is basically what we support by having different "view layers" with the same collections. Are you familiar with the ["view layers and collections" design doc ](https://code.blender.org/2017/09/view-layers-and-collections/)?

Duarte Farrajota Ramos commented

2017-12-11 18:59:03 +01:00

I see thanks for the clarifications agree with it all.

In #53495#474886, @dfelinto wrote:
@DuarteRamos: What you are asking is basically what we support by having different "view layers" with the same collections. Are you familiar with the "view layers and collections" design doc ?

I've been reading again with more, must have I missed that part. I mistakenly interpreted View Layers simply as a spiritual successor of current Render layers exclusively for rendering purposes alone, was not aware of its full capabilities. They seem to cover that workflow perfectly.

Thanks for the feedback and keep up the excellent work :)

I see thanks for the clarifications agree with it all. > In #53495#474886, @dfelinto wrote: > @DuarteRamos: What you are asking is basically what we support by having different "view layers" with the same collections. Are you familiar with the ["view layers and collections" design doc ](https://code.blender.org/2017/09/view-layers-and-collections/)? I've been reading again with more, must have I missed that part. I mistakenly interpreted View Layers simply as a spiritual successor of current Render layers exclusively for rendering purposes alone, was not aware of its full capabilities. They seem to cover that workflow perfectly. Thanks for the feedback and keep up the excellent work :)

Evandro Costa commented

2018-06-03 05:49:13 +02:00

Added subscriber: @EvandroFerreiradaCosta

Evandro Costa commented

2018-06-03 05:49:13 +02:00

Hi Dalai... can I ask a question?
Are there any plans to use a similar approach to Armature Layers, to turn them to a Collections system instead of limited layers like they are today?

Hi Dalai... can I ask a question? Are there any plans to use a similar approach to Armature Layers, to turn them to a Collections system instead of limited layers like they are today?

Julian Eisel commented

2020-06-26 19:22:24 +02:00

Added subscriber: @JulianEisel

Julian Eisel commented

2020-06-26 19:22:24 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Julian Eisel closed this issue

2020-06-26 19:22:24 +02:00

Julian Eisel commented

2020-06-26 19:22:24 +02:00

I think most things mentioned here are done. If something is missing, I prefer new and up-to-date tasks for this.

In general the task is rather outdated, the design changed quite a bit. Further improvements and additions are possible of course, we can open new tasks as needed.

I think most things mentioned here are done. If something is missing, I prefer new and up-to-date tasks for this. In general the task is rather outdated, the design changed quite a bit. Further improvements and additions are possible of course, we can open new tasks as needed.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

View layer and collection editing - Design Task #53495

Enable/disable overrides

Outliner

Viewport

Object Properties

What does Ctrl+X don't move objects to master collection do? Does it remove objects from the scene too? Does it move them to a parent Collection? Will it leave them in some sort of limbo? Might just need some rewording so it is clear what it does, especially if it does delete objects.

What does `Ctrl+X don't move objects to master collection` do? Does it remove objects from the scene too? Does it move them to a parent Collection? Will it leave them in some sort of limbo? Might just need some rewording so it is clear what it does, especially if it does delete objects.