A finished shot — a character winding up and hurling a ball across the frame — arrives on screen as a stream of pixels, twenty-four or more images a second. But nobody paints those pixels by hand. They are the output of a long assembly line that starts with an empty scene and an idea, and ends with light hitting a virtual sensor. That assembly line is the animation pipeline, and learning where every technique in this course plugs into it is the single most useful map you can carry.
This page walks the whole pipeline end to end: the stages that turn an idea into frames, the four different ways we actually create motion, the tools (Maya, Blender, Houdini) that host the work and the shared data structure underneath them, and — as a running example — one shot of a character throwing a ball, traced from blank scene to final image.
A production pipeline is a directed flow of stages, each consuming the output of the ones before it. The exact names and order shift between studios, films and games, but the canonical CG-feature pipeline runs like this:
The dependencies matter more than the exact ordering. You cannot rig a model that does not exist, or animate a rig that has no controls, or render a scene with no lights. Each stage is a contract: it hands the next stage a well-defined artefact — a mesh, a rig, a set of animation curves, a cache of simulated points, a stack of image layers.
"Animation" as a stage hides a deeper question: where does the motion come from? There are four fundamentally different sources, and a real shot mixes all of them. They trade off along one main axis — control (how directly an artist dictates every detail) versus plausibility (how automatically the result obeys physics) — and a second axis of cost.
| Method | Motion comes from… | Strength | Weakness |
|---|---|---|---|
| Keyframe (pose-to-pose) | an artist setting key poses; the tool interpolates the in-betweens | total artistic control; the standard for acting and appeal | labour-intensive; physical plausibility is the artist's problem |
| Procedural | a rule or algorithm evaluated each frame (noise, oscillators, boids) | cheap, scalable to thousands of elements, tweakable by parameters | indirect control; hard to hit an exact authored pose |
| Physically based simulation | numerically solving equations of motion under forces and collisions | automatic, richly plausible secondary motion (cloth, fluids) | expensive; notoriously hard to art-direct to a precise outcome |
| Motion capture | recording a real performer and mapping the data onto the rig | captures the subtle realism of a genuine performance, fast | tied to what was performed; retargeting and cleanup are fiddly |
Read the table as a spectrum from most authored to most solved. Keyframe animation is pure authorship — every nuance is an artist's choice. Simulation is the opposite — you set up the world and let the maths decide. Procedural motion and motion capture sit in between: rules and recordings that an artist steers rather than dictates. Later modules of this course are, in effect, deep dives into each of these four sources.
The pipeline is hosted in DCC applications — Digital Content Creation packages. Three dominate:
| Tool | Known for |
|---|---|
| Maya | the long-time industry standard for rigging and character animation |
| Blender | the free, open-source all-rounder covering the whole pipeline |
| Houdini | the procedural / node-based powerhouse for FX and simulation |
Underneath their different interfaces they share one core idea: the scene is a directed acyclic graph (DAG), also called the scene graph. Nodes are objects, transforms, deformers and operations; edges express dependency and parenting. A child transform inherits its parent's transform, so moving the shoulder carries the elbow, wrist and hand with it. Evaluating a frame means walking this graph in dependency order.
Houdini makes this graph the whole user interface — you literally wire nodes together. Maya and Blender hide most of it behind viewports and outliners, but the DAG is still what they evaluate. Once you think in graphs, "parent the ball to the hand, then un-parent it at the frame of release" becomes an obvious edit rather than a mystery.
Trace a single three-second shot through the pipeline and watch each stage hand its artefact to the next:
Notice how the same ball is authored one way (parented, keyframed) before release and solved another way (simulated) after it. That hand-off — from authored to solved motion — is the crux of the next warning.
It is tempting to lump all moving things together, but the pipeline draws a hard line. Animation is authored motion: an artist decides, frame by frame or pose by pose, exactly what happens — you can grab any moment and change it directly. Simulation is solved motion: you specify initial conditions and forces, and a numerical solver computes the result — you cannot simply drag frame 40 to a new pose, because frame 40 is a consequence of the physics, not an input.
Conflating them causes real grief. Artists new to simulation try to "fix" a bad cloth frame by moving it, only to have the solver overwrite their change on the next run. Conversely, trying to hand-animate every fold of a cape is a fool's errand — that is what a solver is for. The professional skill is knowing which motion to author (the acting, the key beats, the ball's throw) and which to solve (the cloth, the splash, the ball's flight), and then art-directing the simulation indirectly — through forces, constraints and tuning — rather than by grabbing frames.
The tidy left-to-right diagram is a lie of convenience. In reality a shot ping-pongs: a lighting problem sends it back to modelling for a fixed surface; a director's note sends a rendered shot all the way back to animation. The value of the linear picture is that it names the dependencies — you still cannot light before you model — and modern studios lean on this with USD (Universal Scene Description) and layered, non-destructive workflows so that a late change in one stage does not force every downstream stage to be redone by hand. The line is the dependency order; the real process is a lot of small loops within it.
Every module ahead is a zoom-in on one part of this map. Keep the pipeline picture in mind and each topic has an obvious home:
You are, right now, standing at the very start of the map. Everything that follows is a stop along this pipeline.