Animations in games

Game Dev 2017/2018 Univ Insubria

Animations in games

Marco Tarini

Types of animations in games

1. of rigid objects

 animate modelling transformations

(6 DoF per object)

Types of animations in games

1. of rigid objects

 or objects made of rigid sub-parts

Types of animations in games

2. Free-Form deformations

 generic transformations of the object

Types of animations in games

3. of articulated models

 internal skeleton

 most virtual characters!

 “skinning”

Types of animation and DoF

Rigid

Articulated

Free form

6 DoF per object

(or, e.g., 9, with anisotropic scaling)

~50-100 DoF per object

(e.g. 3 DoF per joint x 25 joints)

300-10.000 DoF per object

(e.g. 3 per-vertex)

DoF = Degrees of Freedom

Animations in games

 a

 a

 Assets!

 Control: easy.

full control by artists (e.g. for dramatic fx)

 Realism: hard

it’s up to the artist skill

 Flexibility:little

Doesn’t adapt to env.

 (consumesRAM)

 a

 a

 Physic engine

 Control: hard

 Realism: easy built-in physical laws

 Flexibility: great

Adapts to env / contexts

 (consumesGPU)

Procedural Non procedural

Animations in games



Or… a mix

 ex1: primary animations: non procedural (assets) secondary animations: procedural (physics)

 ex2: alive characters: non procedural (assets) dead characters: computed (physics: ragdolls)

 and more



a frontier in CG and Interactive techniques!

A digression on terminology



The opposite of “procedural”,

depending on the context, can be…

 baked : ‘pre-cooked’, ‘frozen’ into an asset, (when it was produced procedurally)

 asset: stored as an asset (irrespective of origin), that is, read from the disk (or streamed from web)

 scripted: stored as a (simple!) script

(but, the procedure to create something can well be a script!

e.g. a script can procedurally generate a level)

 (manually) designed / edited : made by an artist (as opposed to: by a program)

 (fully) simulated : the output of a (complex!) simulation

Animations in games

(of 3D SolidObjects)

Procedural Non Procedural

Rigid

Articulated

Free form

Skeletal Animations

Blend-Shapes

Rigid body dynamics Kinematic

animations

(ASSETS) (PHYSIC ENGINE / ETC)

Ragdolling Inverse kinematics

(generic) deformable object

simulation usually too expensive

Cloth/

garments

Ropes

(ASSETS) (PHYSIC ENGINE / ETC)

Animations in games

(of 3D SolidObjects)

Procedural Non Procedural

Rigid

Articulated

Free form

Skeletal Animations

Blend-Shapes

Rigid body dynamics

Ragdolling Inverse kinematics

(generic) deformable object

simulation usually too expensive

Cloth/

garments

Ropes

Kinematic animations

Scene graph

TR0

TR1 TR2

TR3 TR⁴ TR5 TR⁶

positioning of the car (in relation to the world) positioning

of the wheel (in relation to the car)

Animated Scene graph…

(“kinematic” animations)

TR0

TR1

TR³ TR4 TR5 TR6 positioning

of the car (in relation to the world) positioning

of the wheel (in relation to the car)

Time: t0 t1 t2 t3 t4

Trasform: ^{TR0 TR1 TR2 TR3 TR4}

Kinematic animations:

how?



way 1:

 just scripting



way 2:

 editing in a animation software

 cinema 4D, blender, 3D max, …

 (including use of I.K. as part of the interface)

 export animation

 as a sequence of keyframes

 File formats: collada, fbx, …

asset:

the script

asset:

the animation

Time: t0 t1 t2 t3 t4

A==>B: TR0 TR1 TR2 TR3 TR4

B==>C: TR0 TR1 TR2 TR3 TR4

DEMO

!

Interpolating keyframes

(applies to all kinds of animations)



Keyframes +

interpolation

keyframe A keyframe B

0.5 ∙ keyframe A + 0.5 ∙ keyframe B

Interpolating keyframes

(applies to all kinds of animations)

 The animator authors:

 a set of keyframes

 each with an associated time

 Status of the ani at any other frame:

interpolation between keyframes

 saves artist work

 saves storage

 note: keyframes distribution can be adaptive

 concentrate keyframes where needed / not linear

“timeline”

key-frames

Historical Note



Blend shapes, all make use Skeletal animations,  of keyframes

Kinematic animations and interpolations

 Artists just need to author key-frames

 Rendering Engine will interpolate



In traditional animation (2D, hand-drawn)

 senior artists draw keyframes

 junior artists (“in-bewteeners”) do interpolations

 using this terminology:

today, “in-betweening” is fully automatic, and is performed in realtime

Keyframe interpolation

(for kinematic animations)

time A = 100

time B = 200 time curr. = 150

?

keyframe A

keyframe B

T

T

T

= ?

interpolated

*T_i= mix( T_A, T_B, 0.5)

*

Kinematic Animations in Unity (notes)

 Just manipulate the object transform in scripts

 see our first project

 Easy to switch from physics  kinematics:

 RigidBody has the boolean field «isKinematic»

 set it off:

 physics takes care of animating the object (as a rigid object)

 object can be manipualted by means of:

forces / impulses / torques, etc

 set it on:

 physics is off: no dynamics, no collision responses

 manipulate object by transforms

 note: collision detection still happens.

and so do collision response of other colliding objects

 E.g.: spaceship is alive  isKinematic = true spaceship is dead  isKinematic = false

Animations in games

(of 3D Solid Objects)

Procedural Non-Procedural

Rigid

Articulated

Free form

Skeletal Animations

Blend-Shapes

Rigid body dynamics Kinematic

animation

Ragdolling Inverse kinematics

(generic) deformable object

simulation usually too expensive

Cloth/

garments

Ropes

(ASSETS) (PHYSIC ENGINE / ETC)

Animation deformable objects:

Blend shapes



A.K.A:

 Blend shapes

 Per-vertex animations

 Vertex animations

 Face morphs

 Shape keys

 Morph targets

 …

BARRY BLITT (THE NEW YORKER)

Blend shapes: concept



Animation in 2D (old school):

a sequence of sprites



Animation in 3D:

a sequence of meshes?

Walk cycle (Monkey Island

LucasArt 1991)

Reminder:

representation of a mesh

 Indexed mode :

 Geometry: array of vertices position

 Attributes:

 stored at vertices

 Connectivity:

 Array of triangles (or polygons)

 Each triangle:

 a triplet of indexesto vertices

Blend shapes

(as a data structures)

connectivity (indexed)

Tri:

Wedge 1:

Wedge 2:

Wedge 3:

T1 V4 V1 V2

T2 V4 V2 V5

T3 V5 V2 V3

Vert: Pos

V1 ^(x,y,z) V2 ^(x,y,z) V3 ^(x,y,z) V4 ^(x,y,z) V5 ^(x,y,z) geometry:

UV Col

(u,v) (r,g,b) (u,v) (r,g,b) (u,v) (r,g,b) (u,v) (r,g,b) (u,v) (r,g,b)

attributes:

V2

V3

V5 V4

V1

T1 T2

T3

Blend shapes

(as a data structures)

connectivity (indexed)

Tri:

Wedge 1:

Wedge 2:

Wedge 3:

T1 V4 V1 V2

T2 V4 V2 V5

T3 V5 V2 V3

Vert:

Base Shape

Shape 1

Shape

2 …

V1 ^{(x,y,z) (x,y,z) (x,y,z) …}

V2 ^{(x,y,z) (x,y,z) (x,y,z) …}

V3 ^{(x,y,z) (x,y,z) (x,y,z) …}

V4 ^{(x,y,z) (x,y,z) (x,y,z) …}

V5 ^{(x,y,z) (x,y,z) (x,y,z) …}

geometries:

UV Col

(u,v) (r,g,b) (u,v) (r,g,b) (u,v) (r,g,b) (u,v) (r,g,b) (u,v) (r,g,b)

attributes:

V2

V3

V5 V4

V1

T1 T2

T3

V2

V3 V5

V4 V1

T1

T2 T3

V2 V3

V5 V4

V1

T1 T2

T3

Blend shapes

 A mesh with several associated geometries

 I.e. a sequence of meshes (‘shapes’) with

 shared connectivity

 shared attributies

 (except maybe normals / tangents)

 shared textures

 different geometries

 Variants (they are equivalent):

 Absolute mode:

 each shape stored explicitly

 Relativemode:

 base shape: explicitly stored

 any other shape: as a (dx,dy,dz) difference with base shape

 small advantage: smaller coords to store (better precision)

 small advantage: more intuitive to set weights (see later)

or‘morph’

or (key)-‘frame’

or‘shape-key’

Blend shapes

(as a data structure, e.g. C++)

 Indexed mesh :

class Vertex { vec3 pos;

rgb color;

vec3 normal;

};

class Face{

int vertexIndex[3];

};

class Mesh{

vector<Vertex> vert; /* geom + attr */

vector<Face> tris; /* connectivity */

};

Blend shapes

(as a data structure, e.g. C++)

 Indexed mesh :

class Vertex {

vec3 pos [ N_SHAPES ] ; rgb color;

vec3 normal [ N_SHAPES ] ; };

class Face{

int vertexIndex[3];

};

class Mesh{

vector<Vertex> vert; /* geom + attr */

vector<Face> tris; /* connectivity */

};

Blend-shapes:

most common file formats



Simple:

 .MD5(“quake”, valve)

 or, just a use a sequence of meshes (es .OBJ)

 making sure connectivity is coherent!

(vertex ordering = the same)



Complex:

 .DAE (Collada)

 .FBX (Autodesk)

Interpolation between shapes



Just interpolating the geometry:

 with absolute BlendShapes : shape_A w_A+ shape_B w_B

 with relative BlendShapes:

shape_base+ delta_shape_A w_A+ delta_shape_B w_B with: w_A+ w_B= 1

0 ≤ w_A≤ 1 0 ≤ w_B≤ 1

Uses of Blend-Shapes

shape A shape B

(shapes = facial expressions)

Uses of Blend-Shapes



Temporal sequences

 shapes = keyframes

Uses of Blend-Shapes



Temporal sequences

 shapes = keyframes

Use of Blend shapes as temporal sequences



Shapes == keyframes of the animation



shape

with time t



shape

with time t



shape

with time t



shape

with time t



current time: t with t

< t < t



interpolate betw. shapes: …



weights : …

shape_B

,

=

= 1 −

=

Use of Blend shapes as temporal sequences



Shapes == keyframes of the animation



shape

with time t



shape

with time t



shape

with time t



shape

with time t



current time: t with t

< t < t



interpolate betw. shapes: …



weights : …

shape_B

,

= 𝑓

= 𝑓

transition function

Transition functions



Not necessarily the Linear one

1 1

𝑥 𝑓(𝑥)

linear

𝑓 𝑥 = 𝑥

(general concept,

applies to all animation types)

Transition functions

NB:  extrapolation ! (  exaggeration )

(general concept,

applies to all animation types)



Not necessarily the Linear one

1 1

𝑥 𝑓(𝑥)

linear

𝑓 𝑥 = 𝑥

Interpolation between more than two shapes



Blending the shapes:

 Absolute:

shape_A w_A+ shape_B w_B+ shape_C w_C + … with:

0 ≤ w_{A,B,C, …}≤ 1

w_A+ w_B+ w_C+ … = 1

 Relative:

shape_base+ shape_A w_A+ shape_B w_B + shape_C w_C + …

or maybe not (extrapolation).

Useful for…

Interpolation between shapes:

notes

 The advantage of sharing the connectivity

is exactly that shape interpolation becomes possible

 (hence the name: blend-shapes)

 The two modes to represent blend-shapes

(relative, absolute) are mathematically equivalent

 any result which can be obtained with one, can also be obtained with the other, using some appropriate weights

 exercise (easy): given the weight with one mode,

how to compute the equivalent weights for the other mode?

 observe: weights for Absolute mode come up being always an interpolation or extrapolation (∑ weights = 1)

 observe: if Relative mode has ∑ weights > 1, it is actually an extrapolation of absolute shapes

Interpolation between shapes:

strengths and limitations

 All advantages of key-frames in general

 strong reduction of asset RAM size (w.r.t. store each frame)

 continuous animations

(e.g. nicely smooth, even at extreme slowdown)

 adaptive temporal resolution

(fewer key-frames where motion less important / more linear)

 But, blend-shape interpolation is not all-powerful!

 good if: interpolated key-frames are similar enough (small motions)

 potentially bad if: key-frames are too far apart (can only recreate linear motions)

 potentially bad if: extrapolation is attempted

(with interpolation, we are just blending together shapes that the artist liked -- safe)

 note: in relative mode, ∑ weights > 1 is still an extrapolation

Uses of Blend shapes



Facial animations

 (one of the commonest uses)

Here toghter with skeletal animations (see later) (mandible, neck, eyeballs)

Using facial animations as Blend shapes: pipeline



The 3D Modeller will author:

the set of blend-shapes



Animator (of expressions) will pick:

weights

 eg.: with sliders

 assisted / substituted by automation

 lip sync

 dynamically determined expressions



Shape Blending: by rendering engine

[VIDEO]

Uses of Blend shapes



Facial animations

 (one of the commonest uses)

Here, together with skeletal animations (see later) (mandible, neck, eyeballs)

Toy Example

 Modeller produces a blend-shape:

 shape[0] = basis (rest-shape, no expression)

 shape[1] = L Eye Closed

 shape[2] = R Eye Closed

 shape[3] = Smile

 Note: in relative mode, all the unaffected areas

(e.g. eyes in shape[3], mount in shapes[1],[2] ) are zero vectors.

 The Animator wants:

 A blink: full smile, plus R eye completely closed

 Q1: weights, in relative mode?

 easy and intuitive

 Q2: weights, in absolute mode?

 hint: it is not just w1 = 1.0, w3 = 1.0 that’s not an interpolation!

 hint: it is not w1 = 0.5, w3 = 0.5 either  half closed eye, half smile!

 compute from relative mode weights…

One non-toy example

Uses of Blend-Shapes



Set of useful/typical physical configurations



Baked poses

Uses of Blend-Shapes



Variants of one given object. E.g. outfits

 (mixable!)

masculine outfit feminine outfit

Uses of Blend-Shapes



Variants of one given object. E.g. outfits

 (mixable!)

human orc goblin dwarf

Uses of Blend-Shapes



Defines shapes of a class of objects

 get a shape in the class = just choose the weights

 3D modelling at an high-level of abstraction

 the weights “span” one shape space

 one given shape = one point in the space

 weights = coords

 the space is the more useful the more:

 all and only the reasonable shapes are represented in the space



Typical Example: face morphologies

 “face-space”

 note: face morphology ≠ facial expression

 Same data structure, different objectives

Usi delle Blend shapes

 Una blend shape per un face space (“face-morphs”)

[DEMO]

What a blend shape cannot do



Change connectivity

 eg. change res, remeshing



Change topology

 breaking apart, fusing parts



Change attributes

 (eg color…)



Change textures

 Use a texture animation instead, maybe?

Blend shapes:

authoring

Manual authoring:

1. Editing base shape

 including:

uv-mapping, texturing, etc.

2. Re-edit it

for each shape-key!

…while preserving:

connectivity, textures, etc

 low poly editing

 or with subdivision surfaces…

 or with parametric surfaces…

 or with scupting.

Blend shapes:

authoring



Handbook for

blend-shape based face animation:

 “Stop Staring”

(3d edition) Jason Osipa

 Covers: style, expression…

 Non technical (high level)

 Not about specific tools e.g. Blender, Maya

Blend shapes:

hot to obtain them



Capture:

 3D acquisition of base shape B0

 (including: simplification, remeshing, uv-mapping, etc)

 capture subsequent shapes B1, B2…

 e.g. real-time (kinect), o 3D scanning for each shape

 compute a morph B0 => B1

 “non rigid mesh alignment”

[VIDEO]

Blend shapes:

strengths / limitations recap



 Flexible, expressive, huge number of DOF…

even too many?

 RAM cost

 Work intensive to construct



 Shape interpolability:

 so good to have it!

 but, has some limits



 Easy to use / efficient, once they are built

 just define global weights

(but, not as bad as old sprites,

because (1) sharing of connectivity, textures, attributes (2) keyframes / interpolation!

Blend shapes:

open challenges



Capturing

 construction from a stream of captured meshes



Compression

 eg: prediction + store corrections + Huffman



Streaming



LOD-ding

Animations in games

(of 3D Solid Objects)

Procedural Designed / scripted

Rigid

Articulated

Free form

Skeletal Animations

Blend-Shapes

Rigid body dynamics Kinematic

animation

Ragdolling Inverse kinematics

(general) deformable object

simulation usually too expensive

Cloth/

garments

Ropes

(ASSETS) (PHYSIC ENGINE / ETC)

Step by step…

Kinematic animations

(global) world space wheel _1 objects space car1

object space wheel_2

object space

car2object space

t ⁰

t 1

Step by Step…

Kinematic animatios

T0

T1

T^1,1 T1,2 T1,3 T^1,4

positioning of car 1 (w.r.t. the world)

positioning.

of wheel 1.1 (w.r.t. car1)

world space

car1 objectspace

wheel1.1 objectspace time

t0 T1 T1,1 T1,2 T1,3 T1,4 … t1 T1 T1,1 T1,2 T1,3 T1,4 … t2 T1 T1,1 T1,2 T1,3 T1,4 …

trasformation

Animation:

An animated

robot…

T⁰

T1 T2

T4 T⁶

Robot (pelvis) world space

spine1

left thigh

right thigh

right shoulder

shoulderleft

right calf spine2

T3

T7

right foot T8

T⁵ neck

bones

“root” bone

Local tranformf (“from foot to calf”)

Gobal transform (“from foot to robot”) is:

T2xT7xT8

Step by step…

From a bunch of pieces…



So far: one mesh in each “bone”

 (e.g., car-cockpit, car-wheel)



That’s ok, for a simple structure

 (like a car, a windmill…)



What about a humanoid “robot” with 50 “bones”?

 Individual meshes for arms, forearms, legs…

three meshes for each finger?

 Possible, but…

 inefficient to render (many “draw calls”)

 uneasy to manage (lots of separated assets?)

 a nightmare to design / author (“sculpt me a nice looking calf”)

 and… looks right only for robots (each object is rigid!)

… to articulated models…



Idea:

use 1 unified mesh for the entire character

 but, add a new attribute per vertex: index of bone

 the mesh now models an articulated object, which can be animated!



at rendering time, transform each vertex

according to the transformation of its linked bone



a mesh of this kind is called a skin

 same biological metaphor:

“bones” = what triggers the movement inside.

“skin” = what follows it outside.

 the set of index-of-bone attributes = the skinningof the mesh (for now)

 assigning this attribute = to be skinningthe mesh

… to articultated deformable models.



Further idea: link each vertex to >1 bones



At rendering time, transform each vertex with:

 aninterpolationof the trasformations associtated to the linked bones

 weightsof the interpolation: defined per-verex



Better deformations!

 e.g.: a vertex on the shoulder follows

partly the shoulder bone, partly the upper-arm bone:

the shoulder deforms nicely



Data structures: per-vertex attributes

 [ bone index , weight ] x Nmax

 (typically, Nmax= 4 or 2, see later)

“Skinning” the of the mesh

ver 2.0 (the real one)

(this story actually happened)

230 △ (1996)

300 △ (1998)

30.000 △ (2008)

48.000 △ (2012) 4.000 △

(2002)

(this story actually happened)

Tekken - 1994 Tekken 2 - 1995 Tekken 3 - 1997 Tekken 5 - 2004 Tekken 6 - 2007 Tekken 4 - 2001

(this story actually happened)

Tekken - 1994 Tekken 2 - 1995 Tekken 3 - 1997 Tekken 5 - 2004 Tekken 6 - 2007 Tekken 4 - 2001

(and we are still at that point!)

Tekken 7 - 2015

(researcher perspective: time for an advancement, maybe?) (see current challenges, later)

Rig (or skeleton):

data structure 1/2



A tree of bones

 bone:

 A frame used to express parts of the articulated model

 eg, for a humanoid: forearm, calf, pelvis, …

 (rigging bone != biological bones)



Space of the root bone =(def)= object space (of the character)



Skeleton of a humanoid:

at least 20-24 bones reasonable: ~40 bones.

max: 100s

Pose:

data structure

One trasformation for each bone i



Local transform:

 from: space of bone i

 to:space of its parent bone

often, only the rotation component (“fixed length bones”:

translations defined once and for all by the skeleton)

Rig (or skeleton):

data structure 2/2

1.

Hierarchy (tree) of bones

 a root bone on top

2.

An arbitrary chosen pose : the «rest pose»

 3D models are to be modelled in this pose

 also: «T-pose», «T-stance»

 same reason why T-shirts are called T-shirts ;-)

Content creation Tasks:

Rigging & Skinning

Rigging – authoring of a rig defining the skeleton

(hierarchy of bones, plus rest pose)

Skinning – authoring of the skinning defining the bone-weights / -indices of vertices

From Rest Pose to a given pose

pelvis (root)

spine 1

shoulderleft

right shoulder

R2

R4 R⁶

right left leg

leg

right spine 2 calf

R3 R7

right neck foot

R5 R8

R3

R1

pelvis (root)

spine 1

shoulderleft

right shoulder

P²

P⁴ P6

right left leg

leg

right spine 2 calf

P³ P7

right neck foot

P5 P8

P3

P¹

pose X rest pose

From Rest Pose to a given pose

pelvis (root)

spine 1

shoulderleft

right shoulder

R2

R4 R6

right left leg

leg

right spine 2 calf

R3 R⁷

right neck foot

R5 R8

R3

R¹

pelvis (root)

spine 1

shoulderleft

right shoulder

P2

P⁴ P6

right left leg

leg

right spine 2 calf

P³ P7

right neck foot

P⁵ P⁸

P³ P1

final trans for foot, from rest pose to pose X = P2P7 P8 (R2 R7R8)^-1= P2P7P8(R8)^-1(R7)^-1(R2)^-1 pose X

rest pose

same as same as same as

Per-bone transformations.

E.g. for the «right-foot» bone:

 Local Transform:

P

 from «right foot» to «right lower leg»

 Global Transform:

P

P

P

 from «right foot» to «character»

 uses the Hierarchyof the Skeleton

 once it’s computed, Hierarchyno longer needed

 Final Transform:

P

P

P

R

R

R

 from «character» in rest pose to «character»in dest. pose

 uses the Rest Pose of the Skeleton(R¹ …R^N)

 once its computed, Rest Pose no longer needed either!

the object frame of the character, i.e. the frame of the root bone

the space wheremesh vertices are defined!

Pose

:

data structure in RAM / disk

 pose= array of (local) transforms

 it’s defined for one given rig

 RAM cost: n_bonesx bytes_for_a_tranform

Osso i Trasform[ i ]

#0 (pelvis) [root] L[0]

#1 (spine) L[1]

#2 (chest) L[2]

#3 (shoulder sx) L[3]

… …

#10 (calf) L[10]

… …

Local Transform

It includes:

• a Rotation: always!

• a Translation: maybe If not, use the one defined in the rest poseof the rig.

==> a pose cannot redefine bone lengths.

• a Scaling: maybe If not ==> a pose cannot redef the size of the body part.

FinalTransform

It includes:

• a Rotation: always!

• a Translation: always!

• maybe a scaling

Ready to be used!

Pose

:

data structure in GPU RAM

 pose= array of final transforms

 it’s defined for one given rig

 RAM cost: n_bonesx bytes_for_a_tranform

Osso i Trasform[ i ]

#0 (pelvis) [root] F[0]

#1 (spine) F[1]

#2 (chest) F[2]

#3 (shoulder sx) F[3]

… …

#10 (calf) F[10]

… …

Skeletal Animation :

data structure (CPU or GPU)



Array of poses

 RAM cost:

(num keyframes) x (num bones) x (transform size)

 Each pose assigned to time dt

 delta from start of animation t₀

 Sometime, looped

 interpolation 1st keyframe with last

Skinned Mesh:

data structure



A Mesh with a skinning

 A per vertex attribute

 Stored per vertex:

 [ bone indexd , weight ] x Nmax times

 example:

Bone Index Weight

9 (Spine B) 0.4

13 (Chest) 0.1

15 (Shoulder Right) 0.4

16 (Forearm Right) 0.1

Vertex 120

N_max = How many bone links for each vertex



It’s a call of the Game engine / the dev



typical values:

 1 (rigid pieces) (bonus: no need to store weights)

 2 (cheap, e.g. for mobile games)

 4 (top quality – standard)

 more: not in games (currently)



Lowering N

in one existing asset?

 possible preprocessing task (e.g. by a game tool)

 e.g unity offers this functionality as part of skinned mesh import

(why a hard bound

on # of per-vertex bone-links?)



In a mesh, some vertex needs

more bone-links (deformable parts), some fewer (rigid parts)



But: GPU = no good at control:

 basically, fixed-length arrays only

 if a vertex needs fewer bones:

 still store all N_maxbone-links

 (unused bones: weight = 0)

 still interpolate N_maxtransforms at rendering time



So, adding a 5th bone-link to one vertex = adding it to all

Bone Index Weight

9 (Head) 1.0

0 0.0

0 0.0

0 0.0

e.g., a vertex on top of skull in a 4-bone skinning needs:

Skinning - how it works (in GPU)

86

model in rest pose

a vertex (in rest pose)

𝑤𝑖 = 1

Transform:

T2

T5

T7

T₁ Bone: Weight:

bone 2 0.3

bone 5 0.2

bone 7 0.4

bone 1 0.1

dest.

pose

x vertex skinning

blend

Skinning - how it works (in GPU)

deformed model

vertex (in dest pose) model

in rest pose

dest.

pose

a vertex (in rest pose)

GPU Skinning – so convenient!

 In GPU memory, we just keep this…

 the (skinned) mesh, in rest pose

 can be fairly hi-res

 the same, for any frame!

 static: needs not be updated per frame

 …and this

 the target pose

 an array of per-bone (final) transformations

 compact!

 we can keep several ready

 On screen, we see this

 a geometry that wasn’t ever stored