Page MenuHome

driver does not update on frame jump
Closed, ArchivedPublic


System Information
Linux bubastis 3.10.25-gentoo #10 SMP Thu Jan 30 22:17:35 UTC 2014 x86_64 Intel(R) Core(TM) i7-4800MQ CPU @ 2.70GHz GenuineIntel GNU/Linux
01:00.0 VGA compatible controller: NVIDIA Corporation GK107GLM [Quadro K1100M] (rev a1) (prog-if 00 [VGA controller])

Blender Version
Broken: 2.70
Broken: git 08bf531956b1c1cff3319d119e8aba55b7a09b9e

A bone whose location, rotation and scale are controlled by drivers does not properly update immediately after a frame jump.

The shape of the cube in the soon-to-be uploaded .blend file is controlled by an armature whose middle bone has several drivers (position, rotation, and scale) based on the positions of other bones in the armature. The quickest way to illustrate the problem is to view the 3D model at frame 18, then jump to frame 1, then frame 2, then frame 1. Hopefully the problem is painfully apparent.

The drivers on bone "waist pre" are all Maximum based on a single variable which is itself a transform channel from the "head" bone. The variable is modified by a Generator with poly order 1 (linear).

One consequence is that if you start to render the animation (either from the command line or within the UI) if your frame_current is not identical to the first rendered frame, the shape of the cube could be wrong. The same risk exists if you skip rendering some frames (because they've already been rendered)

I'm not entirely sure if this is a bug in blender, or an oddity in the way these specific drivers are constructed.



Event Timeline

Robert Forsman (mutantbob) created this task.
Robert Forsman (mutantbob) raised the priority of this task from to Needs Triage by Developer.

This is a .blend file which appends a problematic armature and mesh from a larger project.

Joshua Leung (aligorith) closed this task as Archived.May 22 2014, 4:02 AM
Joshua Leung (aligorith) claimed this task.

This is a well known dependency graph limitation which cannot be fixed in current Blender. Specifically, with bones, the driver targets cannot be in the same armature or else the driven bones will not get the latest changes until after they've been evaluated.

Joshua Leung (aligorith) triaged this task as Confirmed, Medium priority.

is there a way to replicate this issue easily? I'm getting some counting error in a render and I'd like to know what's causing it.