Page MenuHome

Wrong evaluation of Action Constraint
Closed, ResolvedPublic


hash: 2aff243

I've uploaded a sample blend file.

The action constraint evaluated in the scale transform is giving wrong results.

As you will see in the blend file, bone_3 has and action constraint that is triggered with bone_2 Y scale in local space.

If you rotate or scale Bone_2, you'll notice that the action is triggered randomly. Even if you rotate or scale Bone_1, which is the parent of Bone_2, action will be strangely triggered. Location transforms does not seem to trigger the constraint.

Event Timeline

Juan Pablo Bouza (jpbouza) created this task.
Juan Pablo Bouza (jpbouza) raised the priority of this task from to Needs Triage by Developer.
Bastien Montagne (mont29) triaged this task as Confirmed, Medium priority.

Nah, the action is triggered correctly. The issue is that, near Y-scale 1.0 of bone 2, there is a strange glitch that sort of mirror bone 3 along its Y axis…

I'm having the same problem. It seems there is something quite wrong with how blender assesses drivers at the moment.
I've attached a comparative screenshot showing the same file in Blender 2.70 (211f08d) and Blender 2.69.
In this case it's not an action constraint, but a shape key driven by the Y scale of a bone.

BTW, I tested jpbouza's file in 2.69 and the bug isn't present.
I also just rebuilt Blender and can confirm that the bug is still present in eaf387b. Also the bug shows up in renders.
This is a major problem and means that the current version of Blender is not production ready for riggers and animators.

Campbell Barton (campbellbarton) raised the priority of this task from Confirmed, Medium to Unbreak Now!.

note: when scaling Bone_2 in action_bug.blend I get an assert fcurve_eval_keyframes(), at 'a > 0'

also @Beorn Leonard (freen) - could you upload this file with the driver issue?

Ok... excuse the size (it's 3.4Mb)

If you open the attached file in 2.69 and 2.70 you can see the bug quite clearly.

@Juan Pablo Bouza (jpbouza) - the bug is caused by the assert,

looks like this but isnt in 2.70rc2 and wont effect the release. (removing from Blender2.70 project)

Campbell Barton (campbellbarton) lowered the priority of this task from Unbreak Now! to Confirmed, Medium.Mar 18 2014, 11:15 AM

Alright, let's firstly clarify the situation here a bit first:

  • This issue does not affect 2.70 (I'm specifically referring to the RC's and the release which is pending but hasn't quite landed yet)
  • 2aff243 is perhaps the only commit that has introduced changes in this area - indeed, that's exactly the revision that @Juan Pablo Bouza (jpbouza) noted (though I'm not sure whether that was by chance :)
  • The assert that campbell noted is in fact something I put in during the commit to help look out for situations where it looked like it probably would fail, but I couldn't confirm yet whether it would in practice (from the look of things, it looks like it does fail on a good number of files in the wild!)

I just checked my file in 2.70 RC2 and can confirm the bug isn't there.
Not sure how the RCs work, but the last build where I saw the bug was eaf387b, which I downloaded and built as I posted my first comment.

I've made a few fixes which resolve the issues seen in the test files here. Please check on other files whether these issues still occur (in 22ab652 onwards).

If there ARE still any issues, run Blender in debug mode (./blender -d) and paste the output here along with the offending file(s). I've left in some debug prints for now to help generate some diagnostics if this goes wrong still :)

Works for me. Thanks aligorith!

Yep, seems to be working for actions too! :)

Mmmmmm ok... I don't quite get how this hash thing works yet...

I downloaded c17acf1 19 Mar 5:02 - the issue was solved

But in d2660a0 19 Mar 12:20 - the issue is present again!

How come?

Mmmh… not sure about what you mean with "downloaded"… ;)

If you are unsure, best thing is probably to wait tomorrow and test this night's builds from :)

Ok ok, I'm almost sure that I downloaded both builds from there... but we'll wait then...

Oh boy... I still see the bug in 2.7 official... It seems fixed in the sample file I uploaded, but it is not fixed in my complex rigs.... I'll try to debug the rig a bit and see when it happens...

Ok, my mistake, it's not in official 2.7 (I should start compiling again instead of getting messed up with the buildbot :s )

in aee3018, the issue effect of the issue seems to have changed a bit but it is still there. I'm attaching a new sample file where I tried to narrow a bit the problem

_ The bug seems to happen only when there are scale keys in the action.

_ It seems to happen only when there is more than 2 keys

_The issue also depends on the values of the min and max fields in the action constraint. Change those numbers and you'll see that with some combinations the bug disappears.

Hope this helps!

Damn... Reopening this bug report. Now we have another failure where it seems that for whatever reason the curve doesn't get evaluated correctly a fraction past the keyframes at 1.0.

See attached image:

Hopefully things are better now. This time, if there are still issues, it should be just a matter of tweaking a threshold until things start behaving nicely. Hopefully that won't be needed, as increasing that threshold decreases how fine grained you can make your custom fcurves (as it affects the minimum distance between keyframes where they will still be considered different).

I've made up my mind and started compiling blender again, hehe.

Problem solved Aligorith!

Joshua Leung (aligorith) edited this Maniphest Task.

From T40332 (nothing new, only a screenshot)