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

[Ton Roosendaal]

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