[Bf-committers] Drivers Delayed (Dependency Issue)

Tobias Oelgarte tobias.oelgarte at googlemail.com
Sun Feb 20 10:50:31 CET 2011

Without trying to insult anyone: Please tell me a solution. How could i 
drive a bone depending on the animation of another bone without 1 frame 
lag? It seams to be impossible and makes drivers for bone-properties 
useless to me. (pointless feature)

What you describe is horrible. Why do we have dependencies for bones if 
they are not accounted for? Any combination without circular 
dependencies should be allowed to be evaluated in one frame without lag.

- Animation first is fine
- Drivers on object level are really ugly, they should be always 
evaluated last or in dependency order.

Why not update by dependency only (child/parent, driver/source, ...)?

Am 20.02.2011 10:29, schrieb 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
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

More information about the Bf-committers mailing list