Shape key driver influence is off

I’m trying to create a workflow for makehuman shapekeys. Out of the box, the rigify deforms aren’t always correct.
Here’s what I’ve done:

  1. Rotate the upper_arm.L bone
  2. Add a shape key
  3. Change the geometry
  4. Set the bones to rest
  5. Set the shapekey value to 0
  6. Add a driver
  7. Go to graph editor, select drivers, select the shape key
  8. Change the type to averaged value, select the armature then the bone
  9. Changed the type to: X rotation

Now, when the armature is at rest the shape key value is 1, when I want to be zero. Really I want the value to be something like: xrotation * (-10)

Any experienced riggers have some ideas as to what I’m doing wrong?
I tried world space, local space, and a number of other config changes. Feels like I’m just missing something simple. Here’s some screenshots to show the issue a little clearer. Thank you!

Try changing the Type to Scripted Expression and typing something like var * (-10) in the Expr box that appears.

Thank you, that got me MUCH closer. The upper arms movement is now definitely having an effect on the resulting value of the scripted expression, but not quite as expected. I’ve come to the conclusion that the var is not the x rotation of the upper arm, but some value connected to it. Can’t quite piece it together – do these numbers make any sense to you? Thank you so much for your time.

Try changing from quaternion rotation to euler rotation, that might do it. The quaternion rotation value isn’t the ‘real’ rotation value.

Having a bit more luck with euler, but I’m still banging on it – there’s something I don’t know. Some offset, some conversion between world and local, some little trick I’m not seeing, I am so close on this one. Any other tips or paths I could try? Having some success with formulas like value = (var-90)/180. The problem is that the incoming units are degrees and outgoing are 0-1, Now I’ve got no problem coming up with my own formulas, you’d have to for each shape key is different, but I am not getting reliable input. When I set the var = var *1, and set rotation to .1, the value should be .1 but it’s not. And it’s not even reliable constant. What am I missing?

You may have to change the euler rotation order as well. I tested it on my rig, and the only mode that worked well was YXZ euler. Set the expression to var again. Then, if you find a mode that works reliably, you can have the expression set as var and modify the Expanded Polynomial generator at the bottom. To make the shape key blend start faster you would change the value before the addition, and to make the blend happen faster when it has started you edit the x multiplier.

Finally figured it out, thanks so much for your help. I turned on the “Show debug info” and realized that even though the properties are showing the rotation in degrees, the driver is using RADIANS. So I wanted my shape key deform values to to be zero at about 10 degrees, and 1 at about 70 degrees, so convert the two points to radians and you get (.175,0) and (-1.22,1) Using the point slope method I came up with equation (var*-.717)+.125
It works perfectly. And it doesn’t seem to matter which euler rotation order I use.

In my mind, the devs should be consistent and show bone rotations in radians, or at least note the conversion in the interface. Who knows, maybe there is some reason they are doing it this way. And of course we all owe them a beer or two for an incredible job. Thanks again for the help, I would have given up without it.

Special thanks to Cyaoeu.

Oh, they are radians? Interesting… In the ‘old’ build I was using the degrees weren’t even displayed when using Show Debug Info. :ba:
Quaternions worked fine so you don’t have to use euler rotations. The last few posts I made were me being confused, but hey, glad you got it working!

Yeah, I’m using 2.65 which I think is the latest or close to it. I was actually convinced I was in gimbal lock as my parent bone was 90 degrees off Z. (Or should I say pi/2 off Z) Anyway, hope this helps someone else. Cheers.