<p dir="ltr"><br>
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.</p>
<p dir="ltr"> 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).<br></p>
<p dir="ltr">* 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.</p>
<p dir="ltr">* 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.</p>
<p dir="ltr">* 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. </p>
<p dir="ltr">* 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.<br><br></p>
<p dir="ltr">There is still no need to throw everything out the window yet just because a particular setup doesn't work yet!<br>
</p>
<div class="gmail_quote">On 30/08/2015 9:08 AM, "Boris Cohen Tanugi" <<a href="mailto:b.cohen.tanugi@gmail.com">b.cohen.tanugi@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hello !<br><br></div>First, sorry for my english, hope to be clear enough.<br><br></div>Here is the issue i met some days ago and want to talk about :<br><br><a href="https://developer.blender.org/T45903" target="_blank">https://developer.blender.org/T45903</a><br><div><br></div><div>According to Aligorith's drawing, using spline IK whithin an armature still create a dependency cycle through Init Pose even with the new depsGraph.<br><br></div><div>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).<br><br></div><div>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).<br></div><div>If i'm wrong with this statement, hem.. Have a good day (:<br><br></div><div>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).<br><br></div><div>Using this armature "container" offer many advantage, ie:<br></div><div>- isolate all the freaking rigging things in one object<br></div><div>- allow to have a special mode for animation (Pose Mode)<br></div><div>- allow cleaner bone naming (not need of specific marker by character)<br></div><div>- allow edit mode witch is so pleasant to use<br></div><div>- can facilitate animation process (selection/mirroring/etc)<br></div><div>- add here what you want !<br><br></div><div>But create some issue too, compare to using simple "bone object":<br></div><div>- this Init Pose...<br></div><div>- Scripting bones (having to switch back and forth beetween object/edit mode while losing bone reference (we have to store name each time)<br></div><div>- create non deforming bones where simple empty can do it<br></div><div>- animate multiple rigs at the same time<br></div><div>- add here what you want !<br><br></div><div>Don't make me wrong, i love rigging in blender and that's my job since 4 years now.<br></div><div>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).<br><br></div><div>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...) !<br><br></div><div>Thanks for reading :)<br></div><div><br></div><div><br></div><div> <br></div><div><br><br></div></div>
<br>_______________________________________________<br>
Bf-animsys mailing list<br>
<a href="mailto:Bf-animsys@blender.org">Bf-animsys@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-animsys" rel="noreferrer" target="_blank">http://lists.blender.org/mailman/listinfo/bf-animsys</a><br>
<br></blockquote></div>