Arm rig experiment

Support Animation and Rigging
#1

File: arm_dual_bone_deform.blend

This little arm-rig experiment is an attempt to make arm deformations work better, particularly around the shoulder and forearm areas. The point of this experiment isn’t to improve on interface, only deformations (in fact, I haven’t put in any interface stuff at all, it’s just straight FK).

Load up the file and hit alt-a to play through the poses I put it in.

The trick of this setup is the bones on the second armature layer. Feel free to rip it apart. It’s a pretty simple idea, and I’m sure I’m not the first one to think of it, but it works pretty well so I figured it post it here. The technique used for the upper-arm in this should also work well for deformations of the upper-leg, though I haven’t tried that yet.

This particular version doesn’t work for scaling the arms (i.e. stretching), but extending it to work for that should be pretty straight-forward.

#2

I think it’s not a deformation test, but a test to get the same deformation you can have by using Bbones AND have a hinge you can drive/have a slider for. I think this also bypasses the bbone axis flipping? Clever…
And it works with IK/FK alike, I just checked :slight_smile: …
I can duplicate it by starting from scratch, but I can’t get the childof constraint to play nice in my own rig. It makes the arm jump all around… I’m going to play with it a bit more…
thanks for sharing.

#3

It’s similar to the b-bone technique, yes. The big differences are:
1) With b-bones you have no control over how the mesh is weighted to the twist, which always makes me a little wary.
2) The rotation/twisting behaviors of b-bones are actually pretty nasty for things like this (for example, rotate the b-bone version of the setup so that the arm is pointing up, and then rotate it forward and back, like the first few poses in my file–the twisting motion is very abrupt over a small distance, not smooth over the whole rotation as with this setup).

EDIT:
Oh, also, I just realized that I’m using childof+copyloc constraints instead of a normal child/parent relationship in this file. That’s actually superfluous and was part of an older experiment. I’ll clean up the file soon. In the mean time ignore that as it has nothing to do with the deformation test. Sorry for the confusion.

EDIT2:
Okies, the file has been cleaned up.

#4

Newbie here Cessen, and I’m just trying to understand the logic behind rigging in blender. Why are you using IK constraint on those bones in the 2nd layer ?

-Gian

#5

Hey where was this in june when I was going insane over my rig’s shoulders? :stuck_out_tongue: Very cool concept, I did something similar in my rig but only in the deltoid area. I will be using this rig for my next character.

PS write a book or something.

#6

The IK constraint serves as a TrackTo, except with nicer behaviors for this purpose than the normal TrackTo. The behavior of IK on a single bone is equivilant to finding the shortest possible path of rotation between the initial position of the bone and any position pointing at the target, and then rotating on that path. This guarantees the least possible amount of twisting relative to the bone’s initial position, which is what we want.

For the forearm the IK constraint does the same thing, except since it comes after the copy-rotation constraint, it does it relative to the copy-rot position of the bone instead. Again, this gives us precisely the correct behavior because the twist of that bone will always be minimized relative to the hand.

It is concievable to write an actual TrackTo constraint that behaves this way as well, and it would be faster than the IK solution since IK is itterative, whereas a constraint written specifically for this purpose could do it analytically in one step. But at the moment no such constraint exists, so using IK is a reasonable substitute, and does produce the correct behavior.

#7

Whoa, this is pretty cool. It took me a minute to understand it, but it’s quite clever.

The only drawback is that Bone Heat creates a hard border between the deformer bones, which causes the twist to become very pronounced. Could probably be solved with an additional bone or two in the middle, I bet.

#8

Or you could just do a more careful job of hand-painting the arm weights than I did. :wink:

But yes, I don’t claim that the vertex weights in this example are ideal. Besides which, the model is horrific in both form and topology, which also has a big impact on deformations. But it’s just a proof-of-concept.

#9

After trying all kinds of constraints, I arrrived to your same use of two bones, one of them constrained as a single bone IK, inspired on an idea posted by Kattkieru. These are my own descriptions of the idea: forearm and shoulders

Using 2.46, I found a better way than the IK solution though. I managed to write a simple custom pyconstraint that copies the rotation of a bone but tries to keep the roll angle locked. In the process I realized the ideal locked roll constraint is not really possible, but the result is nicer than an IK posing as “track to”.

I guess it could be made better. I am not a coder and it took me a lot of time to solve the twisting that makes “track to” so unusable. The solution was easy in the end, a blending of rotations does the trick.

Please look at this post so I don’t have to write it all again here:
http://blenderartists.org/forum/showpost.php?p=1227359&postcount=10

#10

Geeze, I need to actually read these forums once in a while. I didn’t realize there was another current thread dealing with the same issues.

In any case…

Toloban, yeah, I’m not terribly surprised someone else already thought of the same solution. I just hadn’t seen it before, so I figured it couldn’t hurt to post it. :wink:

Regarding your pyconstraint, though: it looks like it doesn’t minimize the twisting as much as the IK solution. In a solution with the minimal possible twisting, a rotation of the bone around its rest position (think of raising an arm in the air and then spinning it like a vertical gameshow wheel) at a constant speed should also cause the bone to roll at a constant speed. The IK solution does this, whereas your constraint rolls at a non-constant speed. It’s close, but the roll is biased toward one or the other axis’, depending on settings. The single-bone IK constraint actually produces the minimal possible twisting, so any other solution trying to strictly do that should actually behave identically.

That’s not to say that your pyconstraint isn’t useful. It may actually be better for this particular use-case, I don’t know. But it isn’t minimizing the twisting as much as is possible.

I was actually thinking of taking a crack at a non-twist TrackTo pyconstraint myself, since it would be useful for things like this, as well as other things like eye tracking. And an analytic pyconstraint would be more elegant and explicit than the IK approach. Perhaps I’ll do that soon.

#11

Cessen, I basically used a track to constraint and a lock rotation constraint on the deltoid bone, and as of the 248 rc1 it works just fine, the flip isn’t happening anymore… A stretch to has the same result.

#12

It makes sense if they fixed the track to constraint! Got to try that.

Cessen: Yes. I understand what you mean, it was the IK result at 90° that I did not like and I was more interested on a predictable result at some end points. Anyway, I tried a lot of tweaking by changing the blending curve and the results were not so good. Twisting is nicely minimized for a certain range of rotation, but out of this range, the correction happens too fast.

My current guess is that to get it right, the previous rotation state of a bone should be always known, as it can influence the result.

I can’t wait to see what you come up with and what you mean by “analytic”, if when you do it I can understand at all. As I said I am not a programmer and rotation matrices are a bit difficult for me. It took me a lot to make my simple approach work. It is nice by the way that someone comments on it.

#13

I’ve written a no-twist TrackTo pyconstraint. It’s behavior is identical to a one-bone IK constraint, except that you can choose what axis does the tracking, and it works for normal objects too.

Here’s the file:
trackto_notwist.pyconstraint

And here’s an example file, demonstrating that it doesn’t twist:
trackto_notwist.blend

Alt-a to play the animation. Note how the mesh is never twisted through any of the animation, only bent.

toloban: when I say “analytic” I mean that unlike the IK solver (which uses an itterative method) we can write a constraint that does the same thing for a single bone, but does it directly with a simple formula.

#14

I’ve written a no-twist TrackTo pyconstraint. It’s behavior is identical to a one-bone IK constraint, except that you can choose what axis does the tracking, and it works for normal objects too.

you got some mad skillz there :smiley:

#15

Using the arm setup in the first post with the no-twist Track To gives noticeably better deformation than just B-Bones, especially with IK. Great work! Thanks, Cessen!

Scripting is something most Blender animators haven’t really – at least publicly – made that much use of yet, but it’s incredibly powerful for rigging. Just recently have I realized that scripting, not the 3D package, is what’s responsible for all of the attractive features in rigging reels (space switching, auto-snap, auto-clavicle, etc.). Aside from wire/spline deformation, Blender’s got everything other packages do; it’s pretty much just a matter of working with Python and the Transformation constraint, I think.

EDIT:
Just noticed in the Console Window:

Mathutils.VecMultMat(): Deprecated: use vec * matrix to perform row vector multiplication

I don’t think it’s affecting anything, though.