[Bf-committers] Depsgraph proposal

[Nathan Vegdahl]

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

That's a very good point.

I'm still curious what the development hurdles are to do this, though?
 Is it really prohibitively difficult, using e.g. RNA instead of ID
blocks for the dep graph?
Or maybe we could figure out a development roadmap that gets us some
of the stuff right now (e.g. multiple character instances with
different animation), but done in such a way that it will be
migrateable to an RNA-based depgraph in the future without losing all
that work?

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

Possibly.  I'd rather see constraints get their own node system,
though, with more of a data-flow paradigm:
http://storage.cessen.com/temp/examples_of_good.png
Making them part of the normal dependency DAG imposes limitations e.g.
like Maya has:
http://storage.cessen.com/temp/examples_of_bad.png

Same deal for modifiers.

Of course, any new node system would have to integrate into the
dependency graph to some extent anyway, for proper updating.  But I'd
rather keep the depgraph limited to that purpose.

--Nathan


On Tue, Dec 27, 2011 at 2:06 AM, Lorenzo Pierfederici
<lpierfederici at gmail.com> wrote:
> 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
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers