Dynamic Overrides #96144

New Issue

Bastien Montagne · 2022-03-03T10:04:09+01:00

Bastien Montagne commented

2022-03-03 10:04:09 +01:00

WIP

This task will be used as general design, and umbrella task for the Dynamic Overrides project.

General Idea

Dynamic Overrides (or dynoverrides for short) aim at providing a simple and efficient way to override property values of any data-block, linked or local.

While generally based on the same idea as Library Overrides (aka liboverrides), dynoverrides are a fairly different approach. In a nutshell, they will be simpler to maintain and manage, but way less powerful and not suitable for complex things like a whole character animation.

Here is a list of the key differences:

Library Overrides	Dynamic Overrides
Work only on linked data	Work on any data, linked or local
Allows modifying ID relationships	No ID relationships changes
Allows adding complex entities like Modifiers or Constraints	Can only modify simple ‘value’ properties
Are handled on file save/load	Are handled as part of evaluation
Are stored in the ID they affect	Are stored in a different ID
Directly linkable	Linkable only if the ID owning them is linked

Use cases include:

Tweaking some shaders or lamp settings in the lighting stage of a production file.
Tweaking the position of a few props in the shot at the animation stage of a production file. (Note that this would imply a way to export dynoverrides through ID linking too.)
Dealing with giant hierarchies of IDs (see e.g. #96092 ).

Conceptually, dynoverrides are also quite similar to animation data, the main difference being that they are stored in a different, not directly related data-block than the one they affect.

One big change/challenge implied by this project is that linked data become (partially) editable. This will require a lot of changes all around the Editor codebase (to properties drawing code, operators etc.). Support for that will need to be added gradually, so a restrictive list of overridable properties is most likely needed (similar to what is done with liboverridable properties already).

UI/UX

The main, basic interaction would happen at properties level, similar to how animation of a property is handled:

Define a property as dynoverridden (*and where - active scene or active viewlayer).
From there on, any editing of the property affects the dynoverride value, and not the actual RNA/DNA value.
From there on, creation of an animation would animate the value of the dynoverride.

Later some similar feature to the I shortcut (inserting groups of animation fcurves) could exists for similar properties for dynoverrides.

A list of dynoverrides (grouped by IDs) is shown in Scene and ViewLayer properties, with additional bulk-editing features. If a dynoverride defined at scene level is superseded by a same one defined in the active ViewLayer, it should be visible (grayed out in the Scene list?).

There could also be an overview of dynoverrides in the Outliner?

Some questions:

Re-use 'teal blue' color of liboverridden properties, or have yet another color for dynoverridden properties?
Need a dedicated icon (probably reusing part of the liboverride one for consistency?).

Technical Design

NOTE: Using existing animation system here also needs to be investigated; dynoverrides could simply be animation (fcurves) defined at scene and/or view layers level.

Data Model

Dynamic Overrides can be stored in Scene data-blocks, at two levels:

A global level, applying the dynoverrides to all view layers in the scene.
A per-view layer level, replacing the global one when defined.

Each of these contain a list of dynoverrides, together with some runtime data (mappings) to search efficiently whether a property is dynoverridden or not.

A Dynamic Override contains a pointer to the data-block it affects, an RNA path leading to the affected property in that data-block, and the value of the override.

Potential animation of these dynoverride values: could be stored either as part of the Scene animation data (simplest solution, not sure about the draw-backs yet), or into their own animation data at the scene and view layer levels? Latest could make it easier to somehow 'export'/link dynoverrides into other files?

Evaluation

Dynamic Overrides will be evaluated as part of the depsgraph evaluation, after the handling of animation. This implies that they:

Can be animated, but…
Will supersede any animations or drivers defined on the properties they affect.

How exactly this fits in current and planned design for the Depsgraph still needs to be evaluated.

Ideas for Later

Linking of Dynamic Overrides

Finding out how critical it is to be able to link or export/import those dynoverrides, and how this could be done, needs to be further investigated. This would probably not be part of the initial deliverables though.

An idea could be e.g. to 'compile' the current set (from current scene and view layer) of dynamic overrides applying to a given ID, and store it with that ID. Then on linking that ID, code could re-use that 'compiled overrides' data and apply it into the active scene, with a specific status flag indicating that they are 'from linked data' (and therefore not editable, not deletable, and not saved in blend file, but rather re-created from linked data)?

Overrides From User PoV

Find out how much Library Overrides and Dynamic Overrides could be presented as a single override interface to the user, at least at a high level of usability.

Dynamic Overrides as Variants

One of the ideas from original design back from 2.80 area was that it would be possible to define different overrides for different users of a same ID, and that the depsgraph would detect this and generate different evaluated IDs then.

E.g. two different objects using the same material could define their own dynoverrides of the material color, and evaluated objects would get different evaluated materials IDs assigned then.

WIP ------------------ This task will be used as general design, and umbrella task for the Dynamic Overrides project. ## General Idea Dynamic Overrides (or dynoverrides for short) aim at providing a simple and efficient way to override property values of any data-block, linked or local. While generally based on the same idea as Library Overrides (aka liboverrides), dynoverrides are a fairly different approach. In a nutshell, they will be simpler to maintain and manage, but way less powerful and not suitable for complex things like a whole character animation. Here is a list of the key differences: | Library Overrides | Dynamic Overrides | | ----------------- | ----------------- | | Work only on linked data | Work on any data, linked or local | | Allows modifying ID relationships | No ID relationships changes | | Allows adding complex entities like Modifiers or Constraints | Can only modify simple ‘value’ properties | | Are handled on file save/load | Are handled as part of evaluation | | Are stored in the ID they affect | Are stored in a different ID | | Directly linkable | Linkable only if the ID owning them is linked | Use cases include: * Tweaking some shaders or lamp settings in the lighting stage of a production file. * Tweaking the position of a few props in the shot at the animation stage of a production file. *(Note that this would imply a way to export dynoverrides through ID linking too.)* * Dealing with giant hierarchies of IDs (see e.g. #96092 ). Conceptually, dynoverrides are also quite similar to animation data, the main difference being that they are stored in a different, not directly related data-block than the one they affect. One big change/challenge implied by this project is that linked data become (partially) editable. This will require a lot of changes all around the Editor codebase (to properties drawing code, operators etc.). Support for that will need to be added gradually, so a restrictive list of overridable properties is most likely needed (similar to what is done with liboverridable properties already). ## UI/UX The main, basic interaction would happen at properties level, similar to how animation of a property is handled: - Define a property as dynoverridden (*and where - active scene or active viewlayer). - From there on, any editing of the property affects the dynoverride value, and not the actual RNA/DNA value. - From there on, creation of an animation would animate the value of the dynoverride. *Later some similar feature to the `I` shortcut (inserting groups of animation fcurves) could exists for similar properties for dynoverrides.* A list of dynoverrides (grouped by IDs) is shown in Scene and ViewLayer properties, with additional bulk-editing features. If a dynoverride defined at scene level is superseded by a same one defined in the active ViewLayer, it should be visible (grayed out in the Scene list?). There could also be an overview of dynoverrides in the Outliner? Some questions: * Re-use 'teal blue' color of liboverridden properties, or have yet another color for dynoverridden properties? * Need a dedicated icon (probably reusing part of the liboverride one for consistency?). ## Technical Design > NOTE: Using existing animation system here also needs to be investigated; dynoverrides could simply be animation (fcurves) defined at scene and/or view layers level. ### Data Model Dynamic Overrides can be stored in Scene data-blocks, at two levels: * A global level, applying the dynoverrides to all view layers in the scene. * A per-view layer level, replacing the global one when defined. Each of these contain a list of dynoverrides, together with some runtime data (mappings) to search efficiently whether a property is dynoverridden or not. A Dynamic Override contains a pointer to the data-block it affects, an RNA path leading to the affected property in that data-block, and the value of the override. Potential animation of these dynoverride values: could be stored either as part of the Scene animation data (*simplest solution, not sure about the draw-backs yet*), or into their own animation data at the scene and view layer levels? Latest could make it easier to somehow 'export'/link dynoverrides into other files? ### Evaluation Dynamic Overrides will be evaluated as part of the depsgraph evaluation, after the handling of animation. This implies that they: * Can be animated, but… * Will supersede any animations or drivers defined on the properties they affect. *How exactly this fits in current and planned design for the Depsgraph still needs to be evaluated.* ## Ideas for Later ### Linking of Dynamic Overrides Finding out how critical it is to be able to link or export/import those dynoverrides, and how this could be done, needs to be further investigated. This would probably not be part of the initial deliverables though. An idea could be e.g. to 'compile' the current set (from current scene and view layer) of dynamic overrides applying to a given ID, and store it with that ID. Then on linking that ID, code could re-use that 'compiled overrides' data and apply it into the active scene, with a specific status flag indicating that they are 'from linked data' (and therefore not editable, not deletable, and not saved in blend file, but rather re-created from linked data)? ### Overrides From User PoV Find out how much Library Overrides and Dynamic Overrides could be presented as a single override interface to the user, at least at a high level of usability. ### Dynamic Overrides as Variants One of the ideas from original design back from 2.80 area was that it would be possible to define different overrides for different users of a same ID, and that the depsgraph would detect this and generate different evaluated IDs then. E.g. two different objects using the same material could define their own dynoverrides of the material color, and evaluated objects would get different evaluated materials IDs assigned then.

Bastien Montagne commented

2022-03-03 10:04:09 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'