About

This page is just a list of common problem areas/cases that need to be considered when designing or evaluating new depsgraph designs.

For other examples of reported issues in trunk, refer to the official todo list.

Generality

This is mainly about drivers, but there may also still be some other cases where this is handy (TODO: examples needed!)

Constraint Influence on Bone B is driven by Transform of Bone A.
Spline IK - Curve is parented to "stump" bone in Armature, and user wants to be able to have controls in the same armature.

Animating settings of "Mapping" node result in the internal matrix being computed (i.e. RNA update callback for those properties on the node), so that things which use that will also be affected.

An object (or bunch of objects) are parented to objects which are simulated. * These objects are then the parents of some other objects which may also participate in the simulation (but don't interact with the first set of objects for whatever reason).

Duplis - duplicator wants to override some aspects (e.g. "material colour", "animation of items")
Proxies - multiple proxies in scene

For metaballs, being able to find which is the "motherball" (aka the one which owns "DisplayList" used by others with same name - i.e. in the same "group")
To replace methods like BKE_object_relational_superset(). Anything to do with representing/querying/dealing with relationships between things should be handled by depsgraph instead.
- To replace calls like obrel_armature_find(), which need to define custom logic to crawl the scene graph, checking each modifier/etc. one by one to check for relationships. These are used by the above.

Currently we have DAG_print_dependencies(), which is used to "print dependency graph for scene or armature object to console". The querying/filtering API should be able to be used as the backend powering a function which does such a dump. Ultimately, this function should be deprecated in favour of something which can also be directly accessed by users to check for errors in the dependency logic.

Animation flushing - where does this fit in? Action+NLA stacks must go together...
Efficient and proper updates when objects move between layers (or are hidden, but are relied upon by visible stuff)
Cache management - how much of cache gets cleared in response to changes. While the problem of pointcache management really goes to the heart of the physics sims design/integration (and hence, out of scope for this project), we need to leave enough hooks to make it easy for many common tweaks they may want to do later.

Curve "Path" data needs to be queued up for recalc accordingly by depsgraph, instead of waiting for users (constraints, etc.) to manually do this when in an invalid state