animation

cosc x77 - computer graphics

animation representation

• shape specification as a function of time
• many ways to represent changes with time
• intent
  • artistic motion
  • physically-plausible motion
• efficiency
  • typically not a major problem
• control
  • most algorithms concerned with this

animation editing

• different techniques for different processes
• key-framing
  • describe key poses, interpolate the rest
  • man-made process: laborious but artistic
  • good for characters
• procedural animation
  • motion expressed algorithmically
  • good for small secondary motion or special effects
    • e.g. clock animation

animation editing

• different techniques for different processes
• motion capture
  • reproducing performances
  • good for character, but requires lots of hand-tuning
• physically-based simulation
  • assign physical properties
  • simulate physics
  • realistic, but difficult to set up and control style

principles of animation

• classic artistic choices in hand-drawn animation
  • now used to describe computer animation
  • non-technical description
    • can't build algorithms on
    • but useful to think about what the goals are

principles of animation

• squash-and-stretch

principles of animation

• squash-and-stretch

	slow motion
	fast motion
	fast motion w/ s.s.

principles of animation

• timing

principles of animation

• anticipation

animation

movie time: luxo jr.

how animation works?

• flip very fast a set of fixed images
• perceived as motion by our visual system
• how many images per second?
  • shoudl be above flicker fusion: > 60 Hz
  • NTSC TV signal: 60 half-frames per second
  • movies: 24fps repeated 3 times

motion blur

• avoid aliasing over time
  • equiv. to color "averages" to remove "jaggies"

representing changes

• one frame-at-a-time
  • inefficient and cumbersome
• key-pose animation
  • define key poses
  • interpolate in the middle

key-frame animation

• used in 2D hand-drawn animation
  • head animators define key poses
  • in-betweeners define intermediate poses
• same conceptual framework
  • animator defines key poses
  • computer interpolates intermediate poses

key-frame animation

key-frame animation

• how to define interpolating function
  • choose smooth curve formulation: splines
  • interpolation is not rock-solid

key-frame animation

• feedback comes in various forms
  • animation playback
  • parameter curve
  • ghosting

key-frame animation

• what to interpolate?
  • shapes are defined by control points
    • too many controls for animation purposes
  • express deformation with meaningful parameters
    • deformation: changes in shape
• degrees of freedom
  • modeling: number of control points
  • animation: parameters of deformations
  • ui: parameters of manipulators
  • use smallest number of degrees of freedom

deformation examples

• rigid body transformation
  • translation/rotation
  • shape is unchanged

\[\point{p}' = M \point{p}\]

• modeling representation
  • move all the control points: \(n \xx 3\) DOFs
• deformation/animation transformation
  • translation + rotation vector: \(6\) DOFs

deformation examples

• deformations change shape
  • introduce different functions
  • limits on the type of deformation

\[\point{p}' = f(\point{p},\{\alpha_i\})\]

deformation examples

deformation examples

deformation examples

• using a lattice of control points
  • key idea: size of lattice is smaller than model

complex deformations

• complex deformation by function composition
  • no unified description
  • so apply one after the other

\[\point{p}' = f_1(f_2(\point{p}))\]

deformations and control points

• should we deform control points or the surface?
• in general, deforming control points is wrong
  • cannot prove that the surface is equivalent
• in practice, deforming control points is ok
  • control mesh is tessellated enough
  • many useful transforms are well-behaved

deformations for characters

• often combination of lots of deformations
• specialized deformations
  • mesh skinning: body deformation
  • blend shapes: face deformation

mesh skinning

• deform surface around a skeleton

mesh skinning

• concepts based on skin/bone interactions

mesh skinning

• every bone has a transformation: \(M_j\)
• every bone-vertex has a weight: \(w_{ij}\)
  • user provided, often zeros for most pairs
  • typically not zero only for close enough "bones"
• deformation is weighted average of positions transformed by every bone
  • weighted by the vertex weight

\[\point{p}_i' = \sum_j w_{ij} M_j \point{p}_i\]

mesh skinning

• deformation often defined for a rest pose
  • positions are defined in model space
  • reference matrices for model-to-bone transform

\[\point{p}_i' = \sum_j w_{ij} M_j {M_{ref}^{-1}}_j \point{p}_i\]

• normals use inverse-transpose formulation

mesh skinning

• solution for body deformation
• efficient to compute
  • hardware acceleration available
• good control
  • but hard to set up proper weights
• often used in games as-is
• used in movies as part of more complex set-ups

mesh skinning issues

• surface collapse
  • around joints or for strong twists
• hard to fix
  • cannot be fixed by tweaking weights

mesh skinning - defining weights

• often very time consuming: active research

mesh skinning - efficiency

• hard to use, but really fast implementations (Project Page)

blend shapes

• interpolate set of meshes

blend shapes

• user provides a set of meshes with same topology
• final mesh is weighted sum of base meshes
  • weights have to sum to \(1\)

\[\point{p}_i' = \sum_j w_j \point{p}_{ji} \qquad \sum_j w_j = 1\]

blend shapes

• solution for face deformation
• efficient to compute
  • albeit increase memory usage
• great control
  • but only works for small deformation
  • cannot produce "novel" shapes
• often used in games

interpolating deformations

• just interpolate deformation parameters
  • translation: position
  • rotation: quaternions
  • bending/twisting: angle
  • skinning: skeleton translation/rotation
  • blending: blend weights

interpolating translations

• linearly blend the translation keys
  • for linear \(f\), \(\v(0.5)\) is the midpoint between the keys

\[\v(t) = (1-f(t))\v_0 + f(t)\v_1\]

• define a spline passing by the translation values
  • additional controls define speed and acceleration

interpolating rotations

• how many degrees of freedom do rotations have
  • 3, 1 for angle and 2 for direction
• what is a good representation for rotation?
  • matrices
  • Euler angles
  • quaternions

interpolating rotations

• using matrices is problematic

\[M(t) = (1-f(t))M_0 + f(t)M_1\]

• for linear \(f\), \(M(0.5)\) may not be a rotation
  • e.g., \(M_0\) is identity, \(M_1\) is \(90^{\circ}\) rotation about \(x\)
  • \(M(t)\) is not a rotation, since \(MM^T\) is not \(I\)

\[M(0.5) = \mat{1 & 0 & 0 \\ 0 & 1 & 0 \\ 0 & 0 & 1}\mat{1 & 0 & 0 \\ 0 & 0 & 1 \\ 0 & -1 & 0} = \mat{1 & 0 & 0 \\ 0 & 0.5 & 0.5 \\ 0 & -0.5 & 0.5}\]

interpolating rotations

• Euler angles
  • rotation around 3 different axes
  • can represent any rotation
• interpolation is unnatural
  • \(90^{\circ}\) around \(Z\) then \(Y = 120^{\circ}\) around \((1,1,1)\)
  • \(30^{\circ}\) around \(Z\) then \(Y \neq 40^{\circ}\) around \((1,1,1)\)

interpolating rotations

• gimbal lock
  • may lock degrees of freedom when interpolating

interpolating rotations

• matrices: incorrect rotation
• Euler angles: unnatural and gimbal lock
• quaternions: nice mathematical framework
  • won't cover in depth
  • intuition: interpolate rotation as point on sphere

providing deformation parameters

• kinematics
  • provide transformation parameters directly
  • hand-editing
    • forward kinematics
    • inverse kinematics
  • motion capture
• dynamics
  • solve physics equations of motion

forward kinematics

• artists define transformation parameters directly
• hierarchical transformations
  • used for bone structures in character animation
    • e.g. skeletons or robots
  • hard to define what happens at end of chains
    • e.g. which angles should the leg be to have the foot touch the floor?
    • done by trial and error

forward kinematics

• position at end of the chain

\[p_x = l_0 \cos \theta_0 + l_1 \cos(\theta_0 + \theta_1)\]

\[p_y = l_0 \sin \theta_0 + l_1 \sin(\theta_0 + \theta_1)\]

inverse kinematics

• specify directly the position at the end of chain
  • easier to control motion, less trial and error
  • joint angles solutions by inverting previous eqns.

inverse kinematics

• more bones results in under-constrained system
  • infinite number of solutions
  • which solution to pick?
  • impose constraints: minimize energy function based on plausible motion

inverse kinematics

• or try to capture "styles"
  • by learning from data sets

motion capture

• record motion and play it back
  • how to record: motion capture systems
  • how to apply motion to digital characters
    • motion editing
    • motion retargeting

motion capture usage

• heavily in games, a bit in movies
  • not very expressive, but higher expectation

motion capture systems

motion capture editing

• motion capture generates too much raw data
  • how to edit it? try to fit with lower DOFs models
• motion retargeting
  • capture from actor A, but apply to actor B
  • how to do this in a believable manner?
• clean up motion
  • noise present in data / too little DOFs
  • how to clean it up?
• often just starting point for manual animation

kinematics vs. dynamics

• kinematics: specify parameters directly
• dynamics: solve the equations of motion
  • physically based animation
• rigid body dynamics
  • solve rigid body equations
  • collision detection
  • doable in many cases
• more complex cases almost impossible
  • cannot model physics accurately enough
  • simplify for good-enough solutions

dynamics

• animation from dynamics is accurate
  • since we are simulating physics
• at the price of less artistic freedom
  • cartoon physics
• control-vs-correctness triage often hard
  • interests in mixing dynamics with kinematics
  • open research issue

dynamics

• simulating simple objects

dynamics

• simulating complex situations

dynamics

• simulating complex objects

controlling dynamics

• basic principle: cheat where you can

animation

movie time: for the birds

natural phenomena

• often done by physical simulation
  • looks like computational physics
• simulation domain
  • choose based on phenomena to define
    • e.g. smoke uses volumetric adaptive grids
    • e.g. cloth uses points/springs system
• simulation algorithms
  • very different ones depending on simulation domain
    • lots of open research
• Fedkiw site

natural phenomena

natural phenomena

natural phenomena

natural phenomena

particle system

• collection of particles
  • simple, since it is just simulating point dynamics
  • used heavily in special effects
    • complex phenomena represented as point/force collections
  • simplest dynamics formulation
• point properties
  • dynamics: position, velocity, acceleration
  • varying properties: color, temperature, lifespan
  • constant properties: mass. lifetime

particle system

• for each frame
  • create new random particles
    • where to create? along point/line/surface
    • artistic control
  • delete expired particles
    • random/lifespan/collision
  • update particles based on dynamics
  • render particles

particle dynamics

• Newton equation

\[\v = \frac{d\p}{dt} \qquad \a = \frac{d^2\p}{dt^2} \qquad \F(\p,\v,t) = m\a\]

• find position at time \(t\)
  • given position, velocity, and acceleration at time \(0\)
  • initial value problem: use Euler method
    • more efficient methods exist

\[\array{c}{ \p(0) = \p_0 \\ \v(0) = \v_0 \\ \a(0) = \a_0 } \rightarrow \array{c}{ \v(t+\Delta t) = \v(t) + \a(t)\Delta t \\ \p(t+\Delta t) = \p(t) + \v(t)\Delta t + \frac{\a(t)\Delta t^2}{2} }\]

particle systems example

particle systems example

particle systems example