Dev:2.8/Source/overrides/depsgraph

Depsgraph and dynamic overrides

Last revision: November 16th, 2017 Design document by Dalai Felinto and Sergey Sharybin

This document tries to clarify some pending design for dynamic overrides and how the new dependency graph handles them. All the overrides mentioned here are dynamic, as oppose to the static overrides.

Principles

• Overrides can be added to view layers, and collections.
• All overrides can potentially be used as view layer overrides, but some can also be used as collection overrides.
• Objects sharing the same material or other data, but in different collections with different overrides will effectively be given access to different copy-on-write versions of the same material.
• Virtually any setting can be overridden per view layer, and some per collections. However we should be able to control which properties are overridden.
• It’s tempting to add common settings as builtin overrides (e.g., render samples and material overrides in 2.7x). However we will first focus on making adding any override as convenient as possible. Only if we fail at that we will consider re-adding these settings.

Example

• Scene → View layer (e.g., AO Distance)
• Viewport settings → View layer (e.g., AO Bounces)
• Viewport settings→ Collection + view layer (e.g., Matcap, Object Volume Sample)
• Overlay settings → View layer (e.g., Floor)
• Overlay settings → Collection + view layer (e.g., Show Objects Name)
• ID → View layer (e.g., World)
• ID → Collection + view layer (e.g., Lamp Energy, Material Color)

Workspace overrides and viewport settings

There may be a need to introduce workspaces overrides instead of workspace viewport settings.

On one hand this allows users to be really granular as to which visual settings are defined per workspace. On the other hand it adds yet another level of overrides that may be too complex for the final users.

Implementation guideline

Implementation is expected to change once we start to engineer it. This is a guideline to illustrate the technical feasibility of this project.

There are different steps required to handle overrides:

• Collections evaluation
• ID datablock overrides evaluation

The collections evaluation are already in place. However while now we initialize the data from the scene (for clay), we should limit the evaluation scope to handle only override merging. In the end of this step the view layer will have a final merged override IDProperty, as well as the objects.

The ID datablock overrides evaluation will happen after the collections evaluation. It will convert the override IDProperties into copy-on-write DNA for most of the data. For example, if a view layer has a world override, this will change the scene->world data stored in the depsgraph.

Workspace settings

In order to support workspace overrides we need to be able to access the workspace overridable data from view layers or objects.

Example I: Floor spacing.

Although the user will set the floor settings for the workspace, he or she can also set an override for a particular view layer to change the floor. In this case we need to store floor spacing in the view layer as well, and access from it during drawing. Even if the user never directly sets it from the view layer.

Example II: Object names.

We will move the “show object names” option from the object to the workspace. So user won’t be able to individually change an object “show object name” option. However, internally, we will keep this setting in the object datablock, so depsgraph can write to it. And the drawing engine can read from the object directly.