Skeleton Kinematics - cmu462/Scotty3D GitHub Wiki
A Skeleton
is what we use to drive our animation. You can think of them like the set of bones we have in our own bodies and joints that connect these bones. For convenience, we have merged the bones and joints into the Joint
class which holds the orientation of the joint relative to its parent in its rotation
, and axis
representing the direction and length of the bone with respect to its parent Joint
. Each Mesh
has an associated Skeleton
class which holds a rooted tree of Joint
s, where each Joint
can have an arbitrary number of children.
All of our joints are ball Joint
s which have a set of 3 rotations around the ![height=18px](https://raw.githubusercontent.com/wiki/cmu462/Scotty3Dmedia/task4_dev_eq_images/0027.png|height=9px]], media/task4_dev_eq_images/0028.png, and media/task4_dev_eq_images/0029.png axes, called Euler angles. Whenever you deal with angles in this way, a fixed order of operations must be enforced, otherwise the same set of angles will not represent the same rotation. In order to get the full rotational transformation matrix, media/task4_dev_eq_images/0030.png, we can create individual rotation matrices around the media/task4_dev_eq_images/0031.png, media/task4_dev_eq_images/0032.png, and media/task4_dev_eq_images/0033.png axes, which we call media/task4_dev_eq_images/0034.png, media/task4_dev_eq_images/0035.png, and media/task4_dev_eq_images/0036.png respectively. The particular order of operations that we adopted for this assignment is that [[media/task4_dev_eq_images/0037.png).
Task 2a - Forward Kinematics
Note: These diagrams are in 2D for visual clarity, but we will work with a 3D kinematic skeleton.
When a joint's parent is rotated, that transformation should be propagated down to all of its children. In the diagram below, ![height=12px](https://raw.githubusercontent.com/wiki/cmu462/Scotty3Dmedia/task4_dev_eq_images/0038.png|height=12px]] is the parent of media/task4_dev_eq_images/0039.png and media/task4_dev_eq_images/0040.png is the parent of media/task4_dev_eq_images/0041.png. When a translation of media/task4_dev_eq_images/0042.png and rotation of media/task4_dev_eq_images/0043.png is applied to media/task4_dev_eq_images/0044.png, all of the descendants are affected by this transformation as well. Then, media/task4_dev_eq_images/0045.png is rotated by media/task4_dev_eq_images/0046.png which affects itself and media/task4_dev_eq_images/0047.png. Finally, when rotation of media/task4_dev_eq_images/0048.png is applied to [[media/task4_dev_eq_images/0049.png), it only affects itself because it has no children.
media/forward_kinematic_diagram.jpg
You need to implement these routines in dynamic_scene/joint.cpp
for forward kinematics.
- Joint::getTransformation()
Returns the transformation up to the base of this joint (end of its parent joint).
Joint
is a child class ofSceneObject
which has its own version ofgetTransformation()
that you can use by callingSceneObject::getTransformation()
. As explained above, a joint's transformation is accumulated as you traverse the hierarchy of joints. You should traverse upwards from this joint's parent all the way up to the root joint and accumulate their transformations. Also, make sure to apply the mesh's transformation at the end, accessible withskeleton->mesh->getTransformation()
. Joint::getBasePosInWorld()
Returns the base position of the joint in world coordinate frame.Joint::getEndPosInWorld()
Returns the end position of the joint in world coordinate frame.
Once you have implemented these basic kinematics, you should be able to define skeletons, set their positions at a collection of keyframes, and watch the skeleton smoothly interpolate the motion (see the user guide for an explanation of the interface). The gif below shows a very hasty demo defining a few joints and interpolating their motion.
Note that the skeleton does not yet influence the geometry of the cube in this scene -- that will come in Task 3!
Task 2b - Inverse Kinematics
Single Target IK
Now that we have a logical way to move joints around, we can implement Inverse Kinematics, which will move the joints around in order to reach a target point. There are a few different ways we can do this, but for this assignment we'll implement an iterative method called gradient descent in order to find the minimum of a function. For a function , we'll have the update scheme:
Where is a small timestep. For this task, we'll be using gradient descent to find the minimum of the cost function:
Where ![height=12px](https://raw.githubusercontent.com/wiki/cmu462/Scotty3Dmedia/task4_dev_eq_images/0054.png|height=19px]] is the position in world space of the target joint, and [[media/task4_dev_eq_images/0055.png) is the position in world space of the target point.
More specifically, we'll be using a technique called Jacobian Transpose, which relies on the assumption that:
Where:
- ![height=14px](https://raw.githubusercontent.com/wiki/cmu462/Scotty3Dmedia/task4_dev_eq_images/0057.png|height=14px]] (n x 1) is the function media/task4_dev_eq_images/0058.png, where media/task4_dev_eq_images/0059.png is the angle of joint [[media/task4_dev_eq_images/0060.png) around the axis of rotation
- is a constant
- ![height=14px](https://raw.githubusercontent.com/wiki/cmu462/Scotty3Dmedia/task4_dev_eq_images/0062.png|height=16px]] (3 x n) is the Jacobian of [[media/task4_dev_eq_images/0063.png)
Note that here ![height=18px](https://raw.githubusercontent.com/wiki/cmu462/Scotty3Dmedia/task4_dev_eq_images/0064.png|height=9px]] refers to the number of joints in the skeleton. Although in reality this can be reduced to just the number of joints between the target joint and the root, inclusive, because all joints not on that path should stay where they are, so their columns in media/task4_dev_eq_images/0065.png will be 0. So media/task4_dev_eq_images/0066.png can just be the number of joints between the target and the root, inclusive. Additionally note that since this will get multiplied by media/task4_dev_eq_images/0067.png anyways, you can ignore the value of media/task4_dev_eq_images/0068.png, and just consider the timestep as [[media/task4_dev_eq_images/0069.png).
Now we just need a way to calcluate the Jacobian of . For this, we can use the fact that:
Where:
- ![height=19px](https://raw.githubusercontent.com/wiki/cmu462/Scotty3Dmedia/task4_dev_eq_images/0072.png|height=16px]] is the media/task4_dev_eq_images/0073.png column of [[media/task4_dev_eq_images/0074.png)
- is the axis of rotation
- ![height=14px](https://raw.githubusercontent.com/wiki/cmu462/Scotty3Dmedia/task4_dev_eq_images/0076.png|height=16px]] is the vector from the base of joint [[media/task4_dev_eq_images/0077.png) to the end point of the target joint
For a more in-depth derivation of Jacobian transpose (and a look into other inverse kinematics algorithms), please check out this presentation. (Pages 45-56 in particular)
Now, all of this will work for updating the angle along a single axis, but we have 3 axes to deal with. Luckily, extending it to 3 dimensions isn't very difficult, we just need to update the angle along each axis independently.
Multi-Target
We'll extend this so we can have multiple targets, which will then use the function to minimize:
which is a simple extension actually. Since each term is independent and added together, we can get the gradient of this new cost function just by summing the gradients of each of the constituent cost functions!
You should implement multi-target IK, which will take a std::map
of Joint
s and target points for that joint. Each joint can only have 1 target point.
In order to implement this, you should update Joint::calculateAngleGradient
and Skeleton::reachForTarget
. Joint::calculateAngleGradient
should calculate the gradient of in the x,y, and z directions, and add them to Joint::ikAngleGradient
for all relevant joints. Skeleton::reachForTarget
should actually do the gradient descent calculations and update the angles of each joint, saving them with Joint::setAngle
. In this function, you should probably use a very small timestep, but do several iterations (say, 10s to 100s) of gradient descent in order to speed things up. For even faster and better results, you can also implement a variable timestep instead of just using a fixed one. Note also that the root joint should never be updated.
A key thing for this part is to remember what coordinate frame you're in, because if you calculate the gradients in the wrong coordinate frame or use the axis of rotation in the wrong coordinate frame your answers will come out very wrong!
Using your IK!
Once you have IK implemented, you should be able to create a series of joints, and get a particular joint to move to the desired final position you have selected.