Home Youtube GitHub

Eye Rigger mesh


#1

I was wondering whether we could get rid of referencing a mesh for the center of the eye ball, and instead reference a position in world space?

The benefit being that you can save the preset and when it comes to building, we only need the mesh that has the lids ei. only one dependency in the maya scene.

I might be missing some obvious about the eye rigger and the reason for referencing a mesh for the position of eye ball center?


#2

I very much agree with this.

I agree that the eyelids shouldn’t depend on the existence of the eyeballs. (Or the assumption that the eyeball should be skinned). What I do is duplicate my character’s cornea geometry, center the pivot, and then delete it once rigging is complete. Because our eyes don’t use a skinCluster. In the eye config, I reference the duplicate. It’s an awkward workaround.

The other awkward thing about this, is that it skins your eyeball, and thus makes the skinPack less consistent.

Also, if you plan to take this on, please wait until I’m done with the upper+lower blinks. I’m finalizing it today if all goes well.


#3

Didn’t actually know it skins the eye ball. Always hide the centered eye ball.

Won’t work on anything yet. You merging into the facial rigger?


#4

Yep, I won’t touch the legacy eye_rigger now. That should be better for backwards compatibility.

By the way, adding the ability to import the JSON from the GUI was a very nice touch! This will really help newcomers, or people who aren’t comfortable with scripting. And they will still be able to save their configs.

My PR is done. Though I am not 100% comfortable with git to know whether I followed the new procedure correctly. I made a branch off of the master, and my PR is still in the branch.


#5

@chrislesage

I’ve just tested your changes, and there seems to be some issues when you have a blink height. With a blink height on anything but zero the upper lid goes down by default.


#6

Also the blinking attribute doesn’t make sense to me now since its both blinking and pushing the lower lid down.


#7

Hi @Toke_Stuart_Jepsen

thanks for pointing that out. I’ll check out the blink height issue.

The blink + push down is the intended behavior. 0.5 is a half blink and 1.0 pushes the blink all the way down. Our animators personally like it.


#8

I only kept the .blink to support backwards compatibility. But if it makes it more confusing?


#9

The behaviour of the blink attribute will break existing animation cause it’s not the same.

Any way of having the blink attribute do the same as before, meaning the lids meet and nothing else?


#10

@chrislesage can we make the new behaviour optional?


#11

Yes no problem!

But I think it might be cleaner just to make the eyes act like they used to, but keep the upper lower split. “Optional” is always possible in a post script for custom behavior like this. What do you think?

Anyone want to handle this? Otherwise, I’m traveling until Sunday, and I can quickly fix it Sunday or Monday.


#12

Sunday/Monday sounds good to me :slight_smile:


#13

I am also on holidays with the family until Monday :stuck_out_tongue:


#14

I made a few more changes I wasn’t aware of. I had reversed the direction of blinkHeight, because to me, pushing the attribute higher should travel in the same direction as the blink. Also, blinkHeight should have no effect on the blink when the blink is at 0.0. But mine overdrives the blink.

I will undo all that to get back to original behavior.

So I have a bit more undo work to do. Almost there! Today or tomorrow.


#15

Ok, it’s done now, and the PR is submitted. Everything is back to the old behavior, except you can now use upperBlink and lowerBlink separately.

There is no fancy upper-lid clamping anymore.


#16

Thanks @chrislesage I will check it tomorrow :smiley: