[Bf-animsys] Depsgraph refactor progress

Fri Jan 30 05:58:33 CET 2015

Hi Aligorith!

The offending constraints are the Transformation constraints that are in "carpal_ik_L and R". I used that constraint as a very dirty trick to give the IK bone an initial rotation, different to the rest pose (instead of using a driver or manually rotating it). Anyway, you don't need to remove them, just change the target from "forearm_L and R" to "master". That should fix the cycle.

The cycle in the head was trickier and required some changes... I discovered it a while ago in another rig and I fixed it. If you want I could chase it again... but I don't know what the point of investing time in Koro would be... Victor and Franck have newer and improved versions of the same basic rig. So, If the Blender Institute would like to maintain Koro for the next versions of Blender, I would have to fix all these and release a new version, but it is definitely not worth the effort to keep testing that rig with the depgraph refactor branch.

From: aligorith at gmail.com
Date: Fri, 30 Jan 2015 17:26:43 +1300
To: bf-animsys at blender.org
Subject: Re: [Bf-animsys] Depsgraph refactor progress

I guess I should respond/comment about a few of the points raised here:

Regarding Daniel's points:
I tested his file earlier, and the animation seemed to be working (at least on the main rig). The only errors I did run across there were that it was trying to add animation links whenever it encountered animdata, even if there were only drivers present.

(EDIT: After retesting again while writing this reply, I discovered that the animation will be broken here if the transitive reduction is removed. Specifically, the bones will animate, but the geometry won't deform)

Regarding JP's points:
Aarrrggghhh!!!!  

Chasing down the bugs in that file has been so tricky!   (NOTE: Removal of transitive reduction again breaks that rig here). Which transform constraints exactly are the offending ones we should be removing?

Other notes for testers:
- Rigidbody support "should" be working with the new depsgraph. 1-2 weeks ago I went through ensuring that all the necessary links are at least getting created for that, but I'm not sure if any of the rigidbody constraints stuff or integration with other constraints/parenting using the results or influencing the sim are totally working yet.

- As Sergey mentioned though, the rest of the physics integration (specifically anything particles related) is really hit and miss. It really hasn't been hooked up, so, apart from some things working (via the placeholder uberevals), it shouldn't be doing anything.  Prime example of this is that the background specs/floating stuff in the Caterpillar file from the Gooseberry teaser don't work  by and large.

- Regarding the graph visualisation output stuff we try to use for debugging, here are a few words of hard-earned wisdom to save some pain:
1) For "Graphviz" Exports (.dot), only use "dot" on very very simple graphs. This way of showing the graphs will give you the clearest idea of what's going on, but it will crash or output gibblish on cue if given something even slightly more detailed

2) Again for "Graphviz" Exports: If "dot" fails, use "neato" instead. But be warned that neato doesn't always produce graphs which make much sense (heaps of overlaps), and could well take 20-30 minutes for some rigs at least.

3) The experimental OGDF/GML export doesn't currently have a working layout engine attached, but it does output basic node + relationship info.

4) For difficult to visualise graphs, it is possible to import the .dot or .gml files into "Tulip" to visualise them with various different algorithms until one of them manages to wrangle it into shape. Be warned though that it doesn't show directed arrows, and it also lacks most of the context information, so it may still be difficult figuring out what's going on.

On Fri, Jan 30, 2015 at 2:15 PM, Juan Pablo Bouza <jpbouza at hotmail.com> wrote:

Oh poor sergey! Man you should have asked me about Koro so I could help you debugging.

Yep, that rig has 1 dependency cycle in each of its legs (the transformation constraint), and I think that it also has one in his head, haha. But well, somehow it worked ok cause those cycles were never actively in use, as some drivers turned on and off some constraints which avoided the cycle, functionally. So I guess that that is why the rig just worked and those cycles never popped up when we were animating the rig.

By the way, the cycles were not intentional... you know, I did the freaking rig in like 2 days, hehe.

So, now I've also tested Victor, which basically has the same basis as Koro, and as you say, it works perfectly well. So you've done a great job! I would say that you have nothing else to solve regarding these testing rigs, as the problem with koro was a rigging fault.

I did test playback speed and these are my results with Victor:

Armature only playback: 60 fps vs 36 fps (refactor branch)

High resolution character playback: 35 fps vs 20 fps (refactor branch)

Proxy character playback: 49 fps vs 24 fps (refactor branch)

I did the benchmark inserting keys in several controllers.

The good thing is that I also tested driving some "distance" value of a limit distance constraint, with the scale of a bone and it worked like a charm!

Keep up the good work guys!

From: zanqdo at gmail.com
Date: Thu, 29 Jan 2015 16:00:59 -0600
To: bf-animsys at blender.org
Subject: Re: [Bf-animsys] Depsgraph refactor progress

I've tested on my current Tara rig and it works perfectly! Congratulations to all involved! The only thing failing is the actual playback of the animation. Can't say anything about speed yet because of that :)Daniel Salazar
patazstudio.com

On Thu, Jan 29, 2015 at 9:09 AM, Sergey Sharybin <sergey.vfx at gmail.com> wrote:
Hi,
Just a quick update on the happenings in depsgraph_refactor branch.

= Status overview =
So far we've been focusing on having interleaved drivers and armature bones updates and didn't pay much attention to other aspects. So:

- Meshes/curves/metaballs are ported to the new dependency graph practically without visible changes. There are some underlying changes which would allow moving blender to fully node-based system, but those parts are basically NO-OPs currently.
-  Armatures takes really long time to deal with. Basically the status is: simple rig works, complex ones needs more investigation and some design decision we need to do (read about that later). Armatures supports interleaved updates, which means it is possible to have drivers/constraints between different armatures and have proper updates without lags.
- Dupligroups nad proxies are not currently supported. They basically needs to be re-implemented in the new system. I'm currently looking into this.
- Rigidbodies, simulations and so might work by co-incident, but they'll need to be revisited, because there was some code from Lukas in there but depsgraph changed a lot since then and things might not be working as expected now.
- Animation/drivers are expected to work, supporting more interleaved behavior (this mainly applies to drivers, animation does not have dependencies).
- Layer visibility (when object appears visible on the layers) shouldn't have lag now. I'm not totally happy with the current implementation of this in the branch tbh, but it's simple to make it nice and clean using Brecht's idea of changing a bit logic around LIB_RECALC flag.
- Depsgraph building is now quite slower, but we didn't invest time into optimizing it. Evaluation might also be a bit slower because of more granular operations which increases overhead of task system. This will be reviewed after all the features are working in depsgraph.
- Cycle detection and solving needs to be implemented for the new system. Was looking into it this week, but didn't quite finish yet.
Think this mainly covers the state of the branch. Now, why it's not moving much faster you might wonder. That's basically because issues with rigs are really tricky to investigate (trying to find out what exactly is wrong in rig with 1K bones...),
= Testing =
While it is known that complex rigs might fail (for example, Koro rig doesn't fully work) other rigs are just rock-solid now (Victor from gooseberry, agent from the agent short movie) it would help if someone will test more right and if they fails minimize them as much as possible (to few bones only, so it is clear what's going on). Such a minimization process took really log time from us, so having small correct rigs which doesn't work would really help. Correct in terms there's no unsolvable cyclic dependency i.e.
= Constraint targets =
For until recently we tried to make it so constraint targets are using final bone transformation (after parenting + constraints + solver) which what we understand from initial riggers feedback what's needed. However, some existing rigs seems to be using some constraint expecting them to do opposite -- use pre-solver bone transformation.
Basically that's the exact stopper for armatures atm -- understanding what transform riggers actually want to work with.
So, let's start this question again: when you're using bone as a constraint target, which transform you expect to be used?
-- 
With best regards, Sergey Sharybin

_______________________________________________

Bf-animsys mailing list

Bf-animsys at blender.org

http://lists.blender.org/mailman/listinfo/bf-animsys

_______________________________________________
Bf-animsys mailing list
Bf-animsys at blender.org
http://lists.blender.org/mailman/listinfo/bf-animsys 		 	   		  

_______________________________________________

Bf-animsys mailing list

Bf-animsys at blender.org

http://lists.blender.org/mailman/listinfo/bf-animsys

_______________________________________________
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/20150130/fc97c66b/attachment.html>