Hello. Currently I’m trying to rig an eye and it’s getting kinda complex.
Right now if I rotate the eyelid bone it intersects with the eyeball. So to fix this, I created a shape key that corrects for this and bulges the lid out.
I set it up so the eyelid bone drives the shape key, and it works great!
Now all I’m trying to do is drive the rotation of this bone with another. But no matter how I do this, (Copy Rotation constraints, or Action Constraints), the shapekey-driver functionality is lost.
I think this has to do with the fact that when the bone is being constrained, it’s not… actually rotating? The transform properties reveal that rotation on all axes is 0.
So I was wondering, how should I set this up? How can I make it work so that I can have an eye controller object and still have the fixed shape key functionality?
Maybe I don’t understand perfectly your problem, but driving the shape key to the second bone e applying a copy rotation constrain to the first bone to copy the second one?
What Env is saying is that the new bone which you want to use to control the other bone might just as well drive the shape key directly (driver bones can be remote so it doesn’t matter if it isn’t buried in the eye).
Can I add that generally, assuming the eye is spherical (or a lattice deformed sphere), the lid shouldn’t intersect the eyeball if the bone’s root is at the dead-centre of the eyeball and the lid is properly weight-painted. If the bone’s root (pivot point) isn’t located on the true centre of the sphere then it would obviously tend to pull the verts in a different arc to the surface of the eye.
assuming the eye is spherical
is generally not a good assumption when following the Pixar eye tutorial, or something similar, which many do. Subsurfing a UV sphere turns it from a sphere into an olive - not enough to notice unless you look closely, perhaps by comparing it with a blender generated primitive circle, but enough of an olive to poke through when the eyeball turns, even when it’s turning around it’s geometric center. effstops, I don’t know how you made the eyeball, but if the above sounds familiar, you might check the sphereicity of your eyeballs, your problem may be more easily solved by a spherical eyeball and slightly thicker lids (to account for the slight bulge of the coronea).
Well, my eye is not perfectly spherical, (although I thought I made them that way) but it’s kinda too late to change it. It’s not a major problem, though, if I can get these shape keys to work.
AndyD - That’s a great suggestion (switching the shape key driver to the other bone). That had already occurred to me but for some reason it doesn’t work either! This is what happens:
I’ve added Bone #2. I set it up to drive the shape key when it rotates 90°. It works well. Then I click Bone #1 (the one in the eye, weighted to the eyelid), keyframe its rotation and apply an action constraint. Then Bone #2 drives the rotation - the action, but it seems to forget about it’s other responsibility! It no longer drives the shape.
What strikes me as a little odd is that you’re having this problem at all. I haven’t really messed with driven shapes so I can’t verify but I’m fairly certain that rigs like Mancandy use constrained bones and driven shapes as a matter of course (for fixing things like hand and finger deforms).
I just did a quick test with two bones and a cube and got expected results (bone copied rotation and drove shape). Granted this is bit simpler than an eyelid but the theory should be the same.
Which Blender are you using and can you post a .blend?
Hey AndyD, thanks so much for testing that out. I was surprised to find that it worked fine for you, so I went over it all again.
I seemed to have figured out a work-around! The rig is a little more complicated than I explained at first (I wanted to simplify it so people would understand the problem I was having) – I actually had two bones deforming the eyelid:
One for the first line of vertices, and one that had a copy rotation constraint at 50% influence for the second row of vertices. Essentially, rotating the first would also rotate the second halfway, which makes the eyelids deform nicer.
SO, the problem I thought I was having was not the problem I was having! The shape key fixing the eyelid deformation was a fairly subtle change, and apparently it was working and I didn’t realize it!!
I tried exactly what you said with the three bones and yes, you can “layer” constraints … In fact I even added a simple plane and added a driven shape key to it to see if the problem was because of that but no … the shape and the bone acted as I expected it to . Though you do create a loop/cycle in the bones when doing this … but since they are not “related”(same armature but no parent bones - all are “root” bones) this caused no problems …
AFAIK the only times when you can’t layer constraints is when using the IK Solver constraint … It will over-ride the constraints applied to the bones in it’s IK chain … And that is because it is coded that way by Brecht four years ago … Maybe a time to ask for a few if/else statements in the code ?..
… But your problem in this regard … well I can’t reproduce it … If you are still interested in figuring out what the problem is in your blend … post it .
