[Bf-committers] Depsgraph proposal

[Nathan Vegdahl]

> 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.

There are other purposes as well, such as allowing multiple states
(e.g. for different animation on multiple instances of a single linked
character).

But yes, I was under the impression that a proper fine-granularity
depgraph was part of the intent as well.  Then again, we never got Ipo
bags from the animation system re-write, which I thought was one of
the main intents of that.  I'm coming to accept that we only get 50%
of what we want with these re-writes, because we always seem to run
against limitations in other parts of Blender's architecture.

However, I agree with you.  If we want to really be future-proof
(inasmuch as anything is), we should do this as a fine granularity
depgraph.  It's just a matter of whether that is feasible or not...

Ton, can you elaborate on the technical hurdles involved in doing a
depgraph with a finer granularity than ID blocks?  Or perhaps point
someone else to this thread who can elaborate?

--Nathan


On Fri, Dec 23, 2011 at 3:57 PM, Matt Ebb <matt at mke3.net> wrote:
> 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
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers