Computer Graphics Matrix Hierarchies Animation CO 2409 Computer

  • Slides: 13
Download presentation
Computer Graphics Matrix Hierarchies / Animation CO 2409 Computer Graphics Week 21

Computer Graphics Matrix Hierarchies / Animation CO 2409 Computer Graphics Week 21

Lecture Contents 1. 2. 3. 4. Model Animation Model/Matrix Hierarchies Limitations of Hierarchies Rendering

Lecture Contents 1. 2. 3. 4. Model Animation Model/Matrix Hierarchies Limitations of Hierarchies Rendering a Model Hierarchy 1. Matrix Stacks 2. Process

Model Animation • So far we have looked at individual models: – Each a

Model Animation • So far we have looked at individual models: – Each a fixed piece of geometry – No 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)

Bad Drawings

Bad Drawings

Rigid Body Animation • We start with models made up of several rigid parts

Rigid Body Animation • We start with models made up of several rigid parts that can move with respect to each other – Mainly mechanical models, such as vehicles, doors, guns, robots… • A common assumption for such models is that the parts form a hierarchy – A tree structure defining how the parts are connected – We will call each part in a tree, a node

Limitations of Hierarchies • Most multi-part objects fit naturally into a hierarchical form –

Limitations of Hierarchies • Most multi-part objects fit naturally into a hierarchical form – In particular it’s usually easy to determine a root node for the object – But consider a bicycle chain – which link is the root? • A hierarchical form also assumes that each node has only one parent that directly controls its movement – Not true when multiple forces involved – Train carriage with two engines – Two people carrying a stretcher • Need more complex solution for these cases – Use a “solver” – part of a physics engine

Matrix Hierarchies • In such a hierarchy: – Each node has a parent, or

Matrix Hierarchies • In such a hierarchy: – Each node has a parent, or is the root of the tree – A node can have any number of children (including 0) • Each node in the hierarchy has a world matrix – Defining its position and orientation - just like a model • However, the world matrix for each node is stored relative to its parent – So each node is defined in the local space of its parent – Root is stored in absolute world space • Implies that child nodes inherit their parent’s movement

Matrix Hierarchy: Diagram • Such hierarchies are sometimes called Matrix Hierarchies or Transform Hierarchies

Matrix Hierarchy: Diagram • Such hierarchies are sometimes called Matrix Hierarchies or Transform Hierarchies

Building Hierarchies • The position of a child’s origin determines where it will pivot

Building Hierarchies • The position of a child’s origin determines where it will pivot relative to its parent • The orientation of its axes will determines how it will rotate (in X, Y and Z) • So the node’s matrix defines the joint with its parent • Must ensure that we build the hierarchies and position matrices correctly – To allow required animation – Actually this is an issue for the 3 D artist to resolve

Rendering Hierarchies • We want to render a hierarchy of model nodes – We

Rendering Hierarchies • We want to render a hierarchy of model nodes – We need absolute world matrices for each node rather that the parent-relative world matrix that is stored • Can simply make the existing rendering code recursive – the code for each node is: 1. Get this node’s absolute world matrix by combining its relative matrix with the parent’s absolute world matrix 2. Render node with its absolute matrix 3. Repeat process for each child part • This process dictates a depth-first traversal of the hierarchy tree structure – To pass matrices from parent to child easily (see lab)

Rendering Hierarchies: Matrix Stack • Recursion may be inefficient for a real-world app that

Rendering Hierarchies: Matrix Stack • Recursion may be inefficient for a real-world app that has many 100 s or 1000 s of models with many parts – A human model may have 50 or 60 parts – Each function call adds additional code to transfer control to the new function and return back again. – Not usually an issue, but games often need optimisation. • We can convert this recursive process to an iterative one – Instead of using recursion, we use a single loop • The key is to realise that the recursion here is only used to pass the parent’s matrix down to the children. – Instead, just have the nodes point to their parents.

Rendering Hierarchies Efficiently • Put nodes into a list (actually a vector or array)

Rendering Hierarchies Efficiently • Put nodes into a list (actually a vector or array) • Use depth-first order – Done in advance • Each part has its parentrelative matrix – In the example will use M 0, M 1 etc. • Also each node knows its parent

Rendering Hierarchies Example • Each part needs to know its absolute matrix for rendering

Rendering Hierarchies Example • Each part needs to know its absolute matrix for rendering • This is its own relative matrix * parent’s absolute matrix – Same as recursive method • But we can get the parent’s absolute matrix directly – Since we have a reference to the parent – And the parent has already been rendered earlier in the list – No need for recursion