From BlenderWiki

Jump to: navigation, search

Scene Organization and Workspaces

Blender 2.8 design updates August 24th, 2017

This is a proposal to help bring the collection and workspace experiences to a polished user experience level. It doesn't have a big picture, but it builts on top of the previous designs and the current Blender 2.8 implementation.

Scene Organization

Enable collections

We will have an option that separates collection visibility and whether it is enabled. A disabled collection is not included in the depsgraph at all.

Lamps that are only in a disabled collection won’t contribute to the scene lighting. Light probes in a disabled collection won’t be calculated.

Dev-Blender 2.8 SceneOrganizationWorkspace EnableCollection.png

The visibility option controls only whether an object is visible in the viewport. Note that “invisible” objects are still casting shadows.

Better collection management

Users should be able to control collections entirely in the Outliner with drag, dropping and the right mouse button menu options.

For that we need to support multiple objects drag and drop in the outliner.

Dev-Blender 2.8 SceneOrganizationWorkspace CollectionDnD.png

We also need to make sure the outliner is not re-collapsed every time we re-open a .blend.

Outliner Filter

Outliner should have a filter option, where user can filter out what is not relevant at a time.

Right now, for example, there is no way to show only objects, and their hierarchical (parent/children) relations, without including data, drivers, …

A filter system allows the user to set how granular we want the data to be exposed. It also replaces most of the existing “draw mode” options.


  • Collections
  • Objects
  • Data
  • Children
  • Overrides
  • Name (Search)

Search Options:

  • Object type filter
  • Camel case
  • Word complete

The filter system should be enough to get rid of: All Scenes, Current Scene, Visible Layers, Selected, Active, Same Types and Active Render Layer.

The remaining options would be (Groups, Sequence, Blender File, Data Blocks, User Preferences, Orphan Data and Master Collection). But instead of having them always directly accessible we hide them under a top-level toggle where users pick either:

  • Scene Objects
  • Blender Data

Interface draft

Dev-Blender 2.8 SceneOrganizationWorkspace FilterHeaderOld.png

Current header: mix of actions, settings and draw modes

Dev-Blender 2.8 SceneOrganizationWorkspace FilterHeaderNew.png

Proposed header, note that the “collection buttons” are removed and to be accessed via RMB, shortcuts and a menu.

  1. Collapsed Menus
  2. Scene Objects / Blender Data
  3. Filters (Collections, objects, data, children, overrides, search)
  4. Search
  5. Search options

Workspaces, layer and render settings

Mode engine settings


The draw manager is always composing the render engine (Cycles, Eevee, …) with the mode engines (object, edit, texture painting, …) on top.

The mode engines are only viewed when drawing in the viewport or doing OpenGL render. They are never part of the offline “F12” render.

Example of the mode engines settings:

  • Draw normals.
  • Draw objects origins.
  • Show texture paint single channel / full shaded.
  • Sculpt with matcap

Where is the data stored?

Right now those settings are all over the place. In Blender 2.7x we had those stored as objects settings and viewport. While in 2.8 we have them in collections, layers, and viewport.

The proposal is to move all of them to the workspaces.

So they are not in the viewport, and they are not overridable by layers nor collections.

Viewport Settings

It’s tempting to have them in the viewport and consider this a part of the workspace. We can still do it later since viewports are part of workspaces anyways. But it’s better to support things in a higher level, first.

Also, at first, it seems more coherent to have all those settings unify in a single place where you can go to setup how your workspace should look for the different modes.

Render Settings

We can split render settings in two ways:

  • Pipeline settings
  • Engine settings

Pipeline settings should be defined only in the scene level. Those are things like file output, size, format. They won’t be overridable by layers.

Engine settings can be of three types:

  • Offline
    • Multiple shadow maps, ...
  • Online
    • Probe update frequency, ...
  • Both
    • Volumetric, samples, ...

The offline settings are only exposed for the scene. The online ones are exposed for the workspace only. “Both” settings are exposed for scene and workspaces.

Unlike the previous design, workspace render settings are not overrides of scene settings. Instead they are entirely new settings defined for the workspaces.

Layers can override any render engine settings. That doesn’t include “Mode Engine” settings, naturally.

Note: The engine itself (Cycles, Eevee, …) is not considered a render settings. Thus it can’t be overridden by a layer. It is, however, stored in the scene and the workspace.

Final Render Settings Preview

Workspaces need an option to use the final render (F12) settings instead. So users can preview the final render settings, and layers.

This should be set in the workspace properties editor, and affect all the editors. We should clearly indicate in the top-bar that a workspace is using the scene settings.

Dev-Blender 2.8 SceneOrganizationWorkspace Render.png

Layers Editor

All of the scene settings, including which engine to use for final renders (F12) should be in the property editor.

Workspace settings will also be in the property editor. The exception are the “Layer” and “Engine” settings, which will be in the top bar (as well).

Dev-Blender 2.8 SceneOrganizationWorkspace UI-Layers.png

Layer Overrides

There will be plenty of render settings that can be overridden by layers. Right now we are listing every single one of them in the interface. It’s already cluttered, and redundant.

We may want to add overrides to the outliner, but beyond that we can list the overrides in the layer tab, but only the ones that were added. Not all the potential, possible overrides.