1. CSCE 552 Spring 2010
Animation
By Jijun Tang

2. Announcements Homework #3 due Mar 19th Second demo Group based
A model to be used in your own game
Second demo
Very Early April
A demo is needed

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

4. 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

5. Example

6. 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

7. 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

8. Linear Interpolation

9. The Bézier Curve (1-t)3F1+3t(1-t)2T1+3t2(1-t)T2+t3F2 T2 t=1.0 T1 F2

10. 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

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

12. 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.

13. Quaternion Blending Normalizing lerp (nlerp) Many others:
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

16. 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

17. Multi-way Blending Can use nested lerps Weighted sum associates nicely
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

18. 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

19. 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

20. 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

21. 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

22. Mesh

23. 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

24. Textures Array of texels 1D, 2D, 3D and “cube map” arrays
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

25. Cube Map

26. Texture Example

27. High-Level Organization
Gameplay and Rendering
Render Objects
Render Instances
Meshes
Skeletons
Volume Partitioning

28. Gameplay and Rendering
Rendering speed varies according to scene
Some scenes more complex than others
Typically 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!

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

30. 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

31. 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)

32. 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

33. 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

34. 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

35. Volume Partitioning – Portals
Node
View
frustum
Portal
Visible
Test first two portals
Invisible
Not tested ? ?
Eye

36. Volume Partitioning – Portals
Node
Portal
Visible
Both visible
Invisible
Not tested
Eye

37. Volume Partitioning – Portals
Node
Portal
Visible
Mark node visible, test all portals going from node
Invisible
Not tested ? ?
Eye

38. Volume Partitioning – Portals
Node
Portal
Visible
One portal visible, one invisible
Invisible
Not tested
Eye

39. Volume Partitioning – Portals
Node
Portal ?
Visible
Mark node as visible, other node not visited at all.
Check all portals in visible node
Invisible ? ?
Not tested
Eye

40. Volume Partitioning – Portals
Node
Portal
Visible
One visible, two invisible
Invisible
Not tested
Eye

41. Volume Partitioning – Portals
Node
Portal ?
Visible
Mark node as visible, check new node’s portals
Invisible
Not tested
Eye

42. Volume Partitioning – Portals
Node
Portal
Visible
One portal invisible.
No more visible nodes or portals to check.
Render scene.
Invisible
Not tested
Eye

43. Real Example

44. 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

45. 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

46. BSP

47. 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

48. 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

49. Quadtree

50. Octree

51. 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

52. 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

53. PVS
Room A
Room C
PVS = B, A, D
Room D
Room B
Viewpoint
Room E

54. 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

55. 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

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

57. Strips, Lists, Fans Triangle strip 2 4 4 2 1 5 6 8 2 1 2 3 6 7 1 5 3 39 8 4 3
Triangle list 1 3 5 4 2 7 4 5 5 6 6
Line list 1
Line strip 6
Triangle fan

58. 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

59. 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

60. Strips vs. Lists 32 triangles, 25 vertices 4 strips, 40 vertices
25 to 40 vertices is 60% extra data!

61. 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

62. Vertex Index Array

63. 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 vertices in size, resulted in around 95% efficiency

64. 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