利用者:Aligorith/GSoC2013 Depsgraph/Proposal

Dependency Graph and Evaluation Engine Refactor

Joshua Leung (aligorith)

2013 May 3

Summary

For many years, Blender’s dependency graph and evaluation engine has been long overdue for refactoring. Despite various key subsystems in Blender having already been refactored to become more flexible and powerful in the hands of skilled artists, it has become increasingly clear that artists are currently unable to fully harness the full potential capabilities of these tools due to limitations imposed by the current dependency graph engine. This project aims to investigate and resolve the various design issues involved in creating a new future-proof dependency graph system, and will result in an initial implementation of relevant core components.

Benefits to Blender

The dependency graph and evaluation engine is a core component of Blender. In its current state, there are severe limitations on the complexity of setups that users can create. Also, developers are often hamstrung by a combination of highly technically complex bugs, mounting technical debt, and a lack of support for certain helpful operations.

Therefore, there are numerous benefits to the Blender community should this project be successful. These include:

• Greater flexibility for users to define complex setups with fewer dependency and evaluation related glitches or limitations
• The potential for better performance, especially on modern machines
• A more maintainable code base, and a good core on which future developments can be built upon

Deliverables

This system is more of a backend/non user-facing component. As such, it is anticipated that most of the documentation required will be intended more for developers.

Expected outputs:

• Design for a future-proof Dependency Graph and Evaluation Engine
• Detailed design document detailing design decisions and explaining how the system fits together
• Implementation(s) of prototype systems
• A set of test cases which are commonly problematic in the old system (and which should work in the new system)
• Where relevant, user documentation (i.e. release notes) regarding any significant changes requiring user attention and/or care.

Project Details

At this stage, it is clear that aiming to having a completely functioning system completely integrated with the rest of Blender within the SoC period would be very difficult (if not impossible). Instead, this project will have a slightly more modest goal of figuring out what the core should be like by experimenting with common use cases, and establishing a good system that can be eventually integrated after the conclusion of the SoC period.

From various discussions and investigations into this project conducted so far, there seems to be general consensus that the following targets in some form or other are somewhat essential to tackle.

Technical Targets (see [1] and related pages for more detailed notes):

• Extended support for tracking dependencies across different data types
  • Primary target is still for scene (viewport, rendering, tools) usage
  • Secondary target is to allow extension to image types, and other related dependencies
• Finer granularity of dependency representation and evaluation scheduling
  • Primary targets include relationships between bones, drivers, and helper objects (e.g. Spline IK curves)
  • Secondary targets include non-interacting but overlapping dependencies (e.g. a.location -> b.rotation, b.location -> a.scale)
• A mechanism to support concurrent and/or efficient partial evaluations – (local storage?)
  • Primary Target 1: Multi-threading evaluation for faster playback/interface
  • Primary Target 2: Ability for render engines work threaded without conflicts from UI or other systems
  • Secondary Targets: Duplicators, Proxies (or selectively modifying aspects of multi-user data)
• Clean API for efficient/effective dependency queries
  • Primary target is to allow tools to query dependencies and ensure they’re updated correctly
  • Secondary target is for better UI update handling

Of the targets presented here, the first two are perhaps the ones likely to have the greatest impact on the freedom and flexibility of use that users will experience, and are perhaps the greater priorities. However, the last two are also pressing technical concerns, though they are also much more complex.

There are also some other related issues that are often closely tied in with the dependency and evaluation pipelines which have not been listed here (such as physics cache handling, time handling, and property updates flushing). However, these are complicated issues themselves, with little current consensus and/or expertise on hand regarding how to resolve the current problems present there. As such, for the initial stage in this project, it should suffice to focus on “just” the (rather meaty) technical goals mentioned above.

Bio

I’m a first year PhD candidate at the University of Canterbury, New Zealand, having completed a Bachelor of Science with First Class Honours in 2012. For many years now, I’ve also been an active developer (6-7 years) and Blender user (since 2003 – nearly 10 years now!). During this time, I have been responsible for a number of complex and large refactoring projects including a Constraints System refactor in 2007, Animation System refactor in 2009, and was a member of the Blender 2.5 taskforce (i.e. porting everything over from the old event system).

Links

[1] http://wiki.blender.org/index.php/User:Aligorith/Depsgraph_Limitations