[Bf-committers] Depsgraph proposal

[Lorenzo Pierfederici]

On Sat, Dec 24, 2011 at 9:17 PM, Nathan Vegdahl <cessen at cessen.com> wrote:

>
> 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?
>
>
Matt is right, there's so much more to dependencies than armatures and
bones.

Mine is an outsider perspective, but I've been playing with the depsgraph a
bit in the past.
I think that Blender already has the right level of granularity to build a
graph on, and it's the RNA properties. I even have a slogan for that:
"everything is a driver!" ;)

The RNA already has a defined set of types for input/outputs on the DAG
"nodes", and using it would make extending Blender easier and more
consistent, think about it: if it's mapped in the RNA it will work in the
depsgraph, no more special cases ever again!
And it would allow to generalize many of the different interaction between
objects that we have now, drivers wouldn't be needed as a special case and
constraints could be rewritten as DAG "node groups" allowing for unlimited
extensibility.

Performances might be a concern, but I think it's worth looking into
because the speed you lose in the common cases (constraints, parent-child),
might well be balanced by the gain for any customization for which you
don't need slow and unthreadable python scripts (but you could still use
them if you wanted to), or cycling over objects many times.

Lorenzo


>
> 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
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>