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?
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.
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?
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.
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.
Also the blinking attribute doesnāt make sense to me now since its both blinking and pushing the lower lid down.
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.
I only kept the .blink to support backwards compatibility. But if it makes it more confusing?
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?
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.
Sunday/Monday sounds good to me 
I am also on holidays with the family until Monday 
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.
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.
