Computer Graphics Matrix Hierarchies / Animation CO2409 Computer Graphics Week 21.

Click here to load reader

  • date post

  • Category


  • view

  • download


Embed Size (px)

Transcript of Computer Graphics Matrix Hierarchies / Animation CO2409 Computer Graphics Week 21.

  • Computer GraphicsMatrix Hierarchies / AnimationCO2409 Computer GraphicsWeek 21

  • Lecture ContentsModel AnimationModel/Matrix HierarchiesLimitations of HierarchiesRendering a Model HierarchyMatrix StacksProcess

  • Model AnimationSo far we have looked at individual models:Each a fixed piece of geometryNo moving parts

    We have animated these models in a way:By moving and rotating them each frame

    However, now we will focus on manipulating (animating) geometry that is:Made of several rigid parts (this lecture)Flexible with an underlying skeleton (next lecture)

  • Rigid Body AnimationWe start with models made up of several rigid parts that can move with respect to each otherMainly mechanical models, such as vehicles, doors, guns, robots

    A common assumption for such models is that the parts form a hierarchyA tree structure defining how the parts are connected

  • Limitations of HierarchiesMost multi-part objects fit naturally into a hierarchical formIn particular its usually easy to determine a root for the objectBut consider a bicycle chain which link is the root?

    A hierarchical form also assumes that each part has only one parent that directly controls its movementNot true when multiple forces involvedTrain carriage with two enginesTwo people carrying a stretcher

    Need more complex solution for these casesUse a solver part of a physics engine

  • Matrix HierarchiesIn such a hierarchy:Each part has a parent, or is the root of the treeA part can have any number of children (including 0)Each part in the hierarchy has a world matrixDefining its position and orientation - just like a modelHowever, the world matrix for each part is stored relative to its parentSo each part is defined in the local space of its parentRoot is stored in absolute world space

    Implies that child parts inherit their parents movement

  • Matrix Hierarchy: DiagramSuch hierarchies are sometimes called Matrix Hierarchies or Transform Hierarchies

  • Building HierarchiesThe position of a childs origin determines where it will pivot relative to its parentThe orientation of its axes will determines how it will rotate (in X, Y and Z)So the parts matrix defines the joint with its parentMust ensure that we build the hierarchies and position matrices correctlyTo allow required animationActually this is an issue for the 3D artist to resolve

  • Rendering HierarchiesWe want to render a hierarchy of model partsWe need absolute world matrices for each part rather that the parent-relative world matrix that is stored

    Can simply make the existing rendering code recursive the code for each part is:Get absolute world matrix by combining this parts relative matrix with the parents absolute world matrixRender part with absolute matrixRepeat process for each child part

    This process dictates a depth-first traversal of the hierarchy tree structureTo pass matrices from parent to child easily (see lab)

  • Rendering Hierarchies: Matrix StackRecursion may be inefficient for a real-world app that has many 100s or 1000s of models with many partsA human model may have 50 or 60 parts

    We can convert this recursive process to an iterative one

    To help us we use a Matrix StackTo store the matrices for ancestors of the current partDirectX provides such a featureNot difficult to write our own if necessaryThis is an efficient LIFO structure for pushing and popping matrices

  • Rendering Hierarchies EfficientlyPut parts into a list in depth-first orderDone in advance

    Also store depth in the hierarchy of each part

    Each part has its parent-relative matrixCall it the local matrixIn the example will use M0, M1 etc.

  • Rendering Hierarchies EfficientlyIterating through the list is now the same as traversing the tree depth-first

    At each step, will keep track of:Absolute world matrix call it WCurrent depth in hierarchy call it CurrentDepth

    Initialise the process:Set W = the identity / unit matrixSet CurrentDepth = 0Start with empty matrix stack

  • Rendering Hierarchies contFor each part x in the hierarchy list:

    Get depth of part x, call it NewDepthIf NewDepth > CurrentDepth, push W onto stackIf NewDepth = CurrentDepth, do nothing to stackIf NewDepth < CurrentDepth, pop matrices from stackPop (CurrentDepth NewDepth) timesE.g. CurrentDepth = 3, NewDepth = 1, pop stack twiceSet W = Matrix at top of stack * MxRender part x using absolute world matrix WCurrentDepth = NewDepth

  • Rendering Hierarchies Example

    Starting with W = identity(I) & CurrentDepth = 00. NewDepth = 1 > CurrentDepth: push W (Stack:I) W = Stack Top * M0 = M0: render base with world matrix M01. NewDepth = 2 > current: push W (Stack: I, M0) W = Stack Top * M1 = M0.M1: render arm with matrix M0.M12. NewDepth = 3 > current: push W (Stack: I, M0, M0.M1) W = Stack Top * M2 = M0.M1.M2: render grip1 w. matrix M0.M1.M23. NewDepth = 3 = current: no change (Stack :I, M0, M0.M1) W = Stack Top * M3 = M0.M1.M3: render grip2 w. matrix M0.M1.M34. NewDepth = 2 < current: pop stack 1 time (Stack: I, M0) W = Stack Top * M4 = M0.M4: render switch with matrix M0.M4

  • Rendering Hierarchies ExampleLooking just at the render steps:Render base with world matrix M0Render arm with matrix M0.M1Render grip1 with matrix M0.M1.M2Render grip2 with matrix M0.M1.M3Render switch with matrix M0.M4

    These are the correct combined matrices

    The process described is fairly simple to implementMore efficient than recursive version