Emru Townsend: So how does one program (or engineer) for animation? How much of the animation process are you required to know? Or, how much is it a good idea to know?
Flip Phillips: I'll back-door that answer by first citing a little bit of history...
One real unique thing about Pixar's animation system is that it was written to an FDA's (Former Disney Animator--John Lasseter's) specs by a couple of rather amazing programmers (mainly Bill Reeves and Eben Ostby). When you sit down to use it the 'feel' and lexicon of the system is similar to the way you do things when you're drawing or when you're shooting footage. The guys that created the system (and the additional people that are now expanding it) are very good at co-opting the knowledge of the animators, adding their unique knowledge, and in a glorious sun-shiny collaboration, producing a really good set of tools to work with.
I have drawn animation experience but I was only a user of the system. But I feel like if you are a programmer/engineer it's part and parcel of the job to be quite conversant, if not an expert, with the 'process' you are trying to 'engineer'. You might be able to make a system that animates happy-big-eyed-massive-pupil characters based on your blood pressure or foot muscle flexions... that in itself would be amazing. But you'd probably have quite a time getting drawn or stop motion folks to use it... it'd be a quite novelty though... might sell well back in Marin.
You kind of get into this revolution vs. evolution thing, though. Maybe toe twiddling is the ultimate way to animate and we just don't know it yet. It's not much fun just 'implementing' old ideas on a computer (well, for most people it isn't). Some evolution has to come of it or else it is a pretty boring effort. But to make that evolution or perhaps that rare revolution it's probably not a bad idea to stand on the shoulders of giants (or other really big things), know a little about how Frank and Ollie did it... [Frank Thomas and Ollie Johnston, two of Disney's legendary Nine Old Men. --Ed.]
So in summary, I'm a big 'as much as you can know' kind of person. If'n yer an animator it really can't hurt much to learn about how a computer works. It isn't requisite, but it can't hurt. Same goes for the engineering crowd with respect to animation. The end result is that both groups are able to converse in some mishmash of a common language. To be a good 'computer animator' you have to be a good 'animator'. 'Animator' is the key word there, not computer. Keep chanting to yourself, "The computer is only a tool, the computer is only a tool", unless you're in Tony's shoes, in which case the mantra is "The computer is only a means for my existence, the computer is only a job." Or something like that...
Tony Apodaca: I agree wholeheartedly with Flip, although this is probably not surprising since we "grew up" together in the same organization.
There are lot of companies out there who take computer-savvy people, and try to make animators out of them. At Pixar, we take animators and give them computerized pencils. Animation is an art, typing is a skill. You are born with the ability or inability to animate, and in fact the really good animators in the world have all spent time experimenting with lots of different media--sketches, painted cels, stop-mo, clay--and computers are just another medium. Hey, we just had a puppeteer give a talk here, and most of the animators in the company had experimented with that, too!
One example: I just saw a demo reel from a small CG software company. It was really sad. It was clear that the reel was mostly a few programmers using their system, and while these things might be the most exciting animations those programmers ever personally did, they were so bad. You wanted to say, "Hey, my 3-year old can animate better than that!" And then on the reel there was one really good-looking piece, and if you immediately thought "Professional Animator", you were right.
When I say "a lot of companies out there", I basically mean animation software development companies. Most of the production houses have learned (by watching Pixar or from hard knocks) that you need to hire animators, and reports are that the graduates of all the good animation schools are now descended upon in droves by CG production companies. Sure, there are not enough animators to go around, and so people do end up hiring a few non-animators-but-with-potential just to fill in the gaps, but they try.
However, the software still behaves as though the user is very computer-literate, and understands the details of computer graphics algorithms and research. Clearly, in order to sell a product in a cut-throat market, it is a cool thing to advertise "Inverse Kinematics." But what does that mean to a guy who just graduated from art school?
Now, let me clarify one thing, because Flip and I both glossed over this because it is second-nature to us. The Animation System at Pixar is not for animators. And it is not for programmers. It is for animator-programmer teams. In every piece of an animation project, there is a person (called a TD [technical director]) whose job it is to handle all of the programming tasks of the project. He writes hundreds of little programs to handle all phases of the animation (model, lighting, shading, physical dynamics, compositing, shell scripts, more shell scripts, etc.). He delivers to the animator a "model" which the animator animates. The animation system (as Flip said) is organized to let the animator work "in animation terms," without knowing anything about what weird relational database tricks or state-of-the-art CG research was done to provide that model. They go back and forth, the animator asking for certain extra "features", the TD providing the best he can with the technology at his disposal.
This division of labor gives each person the task that they are good at without burdening them with something they are not good at (and perhaps not interested in). Oh, sure, over time you do learn some of that stuff by osmosis, but you don't need to in order to do your job well.
So, you ask about engineering. As Flip mentioned, on any computer engineering project, be it aircraft flight controls, or supermarket inventory management, or computer graphics animation, you cannot be a good engineer unless you listen to your customer, understand his wants and needs, and provide a system which addresses his problem without burdening him with a bunch of your problems. Oh no, the Sybase database can't handle more than 10,000 different UPC codes? Too bad, not his problem. You can't very well tell the supermarket to stop carrying more than 5 different mouthwashes. You have to solve your own technical difficulties yourself.
And so it is in CG. If you are an engineer here, you address the needs of the animator without burdening him with the limitations of the computer, or forcing him to learn a lot of computer arcana which is superfluous to his task. This means that you need to learn a lot about how animation is done, even if you are not very good at it yourself. You learn about what animators enjoy and want to do themselves, what they think is boring and would rather have handled automatically, how they were trained to use their traditional tools and what peeves they have about them. And you will probably never, ever do any real animation yourself.
And I can guarantee, the animators will never write any shell scripts, either.