Re: [Bf-committers] Drivers Delayed (Dependency Issue)
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 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@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Drivers Delayed (Dependency Issue)
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 > 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@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Drivers Delayed (Dependency Issue)
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 > 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@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers