View Full Version : rig cartoony eyes with bones only!
02-11-2009, 12:27 AM
the standard technique for rigging a non-spherical, skewed, cartoony eyeball has always been to deform it through a lattice deformer or FFD. there are a couple of other techniques, but not appropriate for my current dilemma...
i need to rig a cartoon (oval-ish) eye for export to a game engine, therefore i can only use bone data. no deformers & no scale values on controllers. i had seen an example before where rotational data on the eyebones drove the uv coordinates of the eye texture. i'm not entirely sure how to set that up or even get that info to an engine (which is granny runtime in this case). if anyone knows how to set that up, i'd be interested in hearing about it.
mainly, i'm looking for some alternative ideas on how i can achieve this with the restriction being conventional bones & skin only. since i'm looking for some theories, i've posted here in the general rigging forum. ideas don't need to be app specific, what can be done in one app can be figured out in another.
any help is appreciated!
This will be a hard one as you are limited by the engine and not by any given app. Can anything be written for the engine to help with the problem? Even just a simple Xform type modifier that will deform the eye in engine? Sliding UV's would be a great idea but I have not worked with an engine that will handle that without some custom code. Could it be handled with a series of morphs? Expensive in game how ever.
02-11-2009, 08:04 PM
Before you even experiment with your previous theory, you would have to check and see if your game engine is even using UV coordinates or is it baking them & the texture into the model when you export it?
You mentioned that you can't scale controls, can you scale the bones?
Can you use expressions? Set Driven Keys (or equivalent)? What constraints are you limited to?
Here is what I suggest if you are able to scale joints (I'll explain this in Maya Terminology):
1) Detach the iris/pupil from the geometry and move it very slightly above the eye.
2) Create 2 Joints: 1 to pivot from (I placed mine at the back of the eyeball because of the particular shape) and 1 for the pupil to skin to (Should be in the center of the pupil).
3) Create Set Driven Keys (or an expression) on the pivot joint so that when you rotate it side to side and up to down, it will scale out to keep the pupil joint slightly above the eyeball.
4) Create Set Driven Keys (or an expression) on the pupil joint to rotate slightly to keep the pupil from penetrating the eyeball geometry.
5) Create an aim control.
6) Create an Aim Constraint from the aim control to the pivot joint.
7) If needed, Limit the translates on the aim control to avoid unwanted problems.
If you aren't able to scale joints, maybe instead you could translate the pupil joint out instead of scaling the pivot joint.
I've attached a Maya .ma for you to play with and see if it will help you. I think that you can open .ma files with a Maya PLE, right? The version is 2008 on the file. Hope this helps!
02-12-2009, 11:08 AM
I think you have 2 main approaches:
1) Use bones attached to the eye that is rigged with an Xform modifier
2) Make Morphs from an eye that is rigged with the Xform modifier
The second is viable only in case the engine works with Morphs, and if it does you can animate the eye motion and combine it with morphs. The bones way is a bit trickier as you will need to see where exactly you need those bones, and also how many bones you can afford to use for this. In general, for games it is advisable to avoid non round eyes as it such solutions will require more memory consumption. Even though morphs are more expensive then bone animation by default, it might end up being that using 3 morphs over 10 extra bones will be better. So basically you need to evaluate your given situation, but from my experience these are the only two options you will have. Engines do not often support xform modifiers as they are not the cheapest to use at run-time.
02-12-2009, 11:08 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.