Dev:2.8/Source/Layers

Layers

Disclaimer

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

Introduction

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.

Basically apart from organizing your scene in different layers and controlling their visibility, we can’t do much else.

The layer system for Blender 2.8 will support the following functionalities:

• Named layers
• Per layer visibility
• Per layer overwrite
• Layers for organizing a shot, a composition or a specific task being tackled.

Apart from that it’s important to think about the integration between render and viewport visibility. Right not we have Render layers, we have object layers and we even have local layers of a viewport.

The following proposal and design document tries to address the above by unifying the object and render layers and integrating them with the viewport.

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.

Data Design

In order to understand this proposal, refer first to the [ Data Design ] document.

Layers

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

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

Mode

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.

Viewports

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:

• RenderFramebuffer
• RenderToView

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.

Mode Engines

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.

Discussion Topics

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.

Grease Pencil

Since Grease Pencil is undergoing some changes, we should make sure it integrates well with this proposal

Motion Path

Per collection engine settings, and it should be available for more than one engine.

Linking

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.

Scene Override

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

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?

Acknowledgements

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.