How to have eyelid animation conform to eyeballs?
polycounter lvl 6
Eyelid animation is obviously a very important part of getting an expression to look right, and this involves various amounts of eye narrowing, eye twitches, etc. What I'm curious about is, when defining keyframes for eyelids, how to actually get them to reliably conform against the surface of the eyeball.
It seems to me that without a huge amount of fiddly business manipulating the possibly hundreds of vertices you might have for an eyelid, one will either clip through the eyeball or be visibly far from it. Is there a particular technique or other special way I should be thinking about this?
Something I've considered is rotating the eyelid vertices as appropriate around the pivot point which you define to be the center of the eyeball. Would this be appropriate?
It seems to me that without a huge amount of fiddly business manipulating the possibly hundreds of vertices you might have for an eyelid, one will either clip through the eyeball or be visibly far from it. Is there a particular technique or other special way I should be thinking about this?
Something I've considered is rotating the eyelid vertices as appropriate around the pivot point which you define to be the center of the eyeball. Would this be appropriate?
Replies
For instance, I remember seeing some facial tutorials where the eyelids are created sans eyeball, and without snapping them to a sphere or anything like that. Just kind of an improvised eyelid. I can't quite envision how I'd take an ad-hoc eyelid like that and have it work correctly with an eyeball.
I appreciate that I'm being a bit vague, so I suppose a good way of describing my question would be, if I was do give you this eyesocket, what would be best practice for blinking it around an eyeball such that it looks natural?
Gotcha. Sorry for not having set that up before! I notice the divides on those eyelids of yours flow out to the side of the face. But as the sockets I've got set up already have circular edge flow, I've gone ahead and just added some additional loops to support the closed position like so. I expect that should be sufficient?
As you can see he's looking pretty gross just because I've closed the eyes kind of haphazard just for the sake of demonstration. I'll clean up the closed-eye pose once I have all the steps in front of me. Would a good method be to snap the vertices to a sphere?
My concern about using blend shapes to drive eye opens/closes is that the vertex positions are linearly interpolated, which doesn't really line up with how an eyelid works in real life- from the transition from closed to open, the cusp of the eyelid doesn't beeline to rest inside your face, it makes a rotation around the eyeball. Any insight on that? I'm unaware of any "rotational" based blends.
Well, considering your character is hyper-cartoon I wouldn't be too concerned about how an eyelid functions in realism.
My best advice is to try it yourself. I don't know what software you're using but sculpting tools are great for creating morphs/blendshapes.
It's the combination of two blendshapes: a main blendshape for up-down movements, for example, and a secondary blendshape for front-back movements (which does the correction that you want, on top of the only up-down movement).
The main blendshape is animator-controlled, and the secondary blendshape is completely driven by the value of the first blendshape, using a driver curve that is smooth (the driver curve looks like a half circle, so that the corrective blendshape peaks at half the value of the main blendshape).
The mix of these two blendshapes causes round movements. It's kinda like combining sine and cosine (linear movements) to get a circle.
If you're signed in to Amazon you can view part of this in the book sample, it's on page 317:
https://www.amazon.com/Stop-Staring-Facial-Modeling-Animation/dp/0470609907/#reader_0470609907
To get the same topology for both high and low, you just retopo the sculpt normally, then get your retopo to ZBrush, subdivide it to the highest it can get, and project details back from your original sculpt. Now you have a sculpt with a perfect topology for facial expressions and you get those expressions for your low poly simultaneously.
I don't know if you're correct that the corrective blendshape peaks at half the value of the main though: if we're talking about two eyelids meeting in the middle, the horizontal rate of change will reduce to zero as the vertical transition completes, but the two will meet their peak at the same time, I figure.
Any significant downsides to this? I've received some mixed messages about how much clipping should be avoided.
~51:16
One draw back to morphs is that often, you're limited to using 1 morph that translates in a straight line, taking the shortest path between those two points, through the eyeball. To really get the eyelid to slip over the curved surface of the eyeball, you can do one of two things.
You can use thick geometry and extreme morphs to get rid of the clipping but that might not always be an option on some characters.
This has the downfall of pushing the eyelids far away from their natural position to combat clipping. On some characters it can look like their eyes bulge out of their head when they blink but on most characters in most games, no one notices or cares.
OR...
Eyelids are a bit like a garage door and that they need go out and down as it closes.
A single morph can fail to translate out far enough, in some cases. Soo....
You can use a progressive series of morphs to make sure the eyelid sticks to the surface.
A morph for 25% closed which mostly translates forward, away from the eye.
A morph for 25-75% closed, that mostly translates down.
A morph for 75-100% closed, that mostly pushes in toward the eye.
In max and Maya you can stack those morphs to fire off after each one finishes and it's a great technique to solve a lot of issues besides just eyelids.
Another way to control eyelids is with 2 joints that have their pivots at the center of the eye. This is often technically cheaper than morphs and easier to manage and allows you to use morphs for other things like character customization. This technique works mostly like a garage door and pushes the eyelid around the curved surface of the eye as it rotates. It's also really easy to set up and work on all kinds of hardware and engines.
I've used both extensively and I can't really recommend one way over the other in general. Both techniques have their pros and cons and you want to know which one will work best for your project.
Your post was very instructive! I'll go through some options and get back to you all with my progress for further feedback.
Got this done using bones, with the technique from this video:
I'm very happy with it! However, and this is drifting slightly from the problem statement, this method uses blender's "bone constraints": which one set of bones is swiveling around the eyeball, that rotation being driven by a single bone. And ANOTHER set of bones are instructed to follow them with a <1 amount of influence, which is the "constraint" and makes the movement look nice. Those bones in turn drive the vertex movement. My concern is whether this can be exported to UE4.
Not a dealbreaker if it can't, because at this point I expect I could turn these bone movements into a single animation. However, if the constraints can be used in UE4, this would mean that I would have finer control over how much the eye is closed.
Hope this question makes sense, let me know if you'd like any more details!
A joint placed at the center of a sphere will rotate around the surface. It pulls the eyelid in in an arc, not a straight line.
You can get into trouble with a joint if you're stretching some small thin polys. It's better to rig (joints or morphs) with eyelids half closed, which also helps UV's and baking, but all of your characters look stoned, ha.
A single morph will translate straight from one point to another and can clip through, IF you don't take steps to carefully build that morph/blendshape in a particular way.
Single morphs can be done, it's not a huge problem, some trial and error will get you the results you need, I'm showing the worst case scenario to outline the difference.
A cornea bump can be a pain in both cases, but if you're at that level of fidelity that you need the bump, then you can also spend the extra time/tech to make sure it doesn't clip through. There are 2-4 ways to deal with the bump and it all depends on what your project/game/engine can and wants to throw at the problem but that all depends on how important the feature is.
Picking the best looking option might cause performance issues and vice versa. Like I said, I've used both to varying degrees of tech-heaviness and in each individual case, they've been the best solution and what worked on one game would have been a mistake for the others.
EDIT: Dealing with a cornea bump
1) Thicker eyelids. This can take some trail and error but it doesn't balloon your tech budget and is usually all you need.
2) Translate the eyeball joint back, or the the eyelid away from the eyeball. Note: Translation has a cost of adding 3 more channels to your animation and you only use one, however they might already be present and not doing anything, that all depends on your engine.
3) Morph on the cornea bump to flatten it out. This can be driven by the rotation of the eye joint so you don't have to micromanage it.
4) Joint just for the bump. This pops it back into the eyeball and flattens it out.
5) Mesh deformers. This is mostly likely unsupported by most game engines "out of the box" but can be added and built out IF it's really important. This is pretty cool because the bump actually displaces the eyelid and you can see it slipping around under the lid but it has a high tech cost and a lot of friction to a pipeline that probably doesn't need it. If it gets used in other areas of the game, maybe it's ok to use on eyes, or maybe it's really needed on a giant eyeball monster that is 3x the size of the player? Who knows...
So yea, tools in the toolbox, don't use a hammer when you need a screwdriver
As per the video I posted, right now I'm using a joint at the centre of the eyeball to orbit several OTHER bones located on the rim of the eyelid. It does this via a "follow translation" constraint attached to the eyelid bones (the influence of which can be scaled). The vertex weight of those bones is highest at the rim and drops off further up the eyelid. This makes the cusp of the eyelid rotate around the eye as desired but I suspect it's what's making the higher-up parts look a bit flat, because those vertices aren't being instructed to rotate, they're being told to follow a translation.
I might try re-rigging to have all of the eyelid vertices driven by rotation, and see if that works any better.
Improvements- rotational travel around eye, one bone instead of like seven.