[Bf-animsys] Depsgraph refactor progress

[Sergey Sharybin]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-animsys/attachments/20150129/f33baec4/attachment.html>