Well… No.
I suggest you check the exact same numbers as me on the partial mesh you sent me, and see if it runs on your side. Then we can see if it is the mesh, or a bug in the script on your side.
I tested on the partial mesh and it worked.
So it’s probably a problem with my full head mesh, although I don’t know why,
I created the partial one by extracting faces from the full one (+delete history).
Yeah that is bizarre. And the other difference is that you have a full rig in the scene. So maybe check for conflicting names. Do your body geometry, eyeball, eye joint and eye rig group all have unique names?
Are you getting any suspicious looking errors or warnings in the script editor output?
Hey guys,
I had the same issues, it happened when the eye corners were aligned that way. (my mesh was even more stylized (cartoon rinho).
Same - better results with eyelids separated, but I as the deadline was coming, I ended rotating the eye with some root so It was as straight as possible, and then rotation back the rig. <- yep, not so clever. But after digging into the code, I think it would be nice to add a few options to set the orientation of the whole rig. I started working on that, but it’s not ready yet and not sure when would have time to finish it.
Also, I have always better results creating separate geo (just 1 edge) just to generate eye/lip rigs.
Cheers!
1 Like
Hey guys,
I tried to take the alternative approach of building the eye rig on the partial mesh and then either transferring weights or skinning the real head from scratch.
But I encounter several issues with this.
I managed to rig the left eye, just like Chris tried successfully, and it’s connected to the main character rig.
But whatever I do, I can’t get the right eye to rig properly. I even tried opening a clean file only with the partial mesh and creating the eye rig, with a simple joint1 as “head or eye area joint”, but whatever I do, the right eye rig doesn’t build properly and doesn’t blink correctly. The joints rotate around the eye socket when blink is on.
The second weirdness I’m experiencing is that the eye rigger window freezes. For example, I select the eye mesh and press it in, then the edge loop but I can’t press the edges button (the << one), or type text in the text box, for a while. Then I get a // Warning: Python callback failed // in the script line and it unfreezes and I can carry insert the edges, then freezes, insert inner vertex, etc…
Chris, is there any chance you could test if you can build a right eye in that same file you tested before?
I’d really appreciate it.
I’m kind of at a loss here and starting to consider not to use the eye rig at all.
Thank you!
Yep, it is funky on the right side.
The blink blendshape curves are all twisted and mangled.
The upper eyelid is an upper curve:
The lower eyelid is going all the way around the eye! Which is just wrong. The interpolation between those two curves is the mangled blink we are seeing.
At first, I suspected it was because the edge loop you are selecting doesn’t really have any neighbors. But I chose the next one out, and it still acts the same.
Also, the first time I built the eye, I got a different result, and the center of the eye got calculated incorrectly, halfway down the body. I built it a second time with the exact same config, and it worked as pictured.
I also tried subdividing your mesh, in case it was a problem with low density messing up some of the mesh calculations. The results was the same.
Lastly, none of this explains your weird GUI freezing. I ask again, are you seeing any errors in the script editor?
I’m pretty busy right now, but I can try digging into the code within a week or three. There are some solveable bugs here, for sure!
In the meantime, I offer you a hack to consider:
- Rotate your mesh group so your corners are on the outsides
- Run the script
- Temporarily turn on Dual Quaternion weights so the eyelid stays nice and round
- Close the blinks
- Save and export that shape as a blendshape, and use it as a blendshape on your rig.
You could also move some of the other eyelid-shaping controls and save those as blendshapes too.
Thank you for all the testing and advice. I really appreciate it.
I didn’t get any weird errors in the script editor about running the rigger.
The one thing I did get: when I tried running a right eye after the left was already created, I got an error that the right eye’s area joint (or eyeOver…) is not part of the skin cluster.
This error doesn’t happen when you rig the first eye, but once you do, it pops up when rigging the second eye.
Unless you go ahead and ad that joint’s influence before running the rigger for the second eye.
Well, if it comes down to blendshape blinks, on such a low poly mesh I can create them really fast and appealing without all the eye rigger workaround. Not too many vertices to move here, and I’ve creates such blendshapes many times.
I’ll also need blendshape inbetweens for the eyelid to go around the eye and not through it when the blink is halfway through.
I’m familiar with SHAPES but never used it so far, but I’ve been using a fantastic little script called abSymMesh for years. It checks symmetry, let’s you flip you blendshape, mirror sides, etc…
Hey,
I’ve tested your file and it’s working well. I’m using mGear version: 3.1.1.
Please take a look, maybe you could just reparent that rig into your file. Rig was created from your geo, but when it fails, I would recommend you create temporary geometry, so that you’re sure it clean etc.
I can’t be sure about this, but when I was digging into the code some time ago, sometimes I found that edge loops given to script are not sorted in some cases. I’ve fixed that adding sorting function in one of my scripts (based on lips rigger).
I will try to check that also.
About blendshapes -> shapes was the best plugin I’ve ever used, it saved me a ton of time. Not sure if you’re using radialblendshape, but if not I will recommend that also. Gives a little more control out of the box for a simple blendshape setup.
https://www.paolodominici.com/products/zvradialblendshape/
1 Like
Yeah this is a nuisance, but the way I handle the eyes, is that I use the GUI tool to get my JSON configuration file. I build one eye at a time, and then export the weights as ngLayers to be merged into my body weights later.
Once you have the config file and the weights, you don’t need the GUI tool anymore, and you can turn off auto-weighting on the eyes. I load my eyes configs through scripts, and the weights get stored in the Skin Pack file.
1 Like
Hi @Krzym,
This is a super late reply, but this week I am looking into the eye code a bit more. What did you mean by “sorted”? I’m guessing sorting by edge or vert number will not work, since you can’t necessarily rely on those being in a nice order. (Or can you?)
I am testing an algorithm that will either orient itself to the axis of the corner vertices, or will march along the edge-loop, choosing the two middle points for the upper and lower vertices, so even 45 degree rotated eyes should work. This works for finding the vertices, when the user chooses manual corner vertices.
But I’m still trying to figure out why the right side sometimes loops all the way around the eye. I haven’t figured out where that is happening yet.
Edit: Actually, I have a promising result that seems to have fixed it when I override the upPos and lowPos verts in the eyes, but I am double-checking. This was a mesh I had that was failing on the right side, and now it is working, because I find the upPos and lowPos by edge-marching to the middle of the upper and lower eyelid edges. I’ll run this by the devs later this week and then make a pull request if it seems solid.
1 Like
Hi @chrislesage. I’m not sure what exactly is wrong, but sometimes it helped me to create temporary geo - then even 45 degree rotated eyes worked - only minus of that was that the controls weren’t rotated correctly as on your preview - do you think you could quickly fix that too? 
What I was testing was sorting edges/verts by world position or from one corner to another. Sorry I do not have any examples right now, just some code I quickly pasted:
#sort vertices from X+ to X-
def sortVerts(points):
length = len(points)
for i in range(length):
for j in range((i+1),length):
pos_i = points[i].getPosition(space='world')[0]
pos_j = points[j].getPosition(space='world')[0]
if (pos_i < pos_j):
temp1 = points[i]
points[i] = points[j]
points[j] = temp1
return points
c_Loop = [pm.PyNode(e) for e in pm.polySelect(geoTransform, edgeLoopPath=(l_inner.indices()[0], r_inner.indices()[0]), ass=True, ns=True)
if pm.PyNode(e) not in l_Loop and pm.PyNode(e) not in r_Loop]
I’m sure this is not a clever solution but worked that time
2 Likes
Thanks! Yeah that makes sense.
And yeah I’ll see if I can fix the orientation of the controls too. I’ll see if I can calculate a sane orientation space between the vertices.
1 Like
This is a bit old, but a thread closest to the issue I’m having. What ended up being the thing that defines the rig orientation? I’m working on an eye rig that exhibits extreme protrusion and while this rig works, the orientation is pretty wonky. Any recommendations for what I could do to get a more traditional XY plane orientation?
@Saveremreve Is your eyeball geometry separate? Is your eyeball a perfect sphere, or is it a partial sphere? Is the eye skinned or constrained?
There was another thread where someone had a parentConstraint node under the eye, and the transform of that constraint was outside of the eye, and it was causing the bounding box of the eyeball to be huge and the center was detected as halfway down the character. And in that case, the orientation of the controls might be caused by an offset center position of the eyeball.
If that doesn’t seem to be related to your problem, if you share a file, I’d be willing to take a quick look.
The thread I’m referring to: Eye Rig orientation...again
I’m a VFX rigger, so this is a small prototype that’s part of a larger system and it’s intentionally stripped down and very basic. I left my failed mGear eye setup in there, but I basically only want the eye rig and nothing else.
So no intentional use of constraints, and I watched the original walkthrough video and made a temporary sphere for a separate, symmetrical, pivote centered eye I could retarget trivially later.
https://www.dropbox.com/s/sx78zyb864cqyz2/EyeFace_External.ma?dl=0
Here’s another angle that shows the unusual protruding look. My use case is placing copies of the eye on another surface so they must protrude. I intend to use this in a real-time application so this is a lower resolution proxy.
I’ve figured out the problem. The problem is in the way mGear tries to discover the upper and lower eyelid.
Because of the shape of your tear duct, the lowest vertex is inside your tear duct. The eye rigger was written with the assumption of simple football shaped cartoon eyes.
In this image, the two outer positions, and the upper position are correct. But the tear duct is causing the lowest position to be on the inside corner. mGear then averages those 4 positions, and results in the red locator. That location is what the controllers AIM at, from the center of your eyeball. That is where the offset comes from.
If your design permits it, I suggest raising the tear duct slightly so it is above the lower eyelid. Or open the eyelid wider a bit in your model.
I’d also suggest evening out your edge-loops so you have a center edge loop on the lower eyelid. (And again make sure that is the low point in translateY):
2 Likes
Thanks so much Chris. As this is an effects model it’s no trouble to rebalance what the neutral state is. Understanding now how the algorithm works this totally makes sense. Are there any other key items for how it behaves that you think it would be illuminating? Also is there any documentation besides the 2 videos that discuss eye riggers on the main youtube channel I should be educating myself with? I hunted around and that was the best I could find. If there’s anything I could do to contribute I’d like to.
Those are the key items. The way that they are calculated has room for improvement.
I actually wrote a new algorithm for marching along the edge loop, rather than just looking for the lowest point. But I haven’t had the time to test it as much as I would like before I submit it as a PR.
If you are comfortable with Python, feel free to replace scripts/mgear/rigbits/facial_rigger/eye_rigger.py and test this out.
The new function is march_vertex() and it overrides upPos and lowPos. My algorithm isn’t perfect either. It gets the middle point by the middle of the list between the corner points. I’m going to change it to measure which is closest to the middle in space.
And ultimately the orientation is caused by the way t_arrow is calculated using transform.getTransformLookingAt. A better algorithm could likely be found that would make the eye orient to a better plane, or by using the centroid of the 4 points instead of the average. Also, if you use an aim controller in the eye_rigger GUI tool, it doesn’t use that as an orientation. And it could.
In your specific example, t_arrow could be calculated simply by using a point exactly ahead of the center of the eyeball.
1 Like