[Soc-2013-dev] Weekly Report #1 Depsgraph Eval Refactor

Joshua Leung aligorith at gmail.com
Fri Jun 21 15:08:21 CEST 2013

Hi all,

== This week ==
For most of the week, I've been preoccupied catching up on a bit of
research work for uni (after being out of action for the better part
of 2 weeks following some dental surgery).

However, I did manage to spend some time earlier reading up on (and
making notes about) various reports and articles regarding some of
technical/design issues involved in dependency and scene graphs
(particularly those regarding 1) resolution/mitigation of
cyclic-dependency issues, 2) multi-user or data sharing issues, 3)
architectures for safe concurrent processing, 4) general architectural
and implementation details).

I've also been looking into some of the current limitations we have
with the current system (in particular, starting from the ones I'm
most familiar with or have been reported the most - such as
bone-drives-bone, spline-ik setups, rigidbody sim <-> object
interactions, etc.) and trying to think of potential solutions,
keeping in mind the implementation constraints we have on those (e.g.
for armature evaluation, we have the need to compute and free "IK
Trees" before evaluating the bones). From this exercise, I've got a
bunch of ideas for things we should/could be doing, and from there
it's mainly a question of trying to figure out how to get these to fit
together into an elegant "whole" solution, as well as checking on
potential pitfalls.

Finally, I've provided an overview of what IMO are the key goals /
areas / classes of issues we'll need to tackle to have a fully
upgraded depsgraph and evaluation engine. While it's very likely that
not all of these will be fully in place by the end of GSoC (given the
complexity/scope of some of these), it's good to at least be aware of
and thinking ahead towards these when laying the foundations for the
overall system.  See

== Next Week ==
Originally, I was planning on posting (wiki+blog) a bunch of short
posts about these various smaller-chunks as I worked on them (i.e.
basically, tidying up a bit my notes on various issues, and posting
them for greater visibility/documentation purposes for the community)
as I went. While I didn't quite manage to get these up this week, I'll
try to have them up ASAP over the next few days.

I'm currently working towards having an initial design proposal ready
by next weekend for review/feedback/consultation with key devs. This
will probably require some tweaks to address overlooked issues.

== Questions ==

These are mainly related to the sticky proxy/multi-user/duplis side of
things (i.e. where to store results, what/how much duplication of data
is ultimately needed, the actual technical challenges of actually
achieving such duplication without nasty performance side-effects,
etc.). We'll probably figure out something eventually (or at very
least, find a "least offensive" way that's better than the status
quo). At worst, this becomes something for "another day" (i.e. post
gsoc) to solve :/

Less urgently (at least at the moment) is the issue of svn
trunk->branch merges (or rather, how to not wait 6 hours for svn to
slowly spew errors and clobber my working copy, when an equivalent
update would only have taken 1-2 minutes tops). Any
volunteers/suggestions, let me know :)

That should probably be it for now... :)

More information about the Soc-2013-dev mailing list