Dev:2.8/Source/DrawManager/Possibilities

Draw Manager Possibilities

Introduction

For Blender 2.8 we developed a system that allows for full compositing of engines in the viewport. Each engine is free to handle buffers separately and decide how do we want to combine (compose) them together. And we built a layer system that allows a fine tuned control of objects look and render behaviour.

Most of the implementation so far have been towards developing the necessary infrastructure for upcoming design. This document goes over the current challenges and the built functionalities.

Current Design

Render Engines and Mode Engines

At any given time, multiple engines may be activated. This is determined by the current mode and the active render engine.

For example when in object mode with Cycles, you will have Cycles rendering the scene and on top of it the object mode engine - selection outline, non-mesh objects, objects centers and relationship lines.

When in edit mode with Clay engine, you will have Clay rendering the scene with its mockups, and on top of it the edit mode engine for the active object - vertices, edges, mesh selection overlay - as well as the object mode engine for the other objects - non-mesh objects, objects centers and relationship lines.

Finally when in weight paint mode with Eevee, you will have Eevee rendering the scene, and on top of that the weight paint mode engine drawing the active object weight colors, the pose mode engine drawing the active object armature in pose mode, and the object engine for the other objects - non-mesh objects, objects centers and relationship lines.

Compositing

Although the current implementation is heavily using forward drawing (modifying the draw a buffer in-place, by drawing content into the same buffer), we have a system in place for more complex compositing (draw an isolated buffer, then another to combine then into a third buffer).

This allow us to have a slider to control how much of wireframe we want to implement in the edit mesh mode, and how much the rendering engine should display underneath. In some cases, if we really want to disable the engine for an object (e.g., when doing weight paint) it should be possible as well. This is not implemented at the moment though, but we could make the camera visibility option we have in Cycles more generic and reinforced to be used by other engines as well.

Plethora of Settings

When migrating modes to 2.8 or refactoring them from scratch, we have to think about which settings we want, and where they will be presented to the user.

The problem is that there are way too many places we can consider storing a settings:

• User preference
• Mode
• Mode session
• Viewport
• Scene
• Workspace
• Layer
• Collection

The challenge is to define a simple set of rules that are predictable and manageable by the user. It’s important to outline the possibilities though.

Any render settings that we want defined per layer (or workspace) needs to be defined in the scene level, and overridden at the workspace or render layer levels (you can read about the reasoning behind this in the override manifesto). For example, if you set the workspace to show red matcap for all objects, and switch to a different scene, the new scene is also expected to show red matcap objects. But if the scenes have a different matcap rotation, and this is not overridden by the workspaces, this will be carried on to the objects.

Any draw related settings that we want as a core part of the visualization cannot be a viewport settings. Otherwise once we add scene strips in the video sequencer, or simply do batch OpenGL rendering, we wouldn’t know which settings to use.

Design Discussion

Visibility Control

As of now the only of controlling the object visibility is by setting on/off layer collection visibility flags. That means an object that is not in a visible collection won’t be visible in the screen nor contribute to the scene drawing (e.g., for shadows, lighting, reflections).

Open Topics:

We may want a way to force an object (or collection) to be invisible. Even if the object is in a different visible collection.

We also may want a way to hide objects from view without turning off their influence in the scene. This is mostly for light objects. It would be the equivalent of the old “Only Render”.

Speaking of which, “Only Render” can be thought as a collection property, and even more detailed than what we had. For instance, we could allow to hide empties and cameras, but keep showing lamp objects. Or even, to show lamp objects of a collection, but not of the other. This is also required for the “Local View” implementation.

Mode Engines

All the modes can and should be upgraded to benefit from the new viewport capabilities. However we are not changing all of them at once, but focusing on the object and edit mesh modes first. All the others are being ported as close to 2.7x as possible. That said, even object and edit mode designs are not final, and need to be wrapped up.

Object Mode

Ultimately we would like an object mode engine that allows for moving objects in Cycles even where there is no light, or the rendering is slow. This can be achieved with fill color, and objects centers. At the same time, we may want to see the final shaded object without any overlay interference.

Open Topics:

In order for this to work we need a system with options to gives us the flexibility we need. We still need of a mockup and design for this.

Edit Mode

Edit mode now is very similar to blender 2.78 edit mode, but we started moving options away from the object and moved them to the collections. For example, “show normal”, “normal length” were options defined per object.

They are now defined per collection which may be counter-intuitive. But the moment we allow multi-object support this will fit very well.

Open Topics:

That said, now it’s the chance to re-think the possibilities here. For example, instead of normals we could show a different color based on the face orientation. Instead of showing edges we could have random color for the faces, allowing for a comprehensive understanding of the geometry even from a distance.

Outliner

The outliner is a key part of the new design, and it’s the main interface to deal with the collections.

Open Topics:

It would be interesting to see the outliner evolved to show the overrides as options in the outliner, nested along the collections. Perhaps the settings could even be changed there directly.

The number of options (selected objects, active layer, ... ) we have in the outliner now can be overwhelming and it only gets worse once we add the new collection related options.

The overall design of the outliner could be reconsidered to take into account changes to how we will be using it.

Overrides User Interface

Although the properties editor is working well for now, imagine if we migrate all Cycles render settings to the override system, and have them showing twice - once in the render panel, and another in the render layer one.

Add to that the scene mode settings, as well as the collection settings defaults and our current solution is starting to show its limitations.