You probably already tried one of those scale and rotate hand rigs. I personally didn’t like it, because it was a bit hard for me to animate the fingers. As far as fingers interacting with each other or other objects.
So I went back in time to where IK bones were used to direct fingers. I was able to limit the IK bone to a single axis, so the fingers didn’t go side to side. For side to side motion I with a help of pydrivers and a second hidden rig (since IPO drivers or pydrivers cannot deform in real time bones within the same armature.) You can simply rotate the bone for the side to side action. Also a limit was attached so the bone bends at a particular point.
As for the hand and the arm interaction, in real life your hand follows your forearm. Also added a copy rotation constraint which allows you to twist your hand by rotating the bone.
Before I go into any kind of details I thought I might just post this and see what you guys thought.
Very nice . I think its an improvement from your last complete rig . Easy to control .
Not that there’s anything wrong with your last rig - I especially liked how you rigged the mouth .
Thanks ! … will take a look.
… The hand rotation is much better now, I was having a problem with the previous rig rotating the hands.
Will do some more testing with the fingers.
Mike
Great hand rig, Calvin! Very intuitive and fast animation. Since python is just a modern version of Sanskrit to me, can you achieve the same using driven bones? Or what do you lack in that case?
Wow, I checked it out, and then I checked out your key-less face. You’re a better and more inventive rigger than I am… Thank you for letting people like me reap the benefits of your hard work, it really does help.
Thanks for the comments!
RobinM: It’s kind of complicated.
When you use a copy rotation constraint, it can only copy the physical rotation. If for example a bone’s rotation is due to an IK constraint, there is noway to actually copy it.
Well, there actually is… when you un-local the constraint. But there is a problem with that, the rotation copied is not local. If there is a root bone involved, and you rotate the root bone the axis the copy constraint is applied is global and so you are not actually copying along the right axis. (of course it doesn’t matter if you just copying all axis, but if it’s only along one axis, it screws it up.)
The only option I found was to use a python script. What the python script does is calculates the true/local rotation of the bone.
It takes the difference between initial and final position of the bone and subtracts the rotation caused by the parent so we are left with the rotation caused by IK bone.
But that is not the only problem. If you look into one of the layers, there is a second hidden rig for the fingers. The reason for that is… that you cannot have a bone within the same armature act as pydriver or IPOdriver for values of other bones. To solve the problem, I moved the bones that deform the fingers into another armtaure, and left the pydriver bones with the original rig. The bones in the original rig are able to pydrive the bones within the hidden rig.
Your original question:
can you achieve the same using driven bones?
Well, As I mentioned… simply coping the raw data is not good enough. I needed to isolate the rotation to one constraint (cause due to IK bone.) That ment subtracting the rotation caused by the parent bone. Another problem is that Bones don’t use XYZ values, IPO wise… they use Quats. Drivers can only use the bone’s XYZ rotation, how would you go about applying those rotations to WXYZ?
BlackBoe: the face actually uses “some” shapekeys… but they are driven by bones.
Wow thanks Calvin ! I was wrestling with the same problem (I just didn’t know it) for about a week now and your last post made it soooo much clearer and easy to solve … I am stupid and didn’t realize you had “simplified” Bassam’s scale-finger rig using python drivers … I just started looking into python a few days ago myself after trying to do crazy things in the IPO window …
The whole “local” tab in the constraints baffled me because like you said if really only applies to the root and not any of it’s children … perhaps this is an area that needs further development in the future … but thanks again for your solution !
EDIT :Oh next time if you could remember to leave an IPO window and the transform properties open in your blends (if that is where you made interesting developments) for idiots like me I think more people would come to appreciate your work …
