[Bf-committers] Drivers Delayed (Dependency Issue)

[Joshua Leung]

Incorrect analysis...
... and it's not really a bug by our tracker definitions either!

What is really happening is this:
- Animation is ALWAYS executed first (this is done per frame change,
not per update). This is before any data (namely "objects") get
evaluated. For the bones here, the values get written to the
pchan->loc/eul/quat/size/etc. vars at this point.
- Before updates occur (including frame change), the depsgraph only
tags objects with their "object" and/or "object data" needing updates.
- When updates occur, objects are evaluated by these block tags. In
this case, it means that the "pose matrices" (pchan->pose_mat), which
give the final transforms of bones (which you see in the viewport),
are calculated for all bones that an object has (in a single
pass/step) when the object has an "object data" tag
- Drivers for bones (strictly speaking, for PoseChannels, also known
via the PyAPI as PoseBones) and also for animation data are rooted at
Object-level. That is why you'll find the actions for posebone
animation attached to the Object-level AnimData block, as the Pose
data which contains the collection of PoseBones is attached to the
Object NOT Armature datablock.
- The practical implication for this story here, is that Object-level
data (including drivers) is evaluated before Object-data gets
evaluated (i.e. the Drivers will be run BEFORE any of the PoseBones
get evaluated)
- Rotational difference uses the pose matrices of the bones it depends
on (i.e. pchan->pose_mat)
- Hence, the phenomenon you see is all caused by the drivers reading
the last values they could find in the pchan->pose_mat's of the bones
it uses as input. Since the drivers are run before the pchan's will
get updated by being evaluated using newly flushed animation values
(and thus updating their pose_mat's), you will get a "lagging"
phenomenon.


On Sun, Feb 20, 2011 at 9:39 PM, Tobias Oelgarte
<tobias.oelgarte at googlemail.com> wrote:
> I made some tests with the drivers and found out that they are delayed.
> Actually they get evaluated first. Before the objects they are depending
> on are getting updated. Even if there is no cyclic dependency they will
> be first, getting the input of the previous frame, making them lag one
> frame behind the changes.
>
> I posted a bugreport yesterday, but the tracker seams to be down
> currently. Since i think, that this is a serious issue, i posted it also
> on this mailing list.
>
> I uploaded a very simple example to http://www.pasteall.org/blend/5309
> It contains a tiny armature consisting of one parent bone "base",
> followed by a chain of the bones consisting of "rot1" and "rot2". "rot2"
> is animated and will be used as the input for bone "driven", that is a
> child of "base". Last steps ensures that "rot1"/"rot2" are not depending
> on "driven". "driven" has a single driver that updates the location of
> the bone, depending on the rotational difference between "rot1" and "rot2".
>
> Ideally "rot2" would be changed by the animation first, then "driven"
> would evaluated. But instead the driver is evaluated first, ignoring the
> dependency.
>
> Greetings from
> Tobias Oelgarte
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>