From BlenderWiki
Depsgraph 2012
Everything in Blender that's animated goes via the 'dependency graph' code, which handles correct order of evaluation and ensures everything is only calculated once.
This 'depsgraph' is a design from 2005, based on solving the stupid "just calculate everything twice" in Blender 2.3x and older. It has served its purpose for 2.4x, but for the 2.5x target it's definitely too weak.
A new depsgraph system should be built, and it can be made with spectacular specifications. To achieve that I propose to do this in distinct steps - or as different projects.
Great article about the depsgraph state to read too: http://wiki.blender.org/index.php/User:Aligorith/Depsgraph_Limitations
1) New depsgraph system
Improvements in the current implementation can at least offer these features:
- Dependencies for all (ID) data types in Blender.
- Allow finer granularity of dependencies.
- Allow visibility changes (like layers) to be updated efficiently
- Ensure it's not only working for Objects, but also for example for Image-dependencies.
- Ensure the design is ready for the other steps!
A promising approach to check is to create a general "scene graph" API, allowing every Blender Scene to have such a graph, each Group to have such a graph, each Armature to have one, and so on.
Graphs can be designed to be local only (not re-used), so they can be used to store the actual display data too. For some properties (Object derivedmesh) this could already be done.
For sake of simplicity I would consider to have despgraph nodes be ID blocks only. It might give limitations (object -> bone -> object deps), but having each ID be calculated as black box has a lot of benefits with current architecture of Blender data. Granularity can also be achieved by cycle-solvers (detect the cycle exceptions and just call these twice).
2) Threaded update evaluation
- Allow more complex animation systems to be played back in real time
Once a graph has been constructed, a graph-evaluator should be able to extract 'update' jobs that allow to be handed over to threads.
In order to achieve this, modifier/derivedmesh code has to be checked on carefully.
3) Render (preview) jobs
- Renders and previews (composites) should be 100% stable and reliable to use.
The thread issue for render (preview) jobs might be solvable with a locking mechanism in the depsgraph... simply forbidding (or entering wait() ) until a thread releases the data. Solvable via the depsgraph API...
4) Point and data caches (Alembic)
- Animation system should use realtime calculated or stored caches transparently.
Character animators would require this as well, this allows disk-streaming of massive character animations, without problems with duplication and instancing etc.
Also for physics sim Alembic is worth looking into. The depsgraph API could handle such caches or switching to recalulcate them well.
5) Multi-time, Duplicators & Proxy levels
- Allow scenes or Blender screens/windows to on different times
- Allow groups to be instanced, and used on different times or with different actions.
- Allow library linked or instanced data with local overrides in general
Here we get into the most complicated feature to solve. This would require a quite elaborate cleanup first of Blender's internal data system (handling ID blocks, file read/write).
One approach to solve this is to create a "IDType" struct, storing all ID methods as being in use for this; including file read/write, duplication, relinking, deletion, pointer magic, etc. Same goes for the ListBase in "Main", which can get faster searches builtin (old proposal from Jiri).
For example; reading a NodeTree with all data from disk + getting pointers corrected is similar to copying a NodeTree.
Conclusion
Code work for 1-2-3-4 is within reason feasible to plan. The last target (5) is the most complex, very interesting... dangerously exciting, risky but with huge benefits. :)
Excluded in above notes is new animation systems, like integration of Bullet rigid body... not sure how dynamic dependencies influence design.
