Bone locations that control shape keys with drivers

I have a human body rig with 292 bones total. I am at a point now where I would like to work on shape keys to add detail to mesh deformations such as muscle contractions etc… The question I have is whether or not the method I am attempting is the best way to go about doing this.

I want to find child bone locations so I can control the shape key levels with drivers. The problem I have run into: The bone locations stay zero in local and transform spaces in the driver transform channels so I have to use world space. Their local locations (relative to the rig) only change if I move the bone separately by grabbing it. The world location is the only one that seems to show usable change when the child bone is moved by the hierarchy. A problem occurs with using the world location in the shape key driver. If I move the root bone, the child bones aren’t based on it and instead are based on the world origin and where the bones are at default position. So if I move the root bone, all the shape keys start changing even though the rig isn’t deforming, only shifting over to a different spot. Do I want to add another variable to my shape key drivers that subtracts the root xyz locations from the variable based on the child bones’ world location? Is there a cleaner way to do this that won’t require so much clutter and extra calculations to move the armature? Thanks for any advice.

1 Like

Yeah, local space is local space-- if you manipulate a parent, the child hasn’t moved at all in its local space; rather, its local space has moved instead.

But you can do what you want with a constraint. Copy your root bone, parent your duplicate to your root, then give your duplicate a copy position constraint targeting some other bone. Now your duplicate contains the root-space position of that bone, in the duplicates’s local position.

Doesn’t have to be your root bone, either; you can measure the difference between any two bones you want with this, regardless of hierarchy.

I edited the end of my paragraph above. I would rather not have to make more bones. More than 292 is already a lot.

it could be better to use distance or rotational difference in world space as a starting point :

But , I never really tried faking muscle to be honest…

Also, you may look into using some stretch to bones aligned to muscle, that could also help even if that mean adding extra bones.

I work on some cartoony character where I get around 370 bones, without extra stuff to control clothing or hair. I would probably end up adding more then . I’m not sure it’s a real bottleneck performance wise, some constraints may take longer time to evaluate , but I may need to profile all this.

It’s just a matter of keeping that mess organised…

You can use layers and colours to organize the whole thing. 292 bones is still pretty lightweight as far as full body rigs go, you shouldn’t worry - my advice is take special care following your naming convention faithfully, and use groups.

For triggering shapekeys, I’m not sure why you can’t use local space. Could you explain one specific case where you can’t use them and why ?

You can of course substract a driver value with another, but that will have to go through a python expression (“varA-varB”) and if you do that on a lot of bones, it will definitely become gradually slower to evaluate (although there have been improvements recently regarding that… you’d have to test it I guess).

@Hadriscus said:
“For triggering shapekeys, I’m not sure why you can’t use local space. Could you explain one specific case where you can’t use them and why ?”

Explanation:
Local space driver values attributed to child bones only change when the bone is moved with grab/rotate. If the bone is part of an IK constraint or is part of a hierarchy chain that follows a parent bone, the local space value doesn’t change if its moved by the parent. Only the world space changes in this case and is usable as a driver variable. It sucks. They need to add another “space” type for child bones. There are workarounds but they aren’t very convenient.

@sozap I try to stay as efficient as possible with my rigs. With a bound mesh deform cage and an armature deform mesh modifier with a vertex group that determines influence of armature per point on the mesh plus a sub division surface modifier makes me want to stay under 300 bones if I can…
The human body has around 206 bones and I am not even modeling each individual spinal vertebrae (33) total. There are plenty of extra bones under 300 to drive IK chains/ elbow/knee plants.
And you’re right, organized symmetrical names are super important.

So I went with your advice and I added 2 more bones parented to the root and used the distance between bones to solve the shape key driver using world space. Since the distance stays the same between bones in world space, the shape key only moves if the bone moves. I had to add a copy y and z location constraint to get the bone in the correct places when I animate because the “distance between bones” alone doesn’t translate well when you cross a certain threshold in the hierarchy.