[Bf-committers] Drivers Delayed (Dependency Issue)

[Tobias Oelgarte]

Why are bones are not treated like separate objects? Driven Shapekeys on 
objects are not lagging behind. Neither do Constraints. But on Bones 
anything (location, rotation,... , influence on constraints,...) lags 
behind. I think this is a big issue, since you can't drive a bone with a 
bone correctly, as long they are inside the same armature. So far you 
stated the reason for this behavior. I can follow the reasons and it 
seams correct to me.

But isn't this not a general design flaw? As far as i can see, anything 
should be handled in one dependency tree. Updating anything first, that 
does not depend on anything else. Bones should also be part of this tree 
and not be treated separately. Otherwise not "anything is animatable". 
At least not in a way you want to.

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
>