For your final project, you'll make something really cool!

Your Program 2 (due a week from today). Start now (especially finding obj files):

• We'll have a MT on the day it's due. Today and next week's lecture are places to ask all your lingering questions.
• You're P2 will probably influence what you want to do for your final project.

Hiearchial Animation (Geometric Transforms)

Program 2 is about geometric transforms to build a scene:

A skinned mesh animation is applied to the bones of a character. We have affine transforms, that are the same scale, translate, rotate transformations. The idea here is that the bones* themselves need to be animated, and the mesh follows it:

This is more of an artist driven animation. On the flip side, you can have physical based animation where you model our item with a bunch of balls and springs, and calculates pushes/pulls via their spring forces numerically.

Multishape Meshes

This is a data structures issue. So far for P1 and labs up to now, we've only loaded a single shape and added transformations of them. However, now we'll want to associate pieces of our higher model to individually control them. For instance, the dummy.obj there's a group of vertices and faces for each shape of the dummy. For instance:

obj
	shape1
		vert
		faces
	shape2
		vert
		faces
	...
	

For the dummy, there's things like:

Dummy obj
	Right foot
		verts
		faces
	Right Ankle
		verts
		faces
	...

So for our Lab 5, you are given the tiny_obj to load the objects (ie: setup OpenGL to have its data sent to the GPU), but doesn't contain the code to transform and draw the animations themselves:

You'll

1. Compute the global bounding box
2. Transform the bounding box to the origin
3. Transform in the scene.

You'll need to modify the tiny_obj code to allow us to draw and read multiple shape. A lot of the obj's in the wild are multishape.

glm::translatemat4(), glm::vec3(10.0f, 0.0f, 10.0f);

For hierarchical modelling of our transformation, you'll want to use the stack. The idea here is that when you push on the stack of our transforms, you'll just multiply the current matrix with the new one. When you pop, you'll divide by the matrix you pop from.

void setupObj1(const shared_ptr<MatrixStack> MV)
{
	MV.translate(Vector3f(0, 5, 4)); // push the translate matrix onto MV. Now we have MV * Trans
	MV.rotate(-45.0, Vector3f(0.0, 0.0, 1.0)); // push the rotate matrix onto the MV. Now we have MV * Trans * Rotate
	gl.UniformMatrix4fv(prog->getUniform("MV"), 1, GLF_False, ...);
}

Usually the starting top of the MatrixStack is the identity $I$. An important concept is that pushing copies the top element from the stack:

If you have a higher hiearchial model, you should have the matrix of the reference then push the little transforms you want in reference to that. For instance:

• First you push the world frame transform
• Then the camera view transform
• Then the transform on the main object
• Then the transforms on the subobjects
• Then the transforms on the subsubobjects
• ....

That means that if you have a lot of objects that need to sync to a transformation (such as with the camera), then when you change that matrix, it transforms everything.

The key point is that most recent transformations are on the top of the stack. Transformations that occur before or change later transformation are at the bottom.

So for our Hierarchical Model of animation, you want to draw the object from most abstract to most specific:

• You have the base of a tree trunk, with given positions
• You build the branches of the tree in reference to the position of the trunk, with some transformations relative to it
• You build leaves in reference to each branch, with some transformations relative to it.
• ...

You read from the bottom of the stack, with the most specific matrices, to the top of the stack with the least specific matrices, as the left-to-right matrices corresponding to their transforms.