View layer and collection editing - Design Task #53495

Closed
opened 2017-12-07 01:20:39 +01:00 by Dalai Felinto · 16 comments

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

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

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

  • 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
Author
Owner

Changed status to: 'Open'

Changed status to: 'Open'
Author
Owner

Added subscriber: @dfelinto

Added subscriber: @dfelinto

Added subscriber: @spockTheGray-4

Added subscriber: @spockTheGray-4

Added subscriber: @mont29

Added subscriber: @mont29

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

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

Added subscriber: @PawelLyczkowski-1

Added subscriber: @PawelLyczkowski-1
Author
Owner

Added subscribers: @pablovazquez, @ideasman42

Added subscribers: @pablovazquez, @ideasman42

Added subscriber: @DuarteRamos

Added subscriber: @DuarteRamos

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

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.
Author
Owner

@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.

  1. 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.

  1. 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.

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

Sure, I will add this to the document.

  1. (...) 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.

  1. 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/)?

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 :)

Added subscriber: @EvandroFerreiradaCosta

Added subscriber: @EvandroFerreiradaCosta

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?
Member

Added subscriber: @JulianEisel

Added subscriber: @JulianEisel
Member

Changed status from 'Confirmed' to: 'Resolved'

Changed status from 'Confirmed' to: 'Resolved'
Member

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
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
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
6 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#53495
No description provided.