GSoC2013 T-Shirt and Certificate

This morning, I finally received my T-Shirt and Certificate for Google Summer of Code 2013 :)

When my schedule/workload allows (perhaps mid-November/December), I'll start looking into getting the new depsgraph <-> Blender integration work under way. In the meantime, back to the academic trenches!

Depsgraph - First Milestone Reached - Depsgraph Module Compiles!

I'm pleased to announce that the first milestone towards getting the new Depsgraph engine into Blender has finally been passed. As of a few minutes ago (4pm local time, 14th September 2013), the code I've been working on in a separate repo can now be dropped into the Blender codebase and compiled (*). Woohoo!

(*) Of course, a few caveats do still apply ;)

Depsgraph - Animato Integration

This post is another one from my archives which has been sitting around for a while, and concerns how exactly the Depsgraph+Evaluation system integrates (both currently and going forward) with the animation system.

Depsgraph - Transform Component Graph Building

Following on from yesterday's notes about the stages for how Pose Component graphs are constructed, this post covers the graph for the "Transform" Component. Once again, I've had these notes lying around for a while (in fact, this particular notes dates back from the start of August, and predates much of the current work that's in place now), and haven't really had time to scan them in or post them until now (BTW, I've decided to just split these up into smaller chunks for easier handling).

Depsgraph - Pose Component Graph Building Example

This is a just quick update with a scanned diagram showing the steps involved in building the depsgraph nodes for pose evaluation (and ensuring that this setup has dependencies hooked up correctly to enforce evaluation order constraints for the scheduler).

Depsgraph – Mid-Term Updates and Revised Design (“Components”)

Over the past few weeks, there have been relatively few updates about the status of the Depsgraph Refactor project, apart from the regular weekly updates (which have been admittedly a bit vague). That's because I've been busy actually hacking away at it! There's only so much time in a day (or rather, after sleep and research work commitments), so regular blog post updates have taken a bit of a back seat for a while. Nevertheless, today I'll be presenting a little overview of what's been going on, and where we're going now.

Components - The "key" to the new design

Depsgraph - Overview of Design + Goals

Phew! I've just finished writing up a doc giving a rough overview of where we're going with the depsgraph design, and the types of things it aims to do (i.e. problems it should solve, etc.). There may be a few things I've glossed over here and there (and it may ramble a bit at the start a bit), but it should go a long way towards explaining what's going on.

Check out (and join) the discussion and document (check the attachment there) over on the bf-animsys mailing list:

http://lists.blender.org/pipermail/bf-animsys/2013-July/000103.html

Depsgraph - Optional Branches with Runtime Switches

One source of confusion for beginner riggers sometimes is that even though a particular dependency path may not actually be currently active, from the perspective of the dependency graph they are still actively contributing to a cyclic dependency situation. Much of this is due to the fact that the old depsgraph could only really schedule things up by looking at the full set of dependencies and create a static ordering that could work in all cases.

This post explores a potential solution to this problem and how it could be integrated into the framework we've been looking at. 

Depsgraph - ID Groups

In this post, we take a second look at one of the issues from the Granularity Problem: that of “strongly connected components”. That is, a set of nodes which, for all intents and purposes end up referring to each other.

Depsgraph - What's in a Node?

Our previous idea about how to solve the granularity problem raises an important question: What exactly should nodes in this system look like? What do they represent?

Depsgraph - The Granularity Problem

In today's post, we look into one of the problems affecting Blender's current Depsgraph: the granularity problem (also known as the “Why can't I use a bone as a driver for another's constraint influence?” problem). Another related problem arising from this is the “phantom cycles” problem (i.e. the, “Huh? It keeps telling me there's a cyclic dependency here, but these things aren't even related!?”).

Depsgraph - Know thy enemy

As promised in my weekly report yesterday, this is the first in what will be a series of posts documenting various thoughts and snippets of ideas during the development process for a new Dependency Graph engine for Blender.

As well as serving as rolling documentation of the ongoing work and how various design "quirks" (as they'll inevitably be viewed in retrospect) came about, these posts aim to serve two other important roles. From the perspective of the wider community, it provides greater visibility for this project and/or progress made, which may otherwise be difficult to grasp (since it is not really a flashy front-end tool that users can directly hold in their hands). However, more importantly, writing these posts mainly helps/forces me to really flesh out some areas of the design which I may otherwise forget or gleefully gloss over when a suitable solution comes around. It has been said by many notable people (including various scientists, engineers, and academics) that the act of writing down your thoughts can help clarify and refine those ideas, by forcing you to figure out how to express them in a concise manner (and in the process clarifying/resolving ambiguities), thus moving these from merely nebulous figments of your imagination to somewhat physical (or concrete) entities.

So, welcome along for the ride, as the great Blender Depsgraph project gets underway at last.

(Note: some of these posts have been sitting around for a while now – with delays and other things getting in the way – so dates mentioned are somewhat inaccurate).

The Depsgraph Refactor Project

It's official, the great depsgraph refactor is under way at last!

This diagram shows some of the key components or classes of issues that we'll need to be tackling with this system to get it in shape for the types of things we need from it. Orange are for issues that will have direct impact on users (i.e. stuff will now work better and faster), Grey is stuff that is mainly useful for BlenderDevs when writing tools and other stuff.

The Bluish box (i.e. looping over objects-datablocks, and evaluating updates by going downwards from there is a slightly contentious point. IMO we need to do this or else we can't really achieve the generality and granularity objectives - we'd effectively still be stuck in the stone age (where we still end up keeping some ever-bizzare restrictions). The full details of what exactly should replace it though is something that's still heavily WIP, but I do have some preliminary ideas I'm currently toying with.