[Bf-committers] Drivers Delayed (Dependency Issue)
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
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 tobias.oelga...@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@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 tobias.oelga...@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@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 tobias.oelga...@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@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
