[Soc-2013-dev] Weekly Report #2 Depsgraph Refactor

[Nathan Vegdahl]

> Here's what I think are the key requirements:
>
> - Allow dependencies between bones and objects (at least inside group)
> - Handle dependencies of (non-Object) RNA data drivers well
> - Solve our problems with duplicators and proxy usage
> - Make it optimal threadable

I think you've hit upon two of the three important things for this
depsgraph rewrite:
1. The limitations that immediately hurt us with the current depsgraph
2. Simplicity and understandability of the design

But there is a third one that (and I could be wrong about this) it
feels like you're down-playing:
3. Generality and extensibility, so that we lessen our chances of
running into future limitations

I agree, of course, that generality should not come with the expense
of an impossible-to-understand design.  And there's a danger of going
too far and over-engineering the solution for the sake of things that
may never happen.  But it's still important.  If we design the
depsgraph with only the current feature-set of Blender (plus a couple
of planned features) in mind, we are likely to end up with a design
that is difficult to adapt to future developments, and we'll just have
to do this all over again.

There is a balance to be struck.

However, back to lists of things that should be possible with the new depsgrph:
- Multiple object's animation within a single action (technically
possible right now, but it doesn't evaluate correctly).

As far as I understand it, the depsgraph is the main reason this isn't
really possible right now.  I've outlined many times before the
use-cases that are awkward without this (mostly involving NLA
workflows and animation baking), but I can list them again if needed.
It's also trapping us in an armature-centric animation workflow, which
is a hindrance to potentially innovative new developments in the
future.  If at all possible, I would like the new depsgraph to be
designed to allow for this, so that at some point this workflow can be
added to Blender.

--Nathan


On Sat, Jun 29, 2013 at 10:22 AM, Ton Roosendaal <ton at blender.org> wrote:
> Hi Joshua,
>
> It's certainly a very detailed research there already. I spent an hour on reading it, and it would more time to digest the full flow of though processes.
>
> What we should prevent though is to have too much complexity here. So I'd like you to set the analysis aside for a moment and think about the actual requirements we aim for.
>
> BTW:
> Requirements: the goals we to achieve
> Specifications: how to realize this
>
> For example, I'm not so much convinced yet if a fine granularity is even a good requirement. Blender's current design in ridid blocks is just a given fact (with its drawbacks), we should and still can live with that.
>
> Also the cycle solving issue is could be treated by allowing riggers/animators sufficient ways to prevent this - for the useful cases. If you can achieve an animated result avoiding cycles, cycle solving is really secondary.
>
> I really believe in simplicity here too - which would benefit threading in the end too. The larger the 'blocks' or jobs, the better.
>
> Here's what I think are the key requirements:
>
> - Allow dependencies between bones and objects (at least inside group)
> - Handle dependencies of (non-Object) RNA data drivers well
> - Solve our problems with duplicators and proxy usage
> - Make it optimal threadable
>
> Ease of use, speed. And keep it very simple. :)
>
> If a user makes weird cyclic dependencies (like material color changing a bone position that drives an lamp that changes material again) you just don't have to support this. That's where post-evaluation scripting hooks can work too.
>
> -Ton-
>
> --------------------------------------------------------
> Ton Roosendaal  -  ton at blender.org   -   www.blender.org
> Chairman Blender Foundation - Producer Blender Institute
> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
>
>
>
> On 28 Jun, 2013, at 16:03, Joshua Leung wrote:
>
>> Hi All,
>>
>> == This Week ==
>> I spent most of the week polishing/writing up a bunch of notes about
>> various fragments/topics about various design issues and
>> considerations. Links to these are included at the end of this report,
>> and are also linked from the main wiki page (TODO: copy over the
>> contents to wiki pages; I'll probably leave this for September, when
>> I'll almost certainly be fully occupied by a paper submission
>> deadline).
>>
>> In the process of writing these, I now have a clearer perspective on
>> some aspects of the design which had previously still been quite
>> fuzzy/tricky to pin down (notably, how exactly to group/keep track of
>> links between coarse and fine grained nodes).
>>
>> As an added bonus, we now finally have a nice intro to how the
>> internals of the armature evaluation process works (at last! - and
>> just before it's soon to get a good shake-up), and some annotated
>> reading material for anyone getting into this (dependency graph) work.
>> :)
>>
>>
>> == Next Week ==
>> I'm currently aiming to have an initial design doc/proposal (maybe not
>> fully fleshed out with regards to a few areas) outlining the general
>> direction of the system design ready by the end of this weekend (+/-
>> 1-2 days). Core devs (and in particular, those involved with the
>> various physics sims) and riggers are strongly encouraged to have a
>> good look and try to pick up any problems which we may run into. At
>> this stage, I'll probably be posting this to the main developers list,
>> though it might be better to move/hold the discussion on the
>> bf-animsys (http://lists.blender.org/mailman/listinfo/bf-animsys)
>> list, which was originally set up for discussions about animation
>> system stuff during early 2.5 days.
>>
>> I'll also start prototyping/mocking up the core data-structures/API's
>> for implementing the proposed design. Hopefully I won't encounter any
>> significant roadblocks here requiring a serious rethink about where we
>> go with this. It's always a possibility though with something like
>> this.
>>
>> Depending on how I go for time, more likely than not, I'll have a few
>> more posts up examining some of the trickier issues (e.g. physics
>> integration, layer-update stuff).
>>
>>
>> == Questions ==
>> Which list should we hold feedback/discussions about the design on?
>> bf-developers/committers or bf-animsys? In any case, I'll probably
>> just cross-post the initial link(s) across both.
>>
>>
>> == Links ==
>> In chronological/logical order:
>> * http://aligorith.blogspot.com/2013/06/depsgraph-know-thy-enemy.html
>> * http://aligorith.blogspot.com/2013/06/depsgraph-granularity-problem.html
>> * http://aligorith.blogspot.com/2013/06/depsgraph-whats-in-node.html
>> * http://aligorith.blogspot.com/2013/06/depsgraph-id-groups.html
>>
>>
>> Regards,
>> Joshua
>> _______________________________________________
>> Soc-2013-dev mailing list
>> Soc-2013-dev at blender.org
>> http://lists.blender.org/mailman/listinfo/soc-2013-dev
>
> _______________________________________________
> Soc-2013-dev mailing list
> Soc-2013-dev at blender.org
> http://lists.blender.org/mailman/listinfo/soc-2013-dev