# Programming Project Five

Due Thursday, Mar 12th, 5pm

Choose one of the following options. Each are work 15 points, the descriptions and point breakdowns are below.

## Option 1: Inverse Kinematics

Implement an inverse kinematics demo that has a single chain of 5 or more links. The links can be 1 or more DOF rotational joints, but they must be arranged so that the chain can be manipulated in 3D, not just 2D. There should be keyboard (or UI) controls that allow the user to position the goal in x, y, and z, and displays the goal in 3D. The IK chain should touch the goal position with the end of the chain or reach in the correct direction if it is out of range.

I suggest using the Jacobian transpose approach as it is the simplest and does not require any explicit construction of a Jacobian matrix. It operates one joint at a time and is the most intuitive.

3: Chain of links with rotational joints
3: User control over 3D goal position and display of 3D goal
3: IK doing something
6: IK working correctly
15: Total

## Option 2: SPH (Particle Based Fluid Simulation)

Implement a basic SPH simulation with a limited number of particles (at least a few hundred). Choose a physics algorithm from one of the ones in the paper. Display the particles as points, or as small spheres, or something. You don't need to implement any spatial data structures or fancy rendering- just get the basic physics working with as many particles as you can get running at a reasonable speed. The demo should have a reset key or possibly several keys that set up different initial conditions.

The particles should be constrained to a box to keep it under control, but SPH requires that the walls of the box act as a spring-like repulsion force, not just a hard boundary.

I suggest doing a demo where a blob of particles initializes above some ground plane and drops to the ground. You should see something resembling a splash.

3: Particle system data structures & basic rendering
3: Initial conditions set up (a blob above the ground or similar)
3: Basic gravity & ground plane and wall plane repulsion fields
6: SPH physics working correctly
15: Total

## Option 3: Rigid Body Dynamics

Write a program that simulates a single rigid body (like a box) falling and colliding with a ground plane. It should have some initial linear and angular momentum (maybe randomized). The rigid body should collide properly but does not need to come to rest perfectly or collide with other rigid bodies. The program should have a reset key and several keys that select the initial shape of the box. We should be able to select boxes with different dimensions such as cubes (1x1x1), long box (1x1x5), flat box (1x5x5), etc. to show the appropriate behaviors. You can optionally do other shapes such as cylinders, spheres, etc.

3: Basic rigid body data structures, box initialization, & box rendering
2: User controls to reset or select different starting conditions
4: Rigid body motion working (with correct tumbling behavior)
3: Something happening when the rigid body hits the ground plane
3: Ground plane collisions working correctly
15: Total

## Option 4: Particle System

Make a program that simulates a general purpose particle system. The program must have some sort of graphical user interface that allows for adjusting several parameters interactively and displays the results on the fly (suggestion: take a look at NanoGui or Ant TweakBar as possible GUIs that integrate with GL). The particles should support physics for gravity, aerodynamic drag, and collisions with a ground plane at the least. New particles should be continually created at an adjustable rate, and the particles should also have a life span that is assigned when the particle is created and then counts down to 0, causing the particle to disappear. Particles can render as small spheres or as sprites. The following properties should be adjustable:

• Particle creation rate (particles per second)
• Initial position & variance (X, Y, Z)
• Initial velocity & variance (X, Y, Z)
• Initial life span & variance
• Gravity
• Air density
• Drag coefficient
• Particle radius (for both rendering & aerodynamic drag)
• Collision elasticity
• Collision friction

4: Particle system with basic physics (gravity, air friction, ground collisions)
4: Dynamic creation & destruction (based on random life span) of particles
4: Graphical user interface
15: Total

## Option 5: Locomotion

Write a program that allows the user to interactively drive a 4 or 6 legged creature (can be made of boxes) around on flat ground, and uses a procedural walking algorithm to control the legs. The legs can use the simple analytical IK technique from the lecture. The creature should be able to choose from at least two different gaits. The legs should come to rest reasonably when the creature is stopped.

The control can be very simple- such as using the up, down, left, & right arrow keys. The creature should have a max forward/reverse speed and a max turning speed and should also have some acceleration/deceleration on the motion to keep the legs under control.

3: Basic creature skeleton set up with appropriate joints
4: Interactive controls for creature with smooth acceleration/deceleration.
4: Analytical IK working for legs
4: Walking algorithm working
15: Total

## Option 6: Quaternion Interpolation

Make a program that displays 5 'key' boxes in a row and allows the user to rotate each box arbitrarily around x, y, and z using keyboard controls or a GUI. Then, a key should turn on the interpolation which will show a box smoothly passing through the set of 5 key boxes, by using quaternion interpolation. It should allow the user to select between linear and Catmull-Rom interpolation modes, where the linear mode just 'slerps' directly between each key and the Catmull-Rom mode uses the sequence of slerp operations described on page 377 of Graphics Gems II to generate a smoother rotation sequence. In either case, the rotations should always go the 'short way'. Note that the Catmull-Rom function takes 4 quaternions and generates a smooth interpolation between the second and third, so must be used in the correct sequence to go from keys 1 to 5. To handle the border cases, just double the first or last quaternion, i.e., the first segment would look like this: CatmullRom(q0,q0,q1,q2), the second like this CatmullRom(q0,q1,q2,q3), then CatmullRom(q1,q2,q3,q4), etc.

I suggest making a quaternion class with functions for:

• float Dot(Quaternion &q0,&Quaternion &q1);
• Multiply(Quaternion &q0,&Quaternion &q1);
• MakeRotateX(float t), MakeRotateY(float t), MakeRotateZ(float t);
• ToMatrix34(Matrix34 &m);
• Slerp(float t,Quaternion &q0,Quaternion &q1);
• CatmullRom(float t,Quaternion &q0,Quaternion &q1,Quaternion &q2,Quatnion &q3);
If you do all of the key box rotations with quaternions, then you only need to convert to a matrix to render, and you should never need to convert from a matrix.

Normally, for a single slerp, it's advised to check the dot product of the two quaternions. If it's negative, you negate either one of the quaternions and that will insure that the interpolation will go the short way between the two orientations, rather than the long way.

The Catmull-Rom interpolation is built up from several slerps of other slerps (6 total). If you perform the test on each individual slerp, you might run into problems where a flip suddenly takes place partway along the interpolation. This results in a sudden pop of orientation. To fix this, all of the flipping of quaternions should take place before running the interpolation. If you are interpolating between a sequence of quaternions, you should loop through the whole set once, and flip as necessary so that the dot product between any two consecutive ones is positive.

In other words, do this on the whole sequence:

```                for(int i=1;i<NumQuaternions;i++)
if(Quaternion[i-1].Dot(Quaternion[i])<0)
Quaternion[i].Negate();
```

And don't do any other checks in slerp().