[Bf-animsys] New depsGraph and rigging concept in blender

[Joshua Leung]

The biggest problem in that file is that currently all geometry evaluation
(ie. Modifiers and curve path stuff) still needs to go through the geometry
"ubereval" node.

Ubereval nodes are temporary kludges that we put in place so that we could
get the initial working version of the depsgraph out there for people to
start playing with. They work by basically acting as containers for the
"ob" or "obdata" evaluation blobs that the old depsgraph used to use. IIRC,
bone and object/transforms evaluation do not use those Ubereval nodes as
they have been fully granularised (with the exception of constraints, which
are currently done with a single node for the entire constraint stack per
object or bone instead of a single node per constraint).

* Issues such as these ubereval nodes (and the single constraint stack
nodes) are the reasons why the new depsgraph is still not enabled by
default. They are waiting on some work to resolve the problems of where to
store temporary results used between small operation nodes, which fits into
larger issues of what to do about instancing and proxies.

* I'll have to double check about that ubereval to bones link, but IIRC
that is largely a consequence of that ubereval lumping together too many
geometry ops. This meant that it's safer initially to say that all bones
depend on the result of that geometry evaluation.

* When the remaining issues with geometry evaluation are taken care of, the
curve path dep can be directly linked to the bone chains that actually need
it instead is going via init first.

* Also, for the cases that we need multiple groups of bones (from the same
armature) acting on the same points but with some of those bones acting
before others (useful for creating "layered" deforms,  where one set of
bones does the coarse body level deforms while a second set does skin
sliding and other fine detsils) , we've (Bassam, Zanqdo, and I) been
thinking about making the armature modifier restrict itself to only
handling the bones in a particular bone group, or with particular tags.
Using such mechanisms, the depsgraph can also get smarter about how it
links up interleaved pose evaluation and geometry evaluation.

There is still no need to throw everything out the window yet just because
a particular setup doesn't work yet!
On 30/08/2015 9:08 AM, "Boris Cohen Tanugi" <b.cohen.tanugi at gmail.com>
wrote:

> Hello !
>
> First, sorry for my english, hope to be clear enough.
>
> Here is the issue i met some days ago and want to talk about :
>
> https://developer.blender.org/T45903
>
> According to Aligorith's drawing, using spline IK whithin an armature
> still create a dependency cycle through Init Pose even with the new
> depsGraph.
>
> Thing is, there shouldn't be any dependency cycle here as bones
> controlling curves and bones controlled by the curve have no relation
> beetween each other (except being part of the same armature).
>
> Based on the idea that this armature container for bone is the issue (the
> reason why a general init Pose is need), i ll try to explain how it could
> possibly works (from other software concept).
> If i'm wrong with this statement, hem.. Have a good day (:
>
> In blender bones are part of an armature object wherease in other
> softwares (Maya/Houdini/Max, don't know about the others), bones are simple
> objects with special properties (mainly for skinning).
>
> Using this armature "container" offer many advantage, ie:
> - isolate all the freaking rigging things in one object
> - allow to have a special mode for animation (Pose Mode)
> - allow cleaner bone naming (not need of specific marker by character)
> - allow edit mode witch is so pleasant to use
> - can facilitate animation process (selection/mirroring/etc)
> - add here what you want !
>
> But create some issue too, compare to using simple "bone object":
> - this Init Pose...
> - Scripting bones (having to switch back and forth beetween object/edit
> mode while losing bone reference (we have to store name each time)
> - create non deforming bones where simple empty can do it
> - animate multiple rigs at the same time
> - add here what you want !
>
> Don't make me wrong, i love rigging in blender and that's my job since 4
> years now.
> Best of both world would be to keep the armature idea, avoiding the issues
> it causes. For now, having bones as object would make it unusable (due to
> the fixed layer number).
>
> Don't hesitate to correct me if i'm wrong, if you have better
> knowledge/good solution, or to open discussion (pyDriver/other rigging
> concept/cake recipe...) !
>
> Thanks for reading :)
>
>
>
>
>
>
> _______________________________________________
> Bf-animsys mailing list
> Bf-animsys at blender.org
> http://lists.blender.org/mailman/listinfo/bf-animsys
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-animsys/attachments/20150830/e0b2fcd4/attachment.html>