Maya rigging issue: Flat Eyes

olaveiras

Hey guys. I'm creating a pokemon-style creaure and wanted to create a nice, flat and vivid eye (tried a spherical small eye - it got kinda strange and ugly). But what about the rigging? I decided tor record the issues otherwise I would need to post a bunch of prints, which is really boring.
I've been beating my head with this issue for some days, and I can't go any further without getting this done. I'm attaching the mb file (maya 2017).

Edit: 0:05 I mean iris distorted, and not cornea

https://youtu.be/XWE3qCVUyhc

.Wiki

You can try to rig a spherical eye and deform it with a lattice to give it the flat look.

RN

When you say "pretty basic SDK" on your video what does that "SDK" stand for?

As for a flat eye, besides the lattice @Wiki mentioned, is there any reason you can't use a texture and UV panning?

olaveiras

@.Wiki a lattice deformer would get my iris distorted (I wrote cornea wrongly in the video)
@RN SDK means Set Driven Keys from Maya... and using texture/UV would not allow me to use materials to realistic eyes... I need to use separated meshes for cornea and the eyeball, the inner GEO has to be concave, etc

RN

A suggestion: the UV panning can affect not only an iris albedo texture but also displacement textures, one for the cornea bump and another for the iris "valley". So one displacement texture is for the cornea and the other for the iris, if all textures pan in sync then the effect works.

You haven't said what you're going to use this model for, so if this model is for realtime use then you'll have to use a displacement + tesselation vertex shader.

But all of this is if you really need those bumps on the mesh. On a flat cartoony eye I'd guess they won't make a big difference.

olaveiras

@RNSorry for my delay, but I forgot to say that I pretend to render this in marmoset. I saw that UE4 accepts the UV panning, but not marmo.
But i`m pretend to take a shot in next days, If I don`t get the rig working properly.

olaveiras

I just had an epiphany this night and decided to redo all node graph and got able to get it working 100% (i'm really enjoied this challenge, thanks to @.Wiki  and @RN for the colaboration). I'm gonna list here my step-by-step to document my progress.

Main issue: I was using the same corrector for Left and LeftUp, and that was causing conflicts (Edit: some corrective BS to act when it shouldn't).

After separating a corrective BS for leftUp, leftCenter and leftDown each, I got able to do a 100% clean logic (0/1 X/Y condictional diagram) to command my correctives (bunch of condictional and multiply nodes)

Next issue: all corrective BS get linear with direct connections in node graph (Edit: this linear command was giving me the transpassing geometry). I would need some curves to make the problematic correctiveBS (leftUp, leftCenter and leftDown) wait for his moment to act.

I decided to keep one controller (I'm calling it "blue"...) just for the correctives (linear command). I created another one to command (... and calling this one "red") the basic "no-troublesome" moving (up, upCorrective, down, downCorrective, left) in basic-linear SDK.

THEN, the trick was to make blue be commanded red. I used SDK ideed, but adjusted the curves to make red jump in the right moment. Actually I didn't even need to move curves in animation graph. I just had to move the eye with blue, position red to get the right corrective deformation, and hit 'key' in the Set Driven Key window when it got nice.

Edit: resuming the general issue:
red >[curve-command]> blue
red >[linear-command]> up, down and left
blue >[linear-command]> left correctivesBS

RN

Thanks for the breakdown, so you solved it with an XY controller and (let's say) 4 correctives: up, down, left and right, with center as the base shape.

Do you have any clips of the fixed eye in action? Flat eyes are a common problem.

olaveiras

GUYS! This is getting even better!
My corrective BS where done all by hand, pushing pressing and smoothing the mesh. Really messy and not professional, plus creating all this previous headache.

I just get this idea: I bring back an old default shape of my eye in a flat plate shape (with cornea, iris depth and etc). Placed in the right spot on eye hole and placed 4 bend deformers in cross formation, adjusted the angles correctly to make the eye-plate bend smoothly inside my character skull. Now I just have to move my eye-plate up/down/left/right and clone the results (Edit: to create the blendshapes up, down, left and right). I won't even need a corrective BS. My BS's axis will be perfect. I just tried a result and got just perfectly rounded and smooth eye sliding inside the head.

Thanks to you all!

Edit: @RN I wanted to record my previous post today, but I'm in a hurry this week. But I would love to record both situations we discovered today. Really glad to have posted here and ketp fighting this challenge with you guys.

RN

Ahh that's a cool idea @olaveiras, the eye isn't sculpted in a curved shape, it starts flat as a plane and is bent non-destructively using bend modifiers (or whatever equivalent in the 3D app), so the blendshapes can be very simple left right, up down for that planar eye. 

Whenever you get to record something (no hurry) we can add it to the Polycount wiki.

olaveiras

So, I just got an sample working 100% in both eyes. IDK when i'm gonna be able to record a good video, so I'm going to break-down in general the process behind it.

       First of all, just bend deformers if your going to animate in Maya work well just like the lattice deformer. I don't think you'll able to use strech/squash deformation that Lattice provides, but you won't get any distortions in your iris, if that's a matter (it is to me).

       Going throuth the fbx funnel, we have the blendshapes (BS) for the main axis (up, down, left, right) and corrective blendshapes when we get the corners (leftUp, leftDown, rightUp, rightDown). My previous mistake was to create separe correctiveBS for the main axis. This got me into another mess, and I needed to create a bigger logic in nodeEditor to make it work poorly (the red and blue controllers I described days ago).

       Now: SDK for the main BS's, and conditional nodes for the other ones (calling it "corner_BS's"). The conditional nodes are the logic 'yes/no', pretty easy. For that, we have to think in north south way: 
leftUp = (x positive y positive)
rightUp = (x negative y positive)
leftDown = (x positive y negative)
rightDown = (x negative y negative)

We'll use one conditional node to check each axis if it should be ok or no. The conditional node (maya) will have 2 inputs (first, where we plug in the axis from the controller ("CNTRL"), and second we put 0) and the condition itself: we going to use "[first input] Greater than [second input]" mode for the positive values needed "(cond)", and "[first input] Lesser than [second input]" mode for the negative values "(cond)".
At total, (cond+X) (cond-X) (cond+Y) (cond-Y)

For example:
leftUp will need the output from (cond+X) and (cond+Y)
leftDown will need the output from (cond+X) and (cond-Y)

       Out a condition node, all we have is a hard logical pulse 0 or 1. We're working with analogic values here (moving the CNTRL). So, we gonna multiply our previous axis values coming out our CNTRL (X and Y) by the output leaving the conditional (calling it "pulse_to_value_*". If the condition is ok, we gonna have our value axis clean and positive. If the condition is not respected, it'll be multipled by zero and this will cancel all the corner_BS's we don't want to have on. If our logic is nice and soft, we will always get just one corner_BS's activated at a time, when the CNTRL leave the main pure axis.
(remembering - the condition node will cancel all corner_BS's when we get in puxe axis, thanks to the greater/zero than zero rule)
At total, pulse_to_value_+X, pulse_to_value_+Y, pulse_to_value_-X and pulse_to_value_-Y

       That said, we get the output of each pulse_to_value and multiply between couples following our previous logic in marked in red:
For example, in leftUp, we multiply pulse_to_value_+X and pulse_to_value_+Y and plug the output finally ( ) in leftUp BS node.

       But that's not all. We're working with values 0, 1 and multiplications. I doubt your controller will  deslocate value 1 in world scale. Mine was moving 0,05 for each axis. So, we're going to add just one more "last_multiply" node right before the final input in each BS input. I needed to multiply by 20 to get my 0,05 maximum translation reach value maximus 1. AND, probably the rightDown value will be negative, because the conditions and axis values. You just have to put a minus value on the last_multiply.

That's all!