[Bf-blender-cvs] [83fd3767d35] master: Fix T98618: Drivers don't automatically update when changing active camera

[Sergey Sharybin]

Commit: 83fd3767d353213b5b20bf9d386f603dbda249f0
Author: Sergey Sharybin
Date:   Tue Jun 7 15:42:22 2022 +0200
Branches: master
https://developer.blender.org/rB83fd3767d353213b5b20bf9d386f603dbda249f0

Fix T98618: Drivers don't automatically update when changing active camera

Active camera is a property of Scene, so need to take scene changes into
account for such drivers to work reliably.

The fix covers all the common cases of such configurations, but some of
them might not be yet fully supported. Mainly cases when the target ID
is not covered by the copy-on-write mechanism.

There is a fuller explanation available in the code for the ease of reading
by the future generations.

Differential Revision: https://developer.blender.org/D15146

===================================================================

M	source/blender/depsgraph/intern/builder/deg_builder_relations.cc

===================================================================

diff --git a/source/blender/depsgraph/intern/builder/deg_builder_relations.cc b/source/blender/depsgraph/intern/builder/deg_builder_relations.cc
index c16325b7299..c13c6d2f870 100644
--- a/source/blender/depsgraph/intern/builder/deg_builder_relations.cc
+++ b/source/blender/depsgraph/intern/builder/deg_builder_relations.cc
@@ -1711,6 +1711,37 @@ void DepsgraphRelationBuilder::build_driver_variables(ID *id, FCurve *fcu)
         }
         add_relation(variable_exit_key, driver_key, "RNA Target -> Driver");
 
+        /* It is possible that RNA path points to a property of a different ID than the target_id:
+         * for example, paths like "data" on Object, "camera" on Scene.
+         *
+         * For the demonstration purposes lets consider a driver variable uses Scene ID as target
+         * and "camera.location.x" as its RNA path. If the scene has 2 different cameras at
+         * 2 different locations changing the active scene camera is expected to immediately be
+         * reflected in the variable value. In order to achieve this behavior we create a relation
+         * from the target ID to the driver so that if the ID property of the target ID changes the
+         * driver is re-evaluated.
+         *
+         * The most straightforward (at the moment of writing this comment) way of figuring out
+         * such relation is to use copy-on-write operation of the target ID. There are two down
+         * sides of this approach which are considered a design limitation as there is a belief
+         * that they are not common in practice or are not reliable due to other issues:
+         *
+         * - IDs which are not covered with the copy-on-write mechanism.
+         *
+         *   Such IDs are either do not have ID properties, or are not part of the dependency
+         *   graph.
+         *
+         * - Modifications of evaluated IDs from a Python handler.
+         *   Such modifications are not fully integrated in the dependency graph evaluation as it
+         *   has issues with copy-on-write tagging and the fact that relations are defined by the
+         *   original main database status. */
+        if (target_id != variable_exit_key.ptr.owner_id) {
+          if (deg_copy_on_write_is_needed(GS(target_id->name))) {
+            ComponentKey target_id_key(target_id, NodeType::COPY_ON_WRITE);
+            add_relation(target_id_key, driver_key, "Target ID -> Driver");
+          }
+        }
+
         /* The RNA getter for `object.data` can write to the mesh datablock due
          * to the call to `BKE_mesh_wrapper_ensure_subdivision()`. This relation
          * ensures it is safe to call when the driver is evaluated.