Dev:2.8/Source/DesignDocument

Originally posted on code.blender.org on October 7th, 2017. Last revision: October 7th, 2017.

• Goal
• Big picture
• View layers and collections
• Workspace
• User interface
• Engine and draw manager
• Asset management
• Dependency graph

Goal

This document is for Blender developers and other contributors to the 2.8 project. It is meant to provide focus and general agreement on technical design decisions. It will allow to empower everyone to contribute more efficiently. UI and further usability design of features will happen after this, as an ongoing project.

“Blender 2.8 will enable artists to work faster and more efficient. Emphasis is on helping specialists or to enable specialist tasks better. 2.8 will allow Blender template/configurations to start with reduced or different user interfaces.”

The idea is to optimise one’s personal workflow better, instead of trying to maintain a single configuration that attempts to provide all the possible tasks at the same time for everyone.

Big picture

Each Blender window has all of its editors sharing the same state. That means there is always a single active Scene, visible objects, drawing engine, (editing) mode, and render engine. The render and viewport settings are being shared by all the editors.

More settings and viewport overrides might be brought in order to accommodate artist feedback. This feedback will be processed after the intended design has been implemented.

Targets

The Blender 2.8 workflow release original plan was rather ambitious. To make sure the development doesn’t drag forever, and everyone knows what we are working towards we will define the 2.8 project goal and targets as:

End-user targets

• View layers, collections and overrides
• Workspaces
• Top bar with global tool area, and headers
• Blender 101 – optimize the interface for specific tasks
• Tool system and manipulators
• PBR viewport render engine (Eevee)
• General purpose engine (Workbench)
• Pipeline for complete 2d animation with grease pencil
• Amber asset engine (basic, local asset management)
• Everything proxyable (static overrides)

Technical targets

• Replace legacy OpenGL with newer OpenGL (3.3 core for now)
• Replace Derived Mesh (internal modifier storage) with new system (using new Dependency Graph)
• Interleaved global/local undo stack (material changes in Edit Mode are currently not registered by Undo)
• Static override system
• Asset engine API
• Improved dependency system
• Draw manager
• Interface templates
• Separation of existing grease pencil annotation tools and grease pencil objects

Orphan targets

Targets lacking developer-power

• Rewrite particle system
• Multi-object editing

Undefined targets

Targets with vague design to be discussed further

• Workspace own add-ons and keymaps
• Game engine

Not targets

Targets better left alone for Blender 3.0

• Everything node
• An in-depth redesign of our functional user interface

View layers and collections

The View Layer system for Blender 2.8 will integrate workflow and drawing, allowing for better Scene organization and viewport control.

Please read this if you’re not familiar with the very powerful new concepts for 2.8 layers.

Workspace

Workspaces allow users to build up a working environment for a specific task.

Workspaces are simply a wrapper on top of the Blender Screens with extra added functionality such as drawing engine, view layer and viewport settings. It might also include custom keymaps and active add-ons.

Overlay engine

In 2.8 all of the edit modes are part of an overlay engine system and their settings are all stored in the Workspace. For example: “show normals”, “brush size”, “objects origins”.

This includes all the tool and display related settings. Some settings are still allowed to stay per-object (e.g., motion path and ghost settings), but whether to display them belongs to the Workspace.

The overlay engine draws on top of the Viewport’s own drawing engine. It’s not part of the final render. This enables for example Object Mode and Edit Modes in a viewport rendering Cycles.

Viewport settings

Some hand-picked render settings will be exposed to the Workspaces as well as Scene, we are calling them viewport settings.

For instance AO distance depends on Scene scale, and would be an annoyance to set per Workspace. However the number of samples, or whether to use AO are a perfect fit for a Workspace.

View Layers can have specific viewport settings overrides (as well as render settings).

Engine and view layer

The engine, View Layer and the viewport settings are set per Workspace, and therefore affect the entire window. However the final render (which is a Scene setting) is not influenced by it.

This way a file opened without UI will not lose its render settings. For that we store an active View Layer and engine in both Workspace and Scene data blocks.

Use scene settings

For viewport drawing, Workspaces have an option to use the Scene render settings (F12) instead of the viewport settings.

This way users can quickly preview the final render settings, engine and View Layer. This will affect all the editors in that workspace, and it will be clearly indicated in the top-bar.

Active mode

The Workspace stores a mode, instead of having it per object. That means if you switch the active object in a Workspace that is in Sculpt Mode, the new active object will be in Sculpt Mode as well.

The undo stack will store a mix of global and local stacks, to be able to flush the edited data when needed. For example when two windows have the same active object in different modes, and you alternate between them to do sculpting or mesh editing.

If syncing the same object in different modes becomes an issue, we switch the workspace to the object mode, keeping the original active mode as the go to mode when toggling back.

One of the driving forces for this feature is multi-object editing. This may not be implemented in time for the first 2.8 release though.

User interface

The Blender 2.5 design is still valid, we are not refactoring the entire Blender user interface. That being said, we do need to implement the following changes.

Top bar

The top bar will be a global area at the top of each window. It is a place for extended settings, and tools.

All the editors follow the top bar. That means per window we have one Scene, one View Layer and one engine used everywhere.

Templates

Apart from the always present top-bar, we will allow most of the Blender interface to be customizable. This is also known as the Blender 101 project.

The Blender 101 project goal is to be able to create a simplified version of Blender for specialized work such as:

• 3d printing
• Architectural planning
• Movie previsualization

A template can be created with Python. Starting Blender with a template will only make UIs and options available as defined by the template.

Optionally, the template can allow a complete Blender to be accessible.

Workspace

The Workspace settings will be split across:

• Top bar: layer, engine, mode
• Properties editor: render settings
• Viewport: tool settings

The tool settings are part of the overlay engine settings and thus stored in the workspace and global for the entire window.

Collections

A panel for collections will be present in the viewport and the properties editor for the Scene and Workspace tabs.

And we may need a tiny collection enable/disable template in the viewport header. We have no design yet but the goal is to mimic the simplicity and ease of use of the 2.7 visibility bits.

To edit the collection members we will use the outliner.

Manipulators

The manipulators and operators widgets bring the work to the 3d viewport. These are the main guidelines when designing manipulators:

• All interactive elements of a manipulator should be visible (e.g., not only on cursor hover).
• They should be toggleable in editors like UV. In dopesheet the box selection is more unanimous so widgets can be more omnipresent.
• The exception of hidden information can be changing cursors based on the possible action (translate up, down, all directions, rotate, scale).
• The whole widget area shouldn’t be an action area, such as panning widget.

Manipulator widget design

Collecting the cases for 2D manipulator will lead to create a new interaction language in Blender. For 2D it will likely converge to what we see in any other 2D drawing software: such as Google Draw and Inkscape.

For 3D there are fewer open source references to study from, so we will have to extrapolate from the 2D designs and create our own.

Established use cases

Paradigms to consider for the manipulators design:

• Using tablet as main input device
• ‘Face mapping’ rigging and posing
• Virtual reality work – 3d manipulators for tools and operators

Tool system

The non-modal tool usage will be supplemented using manipulators. Instead of having to execute a tool from a shortcut, it will additionally be possible to execute it using visual handles.

The tool-shelf will use this heavily: Selecting a tool from the tool-shelf will activate its manipulators if available. The active tool will have some of its options exposed in the top bar as buttons, as well as its own widgets and events.

Only a single tool is active at a time, and transformation manipulators are only visible when no tool is active.

For example: Extrude tool manipulators mockup.

Engines and draw manager

The draw manager allows to compose overlay engines (the editing mode engines – i.e. object, mesh, sculpt, paint) on top of a render engine.

The concept of a render engine is to allow it to work interactively in viewports, and to work as an offline engine (e.g. Cycles). That means the new real-time engine Eevee can also be used as a production render engine.

Eevee engine

Eevee is a new real-time engine which supports high-end PBR graphics coupled with a responsive realtime viewport.

See: https://code.blender.org/2017/03/eevee-roadmap/

Workbench engine

This is a complete engine designed for modeling. It could be a beautiful white canvas with floor shadows for modelers to work. It does not aim at realism, but at the right visualisation for a certain task, and especially to work perfect with the overlay engines.

Grease Pencil

Grease pencil becomes consolidated as an annotation tool, while a full fledged 3d storyboarding system is implemented with the new grease pencil objects.

See: https://wiki.blender.org/index.php/User:Antoniov/Grease_Pencil_as_Object

Although technically this is a new engine, it’s currently an integral part of the overlay system. This way the 2D drawings can be combined with any other engine. We keep this as the only the exception to the rule, as a prelude of an upcoming viewport compositing system.

Asset management

We build an integrated system to handle files, projects and user’s asset libraries to allow browsing and importing data blocks, textures, and so on.

See: https://code.blender.org/2016/10/asset-management-and-pipeline/

Dependency graph

The dependency graph is responsible for dynamic updates of the Scene, where values vary over time – e.g. to enable animation. The new dependency graph was designed from scratch to allow multi-threading, efficient duplication and overrides. It uses a new data model for scene data, replacing the old ‘Derived Mesh’ from the modifier system.

Ultimately this new system will even allow to view a Scene on a different states in different windows. For example, two windows where one plays animation, and the other is on a still frame.

See: https://wiki.blender.org/index.php/Dev:2.8/Source/Depsgraph

Everything proxyable

Any data block (especially referenced ones from external files) will be able to have local properties. And as far as the tools and editors in Blender are concerned, the linked data with its modifications will be treated the same as any local data block.

See: https://developer.blender.org/D2417

This also means that the Armature Proxy will go away, and get replaced with this new system.

Overrides

View layers and collections can override draw and data block options. Those overrides are local to the view layers, but handled as part of the dependency graph rewrite.

See: https://wiki.blender.org/index.php/Dev:2.8/Source/overrides