Warner brother facial setup


Hi everyone, I would like to rig a cartoony character with really wild/broad facial expressions. Which techniques would you recommend me. I looked on Google and could only find links to few DVDs. Are there any free tutorials around?

I have experimented with Blend shapes but it looks like I might be better off using something a bit different. On the Fahrenheit DVD which came out few years ago, they were recommending some techniques using hair follicles or the rivet script but I am wondering if there are any new way of rigging extreme facial expressions.



I doubt that there are revolutionary techniques that evolved since the fahrenheit dvds since maya hasnt evolved in this area since then. There were some super-cartoony-dvds from maya/alias/autodesk available, but dont know how they compare to the fahrneheit ones. I have both mentioned and they are surely worth the investment.

edit: with the "dont know how to compare" thing I mean they both have very valid strategies to achieve advanced deformation effects, but I cant judge which is “superior” to the other. Both offer great infos.


Jason Osipa’s book Stop Staring, the second edition goes into
this type of setup.

It’s a very good setup he uses for extreme facial poses.


Facial rigging, there are many techniques used. For a warner brother type toony facial rig, you can go through Jason Osipa’s Stop Staring Book which explain a wide range of techniques involving creation of blendshape, layering deformation, using lattice, bend deformers etc.

What I suggest is that there are a lot of cool resource in the web, absolutly free. You can search video for facial rigging in youtube and vimeo and I am sure you will find a lot of free resources.

Also, I did a little tutorialback which involves joints to deform the face, but for warner brother type animation, I suggest using blendshapes, joints and various deformers such as lattice, bend etc all together.


You can find some useful resources in highend3d.com as well, such as tutorials and rigs made by other peoples. You can dissect and operate on these rigs to find out more…:scream:





oh thanks a lot guys! Actually I went through the first edition of Jason Osipa’s book this week and really liked it but he kept mentionning Expressions when nowadays I have been told they should be a no-no and people should favor Nodes instead. The book was printed when Maya4 came out though.

I will check your links and have a look at the new edition of Jason’s book then.

Thanks a lot.




The second edition is much more up to date, and includes a few extra bits that make it worth picking up if you don’t own one of them. I still need to get my copy. ^_^;

Expressions are bad in that they tend to break at the least opportune of moments. Also, they execute the most slowly of anything you can do in Maya. There are certain ways to use them that can keep execution moving quickly but yeah, for the most part everything you want to do can be accomplished through direct node connections, utility nodes, and a little planning.

I don’t want to start a flame war but another really slow thing to use are driven keys. They can also, in most circumstances, be replaced with a collection of clamp and setRange nodes. When you can avoid them I recommend doing so.

The Farenheit DVDs are brilliant, but they’re also quite old at this point. Still, as a foundation they’re terrific, as are the Art of Rigging I and II book / DVD sets. I think Art of Rigging I is the most important thing a rigger could read for Maya despite its age; it’s just so comprehensive. It’s not specifically focused on faces but the tricks it teaches work across the board. I still flip through that book and find new things I can use, and the scripts that come with it are priceless starting points. They’re $20 each now, download only, so you have no reason not to pick them up. :slight_smile:

Lastly, be careful with the rivet script. If you put one on an area that deforms greatly, your rivet will often twist and spin. It’s an easy fix that I wrote a blog post on a while back here:


really cool, I only went quickly through your blog post. You are talking about Nurbs but my character is modeled in Polys. Can this apply too? I will save your post and read it at home (no internet at home)

Thanks again


That was new to me, that driven keys are slow. What is it that makes them slow? It´s just an animationcurve? I tend to use them quite alot without thinking too much about it, but on the other hand I would want better speed in my rigs … maybe a pattern can be seen :slight_smile:

// Otto


Interesting you say this - this guy on this post here claims to have done speed tests and saw that SDKs evaluate faster than multiple nodes (of course, this would totally depend on many things).


Meh, I don’t agree. ^_^; In all honesty I haven’t used them since we upgraded to 2K9, so there could have been some nice speed boosts.

However, in my experience the large majority of driven keys you see in rigs and in general are basically linear expressions – for example, mapping a 0-1 value to a 0-90 degree rotation. Sure, people use driven keys for things like complex animations that need to be driven by one channel, and in those cases I think they’re acceptable. But doing simple math on paper and replacing that driven key anim curve with a single multiplyDivide, setRange, or even a unitConversion is faster in my experience. (UnitConversions are my new favorite trick – they’re a bit faster than multiplyDivide, so when you’re only running a single value into a multiplyDivide you can use them instead.) Or running a value through a reverse node as opposed to making a driven key reverse a relationship.

There are other reasons for not liking driven keys, too. For starters, if you wanted to do something to all the anim curves in a scene, you have to be smarter about where you’re pulling them from (IE, you’d have to specify each and every character control) as opposed to traipsing through the DAG. That’s caused problems in scripts a few times, and adds a layer of complexity that I’m not a fan of, although you can add a custom attribute to driven key curves that can help scripts skip over them.

Bottom line, I’m not saying not to use them. I still use them on occasion; I just try to find way to not do so. If you want to be convinced about the speed, set up a simple mel script that creates ten thousand or so objects and does timing tests between driven keys and similar node networks. Create some funky random animation and time how long it takes to do step through a hundred frames. Never take anyone’s word for it-- you have to find your own way. In the end whatever makes pictures easily and with stability is the right choice.

As far as what makes them slow: my guess is just that their math is a bit more complex (solving equations to get a smooth point value as opposed to simple multiplication). Not a huge amount more complex (I had a PDF somewhere of how they’re calculated but I can’t find it right now), which means that at a certain point they would be faster than a large node network. The other thing I’ve wondered is how they’re cached. I’m not sure that animCurves are cached the same was as other Maya nodes. But they could be.


Put a rivet on one of your characters and then check its hypergraph connections – the original author’s ingenious idea takes two edges, lofts a nurbs plane between them, then uses that with a pointOnSurfaceInfo node and an aimConstraint node to position the locator. Me doing that on a nurbs surface is just taking out the extra steps; you can affix rivets to areas of great deformation by changing the connections as I specified in my post.

Most of the time you don’t have to worry – lots of great rigs have used rivets without fail. It’s just in certain circumstances that it will start twisting. I never had any problems until I used them to make ribbons for bird wings.

The reason is this: the original script uses the surface normal and one of the tangent vectors to align your locator to the aim constraint. When the surface start changing drastically the plane that the normal and a single tangent vector create don’t necessarily match up with the other tangent vector, causing the flip with the aim constraint; this is especially evident on long, skinny nurbs planes like ribbons. Since the two tangent vectors are always orthogonal on a nurbs surface at any one point, they’re a more stable choice.

If you’re worried, though, you could always use follicle nodes. Maya 2K10 has all the hair stuff that 2K9 Complete and prior lacked, so tricks like the rivet are no longer necessary.


u can get very good results by using muscle system of maya .
I don’t know any step by step tutorial on the web .but I made a clip that shows how will be the result hope it gives you the idea how you setup that face.


I am finally back home. Thanks everyone for participating to that thread, it will take me few days to digest all those great infos. I also bought the second edition of Jason Osipa’s book and found some interesting things. I am surprised he is still using expressions for connecting the blend shapes to his UI but maybe there is no other way…

Thanks again especially kattkieru



Never take anyone’s word for it-- you have to find your own way. In the end whatever makes pictures easily and with stability is the right choice.

Exactly don’t take my word for it, try it. For me it works perfectly fine, and I’ve done complicated thing with them they are very reliable and easy to setup (after all there are simply animcurves) now the test we’ve done here comparing the speed in the hypergraph, show that one set drivenkey evaluate about the same speed as any other node so I wouldn’t make a all lot of node to try to mimic one setDrivenKey if it isn’t necesary. Now that’s just me it works for me I usually have the real time result I expect (compare to expression that are slow although multithreaded now) so like I say I’ll continue to use them and wouldn’t say to avoid them.



Ok I might add a couple thing I forgot actually to give you an exemple in pair with the thread subject (which is not are set driven key good or bad :slight_smile: ) We’ve setup in the past a system that was quite powerfull I thought, and that I still use now but since I’m not doing much setup anymore there might be other way that are better…;here is how that stuff works: it was actually for facial setup, all or facial setup was bone driven (same structure of bone for all face) powerfull since you can easily (almost) duplicate it from one character to another and have simply minor touch up for the skinning.
The system was that we would actually animate the bone in a non linear way since muscle follow a non linear structure it give much more credibility that blendshape. So all the bone necesasry for a pose would be animated in a file from let say 0-10 frames. We would then have a script that would reference the file with the animated pose read the animation and convert the movement of the keyframe to setdriven connect to an UI (Osipa style) that would drive the animation. In that particular case we had realtime on our face and franckly I don’t see any otherway we could have achieve that without using driven key. Ok that’s an exemple it works for us, it’s not something new or revolutionnary but drivenkey were the backbone of the system I would say simple and effcient for what we had to do. Good thing with that system is that we had animators creating the shapes :).

Ok that’s it for now in favor of drivenKey :smiley:



thematt, are you from Angouleme? I was there working for 2minutes this summer, small world :wink:

Interesting what you are saying about animators creating Blendshapes, I think I heard that’s what they do at Pixar and probably other Feature animation studio but I don’t have anything to back this up.

Setdriven keys or nodes, I guess a good rigger should evaluate both when working in production and see which one is the fastest for the animators.

I just came back from a gig where the playback of the rigs was 2 fps, I can tell you that wasn’t fun to animate. Luckily by playing around with the setup and disabling few things durning the animation process, I managed to find a way to get a more manageable speed.

that’s actually the reason I am now trying to learn that stuff. In that company a rigger had been hired to do the rigs before the animators joined the company and obviously he had put some fancy features that slowed down the rig drastically and didn’t even do what we wanted them to do.


mais oui carrement on s’est croisé! je travaillais juste en dessous de toi :wink:

Like you said sometime rigger add a lot of unnessary thing to the setup because they don’t know what the animator are going to do with it, it’s important both works together. A setup must be fast and realiable but it’s true that now the characters are supposed to do more and more stuff with all kind of deformation and that leads to complex setup that are most of the time slow, so yes sometime minor thing like using node can speed up the viewport considerably! like kattkieru says there are nodes that are very fast…what I found also is that parent constraint for exemple slow down your setup a lot and there is simple way to avoid them, I’ve seen big gain on doing just that on couple setup I’ve test it on (not production proven though only on testing it myself)…

next time you’re in town hook me up :smiley:



No he doesn´t, he uses math-nodes now. I think he even writes that in his book?

I use the stuff from his shelf(AWESOME stuff), and there a no expressions there. Just lots of tricky connections with math nodes, with great UI-respons and no real speed-problems in rig with the system


with the jsfacialwin.mel it is very easy to setup faces osipia style. I use it all the time and it uses math nodes AFAIK