CSCE 552 Spring 2010

CSCE 552 Spring 2010

Animation

By Jijun Tang

Announcements

Homework #3 due Mar 19th

Group based A model to be used in your own game

Second demo Very Early April A demo is needed

Animation Overview

Fundamental Concepts Animation Storage Playing Animations Blending Animations Motion Extraction Mesh Deformation Inverse Kinematics Attachments & Collision Detection Conclusions

Different types of animation

Particle effects (fire, smoke, etc) Procedural / Physics “Hard” object animation (door, robot) “Soft” object animation (tree swaying in

the wind, flag flapping the wind) Character animation

Example

Quaternions

Quaternions are an interesting mathematical concept with a deep relationship with the foundations of algebra and number theory

Invented by W.R.Hamilton in 1843 In practice, they are most useful to use as a

means of representing orientations A quaternion has 4 components

3210 qqqqq

Keyframes

Motion is usually smooth Only store every nth frame (key frames) Interpolate between keyframes

Linear Interpolate Inbetweening or “tweening”

Different anims require different rates Sleeping = low, running = high Choose rate carefully

Linear Interpolation

The Bézier Curve

(1-t)3F1+3t(1-t)2T1+3t2(1-t)T2+t3F2

t=0.25

F1

T1

T2

F2

t=1.0

t=0.0

Animation Blending

The animation blending system allows a model to play more than one animation sequence at a time, while seamlessly blending the sequences

Used to create sophisticated, life-like behavior Walking and smiling Running and shooting

Blending Animations

The Lerp Quaternion Blending Methods Multi-way Blending Bone Masks The Masked Lerp Hierarchical Blending

The Lerp

Foundation of all blending “Lerp”=Linear interpolation Blends A, B together by a scalar weight

lerp (A, B, i) = iA + (1-i)B i is blend weight and usually goes from 0 to 1

Translation, scale, shear lerp are obvious Componentwise lerp

Rotations are trickier – normalized quaternions is usually the best method.

Quaternion Blending

Normalizing lerp (nlerp) Lerp each component Normalize (can often be approximated) Follows shortest path Not constant velocity Multi-way-lerp is easy to do Very simple and fast

Many others: Spherical lerp (slerp) Log-quaternion lerp (exp map)

14

Spherical lerp (slerp)

Usual textbook method Follows shortest path Constant velocity Multi-way-lerp is not obvious Moderate cost

15

Log-quaternion lerp (exp map)

Rather obscure method Does not follow shortest path Constant velocity Multi-way-lerp is easy to do Expensive

Which is the Best

No perfect solution! Each missing one of the features All look identical for small interpolations

This is the 99% case Blending very different animations looks

bad whichever method you use Multi-way lerping is important So use cheapest - nlerp

Multi-way Blending

Can use nested lerps lerp (lerp (A, B, i), C, j) But n-1 weights - counterintuitive Order-dependent

Weighted sum associates nicely (iA + jB + kC + …) / (i + j + k + … ) But no i value can result in 100% A

More complex methods Less predictable and intuitive Can be expensive

Bone Masks

Some animations only affect some bones Wave animation only affects arm Walk affects legs strongly, arms weakly

Arms swing unless waving or holding something Bone mask stores weight for each bone

Multiplied by animation’s overall weight Each bone has a different effective weight Each bone must be blended separately

Bone weights are usually static Overall weight changes as character changes

animations

The Masked Lerp

Two-way lerp using weights from a mask Each bone can be lerped differently

Mask value of 1 means bone is 100% A Mask value of 0 means bone is 100% B Solves weighted-sum problem

(no weight can give 100% A) No simple multi-way equivalent

Just a single bone mask, but two animations

Hierarchical Blending

Combines all styles of blending A tree or directed graph of nodes Each leaf is an animation Each node is a style of blend

Blends results of child nodes Construct programmatically at load time

Evaluate with identical code each frame Avoids object-specific blending code Nodes with weights of zero not evaluated

Triangles

Fundamental primitive of pipelines Everything else constructed from them (except lines and point sprites)

Three points define a plane Triangle plane is mapped with data

Textures Colors

“Rasterized” to find pixels to draw

Mesh

Vertices

A vertex is a point in space Plus other attribute data

Colors Surface normal Texture coordinates Whatever data shader programs need

Triangles use three vertices Vertices shared between adjacent triangles

Textures

Array of texels Same as pixel, but for a texture Nominally R,G,B,A but can mean anything

1D, 2D, 3D and “cube map” arrays 2D is by far the most common Basically just a 2D image bitmap Often square and power-of-2 in size

Cube map - six 2D arrays makes hollow cube Approximates a hollow sphere of texels For environmental

Cube Map

Texture Example

High-Level Organization

Gameplay and Rendering Render Objects Render Instances Meshes Skeletons Volume Partitioning

Gameplay and Rendering

Rendering speed varies according to scene Some scenes more complex than others Typically 15-60 frames per second

Gameplay is constant speed Camera view should not change game In multiplayer, each person has a different view,

but there is only one shared game 1 update per second (RTS) to thousands (FPS)

Keep the two as separate as possible!

Render Objects

Description of renderable object type Mesh data (triangles, vertices) Material data (shaders, textures, etc) Skeleton (+rig) for animation Shared by multiple instances

Render Instances

A single entity in a world References a render object

Decides what the object looks like Position and orientation Lighting state Animation state

Meshes

Triangles Vertices Single material “Atomic unit of rendering”

Not quite atomic, depending on hardware Single object may have multiple meshes

Each with different shaders, textures, etc Level-Of-Distance (LOD)

LOD

Objects have different mesh for different distance from the player

The mesh should be simpler if object is faraway

Many games have LOD, for example, Microsoft Train Simulator

Volume Partitioning

Cannot draw entire world every frame Lots of objects – far too slow

Need to decide quickly what is visible Partition world into areas Decide which areas are visible Draw things in each visible area Many ways of partitioning the world

Volume Partitioning - Portals

Nodes joined by portals Usually a polygon, but can be any shape

See if any portal of node is visible If so, draw geometry in node See if portals to other nodes are visible

Check only against visible portal shape Common to use screen bounding boxes

Recurse to other nodes

Volume Partitioning – Portals

Visible

Invisible

Not tested

Eye

Viewfrustum

Node

Portal

Test first two portals

? ?

Volume Partitioning – Portals

Visible

Invisible

Not tested

Eye

Node

Portal

Both visible

Volume Partitioning – Portals

Visible

Invisible

Not tested

Eye

Node

Portal

Mark node visible, test all portals going from node

??

Volume Partitioning – Portals

Visible

Invisible

Not tested

Eye

Node

Portal

One portal visible, one invisible

Volume Partitioning – Portals

Visible

Invisible

Not tested

Eye

Node

Portal

Mark node as visible, other node not visited at all.Check all portals in visible node

? ?

?

Volume Partitioning – Portals

Visible

Invisible

Not tested

Eye

Node

Portal

One visible, two invisible

Volume Partitioning – Portals

Visible

Invisible

Not tested

Eye

Node

Portal

Mark node as visible, check new node’s portals

?

Volume Partitioning – Portals

Visible

Invisible

Not tested

Eye

Node

Portal

One portal invisible.No more visible nodes or portals to check.Render scene.

Real Example

Volume Partitioning – Portals

Portals are simple and fast Low memory footprint Automatic generation is difficult, and

generally need to be placed by hand Hard to find which node a point is in, and

must constantly track movement of objects through portals

Best at indoor scenes, outside generates too many portals to be efficient

Volume Partitioning – BSP

Binary space partition tree Tree of nodes Each node has plane that splits it in

two child nodes, one on each side of plane

Some leaves marked as “solid” Others filled with renderable geometry

BSP

Volume Partitioning – BSP

Finding which node a point is in is fast Start at top node Test which side of the plane the point is on Move to that child node Stop when leaf node hit

Visibility determination is similar to portals Portals implied from BSP planes

Automated BSP generation is common Generates far more nodes than portals

Higher memory requirements

Volume Partitioning: Quadtree

Quadtree (2D) and octree (3D) Quadtrees described here Extension to 3D octree is obvious

Each node is square Usually power-of-two in size

Has four child nodes or leaves Each is a quarter of size of parent

Quadtree

Octree

Volume Partitioning: Quadtree

Fast to find which node a point is in Mostly used for simple frustum culling Not very good at indoor visibility

Quadtree edges usually not aligned with real geometry

Very low memory requirements Good at dynamic moving objects

Insertion and removal is very fast

Volume Partitioning - PVS

Potentially visible set Based on any existing node system For each node, stores list of which nodes

are potentially visible Use list for node that camera is currently in

Ignore any nodes not on that list – not visible Static lists

Precalculated at level authoring time Ignores current frustum Cannot deal with moving occluders

PVS

RoomA

RoomB

Room C

RoomD

RoomE

Viewpoint

PVS = B, A, D

Volume Partitioning - PVS

Very fast No recursion, no calculations

Still need frustum culling Difficult to calculate

Intersection of volumes and portals Lots of tests – very slow

Most useful when combined with other partitioning schemes

Volume Partitioning

Different methods for different things Quadtree/octree for outdoor views

Does frustum culling well Hard to cull much more for outdoor views

Portals or BSP for indoor scenes BSP or quadtree for collision detection

Portals not suitable

Rendering Primitives

Strips, Lists, Fans Indexed Primitives The Vertex Cache Quads and Point Sprites

Strips, Lists, Fans

1

2

3

4

5

6

7

89

1

2

3

4

5

6

7

8

1

23 4

5

6

1

2

3

45

6

1

2

3

4

5

6

Triangle list

Triangle fan

Triangle strip

Line list Line strip

Vertex Sharing

List has no sharing Vertex count = triangle count * 3

Strips and fans share adjacent vertices Vertex count = triangle count + 2 Lower memory Topology restrictions Have to break into multiple rendering

calls

Vertex Counts

Using lists duplicates vertices a lot! Total of 6x number of rendering vertices Most meshes: tri count = 2x vert count

Strips or fans still duplicate vertices Each strip/fan needs its own set of vertices More than doubles vertex count

Typically 2.5x with good strips

Hard to find optimal strips and fans Have to submit each as separate rendering call

Strips vs. Lists

32 triangles, 25 vertices 4 strips, 40 vertices

25 to 40 vertices is 60% extra data!

Indexed Primitives

Vertices stored in separate array No duplication of vertices Called a “vertex buffer” or “vertex array” 3 numbers (int/float/double) per vertex

Triangles hold indices, not vertices Index is just an integer

Typically 16 bits (65,536) Duplicating indices is cheap Indexes into vertex array

Vertex Index Array

The Vertex Cache

Vertices processed by vertex shader Results used by multiple triangles Avoid re-running shader for each triangle Storing results in video memory is slow So store results in small cache

Requires indexed primitives Cache typically 16-32 vertices in size, resulted in

around 95% efficiency

Cache Performance

Size and type of cache usually unknown LRU (least recently used) or FIFO (first in first

out) replacement policy Also odd variants of FIFO policy Variable cache size according to vertex type

Reorder triangles to be cache-friendly Not the same as finding optimal strips! Render nearby triangles together “Fairly good” is easy to achieve Ideal ordering still a subject for research