This document was built on top of the development and research lead by Julian Eisel (Severin) as part of the Google Summer of Code 2016. This proposal is a usability amendment to his design with the viewport project in sight. See the original documentation [here].
The current layer system in Blender is showing its age. It’s been proved effective for simple scene organizations, but it lacks flexibility when organizing shots for more convoluted productions.
The layer system for Blender 2.8 will integrate workflow and drawing requirements. It will allow for organizing the scene for a specific task, and control how different set of objects are displayed.
The following proposal and design document tries to address the above by unifying the object and render layers and integrating them with the viewports and edit modes.
For the rest of the document, whenever we refer to a layer we are talking about the new layer system that replaces all previous layer implementations in Blender. Since in the future we will have other kind of layers (e.g., animation) the layer here referred will be renamed soon (view layer? render layer? workflow layer?).
Here is a proposal for how to separate data, and integrate the layer concept with scene data. In 2.8 we will split the scene in layers, and each layer will have a mode and an engine to use for drawing. Each viewport can show a different layer.
DNA data (that what gets saved and what we work on), Scene data (based on animation or scripts), and Render Data (engines) should have an explicit separation. In 2.8 we will split viewport rendering into many smaller ‘engines’.
(Data diagram revised from original data design by Sergey Sharybin and Ton Roosendaal)
Scene and Layer
Each layer will have its own active object and selected objects. We drop the scene base, and guarantee there is always a layer in the scene (as we do for Render Layer now). A scene also has an active layer, which is the one used to determine the “global” mode for the other editors.
Render or Draw Pipeline
- Active Layer
- Collections define visibility, overrides, light!
- Update layer list (or make copy)
- Send to depsgraph (or use cached)
- Send scene data to engine
- Draw per-mode specific tools
- Draw or render
1 render layer = 1 image (multi-view, passes)
A layer is a set of collections of objects (and their drawing options) required for specific tasks. You can have multiple layers in the scene for compositing effects, or simply to control the visibility and drawing settings of objects in different ways (aiming at different tasks).
A layer also has its own set of active and selected objects, as well as render settings. Few render settings are kept at scene such as dimensions, views and file format.
A scene can have multiple layers, but only one active at a time. The active layer will dictate which data the editors will show by default, as well as the active mode.
Collections are part of a layer and can be used for organizing files, fine tune control of components drawing and eventually overwrite support of linked and local data. They are group of objects defined individually or via name and other filtering options.
The drawing settings relative to a collection will be defined in the layer level, with a few per-collection engine specific options (matcap, silhouette, wire).
A collection has the following data: name, visible, selectable, engine settings per collection, overrides, element list.
As part of the workflow design a layer will be created with a task in mind, and part of this task is the mode used at a given time. The mode will be an explicit property of the layer.
The available modes at a time are depending on the active object. All selected objects (when possible) will enter in the same edit mode. That means an animator will be able to pose multiple characters at once. And the mode is no longer stored in the object.
A viewport should be able to select a single layer to display at a time. However the viewport stores the least amount of data. A viewport doesn’t store the current mode, the current shading, nothing. Apart from the bare minimum (e.g., current view matrix) all the data is stored in the layer.
That also means we can have multiple viewports in the same screen, each one showing different objects, or even the same objects but with different drawing settings.
Since the settings are defined at a scene level (scene > layer > collection), and not at viewport, multiple viewports can share the same drawing settings and objects visibility. The same is valid for offscreen drawing, scene sequence strips, vr rendering, …
Viewport and Render API
This is still needs to be discussed further, but the initial idea is to re-define the Render API so that an external engine would define two rendering functions:
Where the latter would be focused on speed, and the former in quality. That creates a separation in the original idea of making the “Cycles-PBR”, or “Cycles-Armory shaders” as part of the Cycles implementation.
That also means we can (and will) have a new Render Engine only for nice good PBR OpenGL viewport rendering. The pending points are:
- How do we handle the external engine drawing
- Shader design (face, lines, points, transparency)
Render Engine View Drawing
There are two main options to implement this:
- Blender draws the objects using the render engine defined GLSL nodes, and some screen effects, handling probes, AO, …
- The render engine is responsible for going through the visible objects, binging their shaders, drawing them, …
Either way we will have the engine responsible for drawing the solid plates [see docs]. This then is combined with tools drawing, outlines, …
Engine such as Cycles really need to be in control of the entire drawing of its objects. However for OpenGL based engines, we could facilitate their implementations.
OpenGL Rendering Engine
A new render engine should be able to close the gap between fast viewport drawing and realism. This engine could take care of PBR materials that deliver a Cycles like quality, without having to mess with Cycles specific shade groups.
In fact this engine should have an option as to the backend used for the views. The user should be able to pick between Cycles, PBR, Unreal, Unity, … and have the texture maps corresponding to the specific engine.
Cycles itself can still deliver a RenderToView routine that is faster than what it is now (with forced simplification, …). That said, it’s not up to Cycles to implement GLSL nodes that are similar to it BSDF implementations.
We will have specific engines aimed at specific edit modes. Those engines can be used for drawing a layer exclusively, or combined with the layer render engine. For example, when using the Cycles render engine in object mode, we will have the object engine drawing nice highlights on the selected objects, as well as object centers and relationship lines.
However the object mode engine will also be accessible as a standalone engine option, bringing back a full solid drawing for the entire layer, with its own options. This also means we are dropping the current draw modes, and in particular the per-object maximum draw.
Topics for the usability workshop in November 2016.
How do we edit multiple objects?
Should we support mesh edit? Meta-balls? Maybe support for some modes only.
Since Grease Pencil is undergoing some changes, we should make sure it integrates well with this proposal
Artists will want to re-use a carefully crafted layer/collection structure. Linking wouldn’t solve that because usually they wouldn’t want the objects to be linked in as well. We could have a save/load system for layer/collections. Maybe it’s something simply doable with Python, similar to how we save/load keymaps.
An animator typical workflow is to have a viewport for the camera view and another one for posing. Changing settings such as simplify would now mean we need to change this setting in different layers (or collections). Or to have other two other layers with different “simplify” settings and switch between them both respectively.
New objects in Blender are automatically added into the active layer and active collection. But should we have a way to also add them into the non-active layers and their respective collections?
Original layer management design by Julian Eisel and Ton Roosendaal and all the developers and artists who provided extensive review on [T38384].
Current design elaborated with Ton Roosendaal and feedback from Sergey Sharybin. Feedback incorporated from Blender Studio crew.