How do I fix the shoulder with shapekeys in 2.55?

Support Animation and Rigging
1

Hello,

My question is simple: how do I drive shapekeys in 2.55 ‘the way’ I can do in 2.49?

I tried to follow this tutorial on an elbow: http://www.blendercookie.com/2010/03/10/working-with-shapekey-drivers/

The driven shapekey with Transform Channel as variable works well with ‘direct’ rotation but when I add the IK constraint, the driver doesn’t work anymore, though it works on the video. Is it a bug?

With some help, I finally used the Rotationnal Difference as variable and it works with the IK constraint. It works well because the elbow only rotate in one axis (from 0° to 150° on Z)

But now I have a problem: how can I do now for the shoulder which needs 4 driven shapekeys, X -X Z and -Z? The Rotationnal Difference doesn’t look at the axis so how can I ‘tell’ it which axis it must follow to drive the shapekey?

Thanks

2

Here’s what I was playing with last week. I created a shapekey for when the arm bone was rotated down on it’s x-axis and it works just fine. If from top view you rotate the arm forwards, on it’s y-axis the shapekey doesn’t work, which is good as the bone doesn’t have any x-axis rotation. The problem I encounter is when you rotate the arm downward on it’s x-axis, then rotated forward from the side view. The bone now has y & x rotations so the shapkey is working, but since it looks like the same pose as just rotating the arm forward from top view, I don’t want the shapekey to work.

To solve that problem, I used a scripted expression driver, seen here:

pic5.png592×641 37.6 KB


Which works just fine, when the arm is rotated downward, then forward from the side view, the shapekey turns off, as it should.
example.jpg1024×362 39.6 KB


However, if you rotate the arm upwards a bit more from side view, the x-rot value increases at a very fast rate and the scripted expression no longer gives the desired results.
pic4.png1016×704 189 KB


So I began to read up on python drivers, thinking I can use an ‘if…then’ python expression to keep the x-rot variable from never going above 90 degrees of rotation. I’ve never set up py drivers, and I’m even unsure if this would work, but that’s the direction I’m working in.

Setting up shapekey drivers for the x rot and y rot is easy to handle, but if the bone has both rotations, shown in my 2nd pic, then both shapekeys would be on, which isn’t what is desired. I got frustrated with trying to figure out the py drivers, and haven’t got back to trying to get them to work again. I thought about posting for help on this subject, but want to try setting up the py drivers again before I ask for help.

If anyone has any insights, please share them…
Randy

3

Thanks for your reply and sorry for the late answer.

Actually, my problem is a little more ‘simple’:

There are too screenshots. On the first (err… the one where the driver works…), if I rotate manually the elbow, the driver works fine. On the second, I setted the IK constraint to 1 and you can see that the driver doesn’t work anymore.

I found a way to fix this problem for the elbow with the Rotationnal Difference. Ok, but for the shoulder, that will obviously not be that easy.

If I understand correctly, your technique is more to avoid a mix between 2 driven shapekeys, but does it works if you set an IK chain? That’s finally my main problem.

Attachments

shapekey_255_002.jpg755×1024 123 KB

shapekey_255_001.jpg755×1024 123 KB

4

Howdy,

I’ve noticed the same thing with drivers when IK is involved. The driver values don’t update. There is a good article on algoriths blog about the order in which things get processed … I’ll hunt it down and edit later.

a perhaps quick and dirty option i’ve used for elbows shoulders etc is shrinkwrap an elbow vertex group to a sphere like object on the joint.

5

Yes, I was looking into a method to avoid 2 shapekeys being on at the same time. Now I understand your problem, I’ve seen few use ‘rot difference’ to get around this in some areas. Not sure about shoulders. I found while trying to figure this all out, if you uncheck ‘local space’ it works just fine with IK chains.

Not to step on batFinger’s toes, but I just found the article he speaks of today. It’s located here and indeed if you read down the page:

The “Local Space” option is one that I think needs a bit of explanation, as there are a few gotchas there, especially relating to rotation:

  • In general, the “Local Space” option takes the transform properties that the ‘Single Property’ variable type has access to, instead of using the final constrained location. Thus, stuff like IK is ignored when using this.

I stumbled upon this when working on my Joe_Rig character, the drivers on fk bones worked just fine in fk mode, but once the arm was switched to ik, where the fk bones copy the rotation of the ik bones, it didn’t work. Turn off ‘local space’ on the driver, and it worked in ik just like in fk.

The whole webpage is worth reading, so much so, I bookmarked Aligorith’s blog because now I see the amount of information he’s putting up about the new animation system. Afterall, the best place to find information on the new animation system is from the person who wrote it…

Randy

6

Well, what I can say is that it does not work. At least not here, on my computer (Imac, OSX 10.6.5) and Blender 2.55 beta rev33433 64bits.

Here’s an example with a driven shapekey I try to set on the torso bone named ‘chest1’ on rot X from 0 to -0.460. I works well with local space enabled.

If I turn it off, it does not work anymore, with IK constraint or not. I tried to change the curve to find a correct one, without any success. And the worse is that the value of the driver change if I rotate the ‘main bone’ (bone ‘spine0’)!

I really think there is a problem here…

I readed the article and tried to understand it, but it obviously didn’t give me any solution to my problem.

In comparison, I can do all I want with driven shapekeys in Blender 2.49, with IK, FK, Actions, all you want, then why does Blender 2.55 doesn’t allow me that?

Attachments

shapekey_255_003.jpg755×1024 97 KB

shapekey_255_005.jpg755×1024 96.4 KB

shapekey_255_006.jpg755×1024 95 KB

7

I know this does not answer your question… but I see so many people work so hard on getting IK right on an arm… and I wonder why? Have you ever seen animation done using IK for the arm? It is very unnatural. To the best of my knowledge, any good animator is using FK for the arm, since it is the only way to get the Arcs right…

FWIW.

(Jeff Lew’s Animation DVDs provide an excellent discussion of this… Jeff Lew; Principles of Animation)
Of course, if you just want a quick pose for a still frame, that doesn’t matter… but when you animate using IK in an arm, the “tweening” generated is very unnatural…)

8

That’s an interesting idea… do you have pictures of it in action…?

9

I’m wrong, I tried it out, and I cannot get shapekeys to be driven by bones that are part of IK chains… I’ll have to look into this more…

Sorry,
Randy

10

OK, played with this a bit and I’ve gotten a shapekey driven by a bone that is part of an IK chain working, but it’s got some problems I don’t understand. In the attached .blend file there is a simple chest & arms with an armature. There is a shapekey for the shoulder that works when the arm is rotated downwards from the front view (-x rot). There is an IK constraint on the lower arm and if it’s influence is turned on and the arm is positioned using the IK target in a similar arms down pose, the shapekey works as well. If ‘local space’ is checked, then the shapekey won’t work when the IK constraint is turned on.

Now here’s the part that I don’t understand, if the bones are rolled so that the x-axis is pointing downwards and the driver is switched to work on -z rot instead of -x rot, the results are different and don’t work. Not sure why.

But yeah, open the file and look at it, the shapekey is on, and the IK constraint is on. If you turn off the IK constraint, the arm will return to it’s rest position. Now if you rotate the upperarm bone down, the shapekey will work as well.

Randy

Attachments

DrivenShapekey255.blend (330 KB)

11

You’re facing exactly the same problem I did.

The ‘local space’ not working with IK is a serious problem IMO. It should works, as it works on Blender 2.49. That’s all I can say about it because right now, I don’t see any ‘good’ solution to solve this problem.

I was thinking about duplicating bones (at least 2 more bones per original bone) and add them ‘copy rotation’ constraints on one axis only (ie: X) and apply them a rotationnal difference, but seriously if I must do it for all the bones of my rig, it will never end…

I think the devs should look a little more at it.

12

IK is necessary sometimes. If the hands are fixed anywhere ( doing pushups, hands resting on a table ) IK is a pretty good thing to have. That’s why most rigs have both FK and IK.

13

Yeah, I suppose in the case of a push-up it would be useful…

14

I modified your Blend to use four shape-keys controlled by helper bones. One for each adjustment position - up down front back. This works pretty well with IK or FK as I used rotational difference to do the driving. This is actually fairly easy to set up and requires no strange driver tricks at all.

Attachments

DrivenShapekey255_mod.blend (346 KB)

15

Here is a demo file showing how to do it on all three axis’, with six corrective shapes:
http://storage.cessen.com/perm_links/2010/blenderartists/corrective_shape_demo.blend

I use rotation difference quite heavily to drive corrective shapes. I just create a new bone for each corrective shape, in the orientation that I want that shape to be fully triggered at, and then use rotation difference. It works quite well, in my experience. I used the technique heavily in BBB, and to a lesser extent in Sintel.

If you want to get really sophisticated, you can write scripted driver expressions using multiple rotation difference variables, or a rotation difference and a distance variable, etc. I haven’t found myself lacking in the tools necessary to drive corrective shapes. Although, admittedly it can be a bit on the tedious side sometimes.

16

Hey, thanks pappy & Cessan! Two slightly different approaches to the same end solution. I was looking to py drivers, but found it difficult to find much information on them (found 1 sample .blend in the wiki about them).

Personally, for my work on my Joe_Rig, I totally dropped the idea of corrective shapekeys for the shoulder and went in a different direction. I used the mesh deform modifier and two extra bones, one to preserve volume & it’s target. It totally fixed all my problems and was easier to set up. The extra bones are highlighted in attached screenshot.

But thanks again, I’m sure I’ll be using the techniques presented here in the future!

Randy

pic7.png1016×704 184 KB

17

Wow guys, all I can say is thank you very much! :smiley: :eek: :yes:

I already mentionned that I was thinking about extra/helpers bones but you show me that it is not hard to set.

Though I still think the old system was better for this :stuck_out_tongue:

Cessen, your method looks great to me though there are something I need you to explain: how the driver know when to activate? I mean, if I rotate the leg bone on -X, then the driven shapekey COR-leg.01 is moving, but why not the others? because you setted several shapekeys and they’re just ‘cohabiting’? And what about COR-leg.05 and .06? :eek:

Please explain :o :confused:

Pappy, your method is great too. That’s the one I was thinking, but I was more thinking about 2 helper bones (ie +X/-X and +Z/-Z) with the right curves to set the rotationnal differences on the 4 directions. Don’t know if it will work…

Happy… :smiley:

edit: @Cessen. I noticed the internal roll of each bone, that’s probably the answer. :spin:

18

Nice idea Pappy! The helper bones are laid out neatly in front, so the rigger can see exactly what’s driving what. Simple solution.

19

why did blender lose the ability to do this the easy 2.4x way and why can’t it do it any more?

20

There was an easy 2.4x way? We added “rotation difference” drivers for BBB because other methods weren’t reliable. Driving corrective shapes for multi-axis rotations really shouldn’t be done with euler (XYZ) rotations as the driver. It’s bad voodoo. So if that’s what you’re referring to… I can’t say that I miss it.

Having said that, it probably would be useful to be able to access the post-constraint transform matrix of bones from within drivers. But that also complicates things. There would need to be some way for the user to specify that they want the pre- or post-constrained transforms. And that could also result in some odd dependency behaviors (recall in 2.4x that drivers could get all kinds of weird dependency and 1-frame-delay issues).

Ultimately, I think this would all best be solved with a unified node-based driver/constraint system. :wink: That would give the greatest flexibility, and would enable some really cool stuff. But that’s probably a long ways off.