Sergey Sharybin
c26566ad27
Drivers: Introduce the Context Properties The goal: allow accessing context dependent data, such as active scene camera without linking to a specific scene data-block. This is useful in cases when, for example, geometry node setup needs to be aware of the camera position. A possible work-around without changes like this is to have some scene evaluation hook which will update driver variables for the currently evaluating scene. But this raises an issue of linking: it is undesirable that the asset scene is linked to the shot file. Surely, it is possible to have post-evaluation handler to clear the variables, but it all starts to be quite messy. Not to mention possible threading conflicts. Another possibility of introducing a way to achieve the goal is to make it so the dependency graph somehow parses the python expression where artists can (and already are trying to) type something like: depsgraph.scene.camera.matrix_world.col[3][0] But this is not only tricky to implement properly and reliably, it hits two limitations: - Currently dependency graph can only easily resolve dependencies to a RNA property. - Some properties access which are valid in Python are not considered valid RNA properties by the existing property resolution functions: `camera.matrix_world[3][0]` is a valid RNA property, but `camera.matrix_world.col[3][0]` is not. Using driver variables allows to have visual feedback when the path resolution fails, and there is no way to visualize errors in the python expression itself. This change introduces the new variable type: Context Property. Using this variable type makes allows to choose between Active Scene and Active View Layer. These scene and view layer are resolved during the driver evaluation time, based on the current dependency graph. This allows to create a driver variable in the following configuration: - Type: Context Property - Context Property: Active Scene - Path: camera.matrix_world[3][0] The naming is a bit confusing. Tried my best to keep it clear keeping two aspects in mind: using UI naming when possible, and follow the existing naming. A lot of the changes are related on making it so the required data is available from the variable evaluation functions. It wasn't really clear what the data would be, and the scope of the changes, so it is done together with the functional changes. It seems that there is some variable evaluation logic duplicated in the `bpy_rna_driver.c`. This change does not change it. It is not really clear why this separate code path with much more limited scope of supported target types is even needed. There is also a possible change in the behavior of the dependency graph: it is now using ID of the resolved path when building driver variables. It used to use the variable ID. In common cases they match, but when going into nested data-blocks it is actually correct to use relation to the resolved ID. Not sure if there was some code to ensure that, which now can be resolved. Also not sure whether it is still needed to ensure the ID specified in the driver target is build as well. Intuitively it is not needed. Pull Request #105132
32 lines
842 B
C++
32 lines
842 B
C++
/* SPDX-License-Identifier: GPL-2.0-or-later */
|
|
|
|
#pragma once
|
|
|
|
/** \file
|
|
* \ingroup pythonintern
|
|
*/
|
|
|
|
struct ChannelDriver;
|
|
struct DriverTarget;
|
|
struct PathResolvedRNA;
|
|
|
|
#ifdef __cplusplus
|
|
extern "C" {
|
|
#endif
|
|
|
|
/**
|
|
* A version of #driver_get_variable_value which returns a #PyObject.
|
|
*/
|
|
PyObject *pyrna_driver_get_variable_value(const struct AnimationEvalContext *anim_eval_context,
|
|
struct ChannelDriver *driver,
|
|
struct DriverVar *dvar,
|
|
struct DriverTarget *dtar);
|
|
|
|
PyObject *pyrna_driver_self_from_anim_rna(struct PathResolvedRNA *anim_rna);
|
|
bool pyrna_driver_is_equal_anim_rna(const struct PathResolvedRNA *anim_rna,
|
|
const PyObject *py_anim_rna);
|
|
|
|
#ifdef __cplusplus
|
|
}
|
|
#endif
|