CGTalk - help: eye look-at with uv coordinates

View Full Version : help: eye look-at with uv coordinates

DeFi

11-12-2006, 01:00 PM

Hi, everybody.

I have a little rigging problem. Since a sphere-look-at + fdd solution wasn't applyable for my new comic character, I tried to develop an eye control system that realizes eye movements by altering the uv coordinates of the eye materials. I ended up with a custom attribute driven script controller system that uses the following parameters to drive both eyes(Paul Neale's excellent attribute_holder script helped a lot with this, so: Thanks! :D ):

left/right: moves the eyes left and right
up/down: moves the eyes up and down
center: determines the eye crossing factor
size: the size of the pupil
squeeze: squeeze the pupil horizontally or vertically

This works fine but it would also be nice to have the possibility to drive the eyes by an object they always look at. So I placed two point helpers behind each eye. A zero-direction helper that always looks at a default position target for the eyes and a direction helper parented to the zero helper that always looks to the actual position target for each eye. Now my idea is, to get the angles between the x and y components of the rotation of the the direction helpers relative to the zero-direction helpers and drive the uv coordinates with this. So if you get an x angle of, lets say, 60° and x corresponds to up/down movements you make a linear contraint between the angle and the desired uv-offset.

So next thing I tried was, to wire the rotation components of the direction helpers in their parent space(they are linked to the zero-direction helpers) to the uv-coordinates. Unluckily the look-at controllers of the direction helpers had no values that contained these relative angles and the Euler-XYZ controller thats below it in the rotation list controller has some rotation values, but they would obviously not contain what I was looking for.

So I thought about using a script controller on the uv-coordinates as I did earlier for connecting them to the custom attributes. Digging the maxscript reference brougt out a nice piece of code that should be able to determine the angle differences between two objects. I modified the code a little bit and came up with this(eyeZeroDirection and eyeDirection contain the nodes to the two helper objects):

dParent = inverse eyeZeroDirection.transform;
dChild = eyeDirection.transform;
dResult = dChild * dParent;
rotQuat = dResult.rotation;
rotEuler = quatToEuler rotQuat order:1;
up_down = rotEuler.x;
up_down = up_down / 60.0;

Evaluate => no errors => Halleluja! But the strange thing is: Not only that nothing happens with the uv-coordinates while moving the eye targets now and thus changeing the direction of the direction helpers. In addition the track view and max now freeze for 30 seconds every time the new script controller is selected in the trackview. I spent the last three hours on fiddeling around with this, but the error successfully managed to hide from me. :sad:

So my question is: Does anybody see my error or has a solution for my problem? It would be very nice if you would sacrifise a little bit of time to help me on this.

Thanks

DeFi

DeFi

11-12-2006, 04:32 PM

Update: I just discovered that max flipped the coordinate system of one helper for some reason, making x the wrong axis. The eyes now move as the target moves but there's still this freezing of max. The time of freezing has a linear reationship with the number of scriptcontrolers using the method described above. So I changed all of them to a simple assignement of a constant and the freezing dissappeared. So it's obvious that the reason for freezing is some kind of evaluation of the script, but this doesn't happen when the evaluate button ist pressed, only when max tries to refresh the animation curve of the controller in the track view.

Is there a way to get around that? Perhaps an easyer way to get the needed relative angle values or a way to speed the script up?

EDIT: The really slow part of the script seems to be to get the .transform property. Even getting a .rotation property of a node isn't faster.

timothyc

11-13-2006, 04:46 AM

There's an easier way. Try this:

1. Make a sphere (this is the eyeball), and a NURBS plane.

2. Line up the plane perpendicularly to the sphere so that its borders completely surround the sphere.

3. Apply a SurfaceMapper(WSM) to the sphere and pick the NURBS plane. Note the default Map Channel of 1.

4. Apply your iris texture map to the sphere, map channel = 1.

5. Make a point helper as your lookat target.

6. Apply a Lookat constraint to the NURBS plane, choosing the Z axis as its lookat axis. Pick the point Helper as the lookat target.

What this does is project the NURBS's UVs on to the sphere, where they are used as mapping coordinates.

TC

DeFi

11-13-2006, 09:59 AM

Hi,
thank you very much for your answer. :)
I tried your solution with my characers mesh instead of the sphere and it worked fine but I noticed two little problems:
1. If I make the system look at points that move the iris to the corner of the eye I get UV-distorsions(the iris is squeezed), because the surface of my eyes is far from being a sphere.
2. The eye movement isn't limited to some maximum angles. So, if I make the system look at points at one side of the character the iris of the eye on the other side tends to dissapear earlyer than the other.

For my character it's important to have no uv-distorsions in the eyes if you look at it from the front. To achieve this I applied a planar mapping for each eye after the morph modifier. So the eye textures stay perfectly in shape even if a morph target requires to deform the geometry of the eye a little bit. In addition the center of the iris should be limited to the visible area of the eyes. Thats because I want to be able to move the target at a big circle and the iris follows but always stays 100% visible. I think I'll use this as a fallback, if I don't find a faster way to get the required angles for my solution.

CGTalk Moderation

11-13-2006, 09:59 AM

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.