[Bf-committers] Depsgraph proposal

Matt Ebb matt at mke3.net
Sat Dec 24 00:57:09 CET 2011


On Fri, Dec 23, 2011 at 7:49 PM, Nathan Vegdahl <cessen at cessen.com> wrote:

> let's at least not pretend that "detect cycle + call x
> times" is a real solution to granularity issues.  Blender will still
> have a granularity issues with it's dependencies, it will just be
> pushed x levels down (at a performance cost of x).


When the idea of a 'depgraph project' was first announced, I thought that
this was exactly what was going to be tackled. IMO lack of granularity is
the single greatest problem with blender's dependency system as it stands -
much more important than things like lack of threading. It's not just a
problem for character animation, but has far-reaching consequences for the
rest of blender too (eg. bad physics behaviour, dodgy 'collision modifiers'
etc).

I realise it's probably a very difficult problem to solve internally, but I
wonder if it's really worthwhile to be spending the resources on a redesign
here if this issue isn't seriously addressed.

For some of these other non-character animation problems where data needs
to be depended on and accessed at different points in the evaluation chain,
not just after final evaluation, I'm not sure they even can be solved by
re-cycling several times (correct me if i'm wrong!), since what's needed
for these tasks is access to and control over how data is transferred and
evaluated through the system.

These limitations also cause roadblocks for further tools from being
developed such as node based modifiers, better physics systems like node
based particles, node based animation/contraints. In modern cg and fx,
animation is not just objects or bones moving around any more, it's complex
procedural geometry creation and animation, scripted variable expressions
and relationships, data flow connecting separate systems like physics
solvers. I really think if this depgraph project is intended to set blender
up for the future, it needs to do more to acknowledge and prepare for these
sorts of functionality, even if it's not possible to implement them all
right now.

cheers

Matt


More information about the Bf-committers mailing list