Search:

# Contrib / JeffWillRyanP3WriteUp

Source code: http://www.upl.cs.wisc.edu/~jhugo/cs638_p3.zip

A generated cost graph: http://www.upl.cs.wisc.edu/~jhugo/pics/costTable.jpg

A generated cost graph with dynamic timewarping: http://www.upl.cs.wisc.edu/~jhugo/pics/dpTable.jpg

Best path through spliced motions: http://www.upl.cs.wisc.edu/~jhugo/pics/pathTable.jpg

What we were trying to do:
We were trying to do dynamic timewarping based splicing of motions. That is, realistically putting the upper body of one motion onto the lower body of another motion.

What we actually achieved:
We created a program which can take two motions and splice the top half of one onto the bottom half of another, and slow down or speed up one of them to match the speed of the other. The spliced motion then looks like an original motion (as much as is possible): it puts the left arm forward with the right leg, and vice versa. The kinds of demos we can show are fairly limited in the program's current state, but that is mainly a consequence of not having enough time to first find other good motions (motions that one would want to splice in the first place), and then to actually test those motions.

Behind the scenes, we first find the node above the root (along the y-axis) to figure out where to splice the motions together. Then we run our timewarping algorithm to figure out how one motion should be slowed down/sped up to match the other. This is done by constructing a cost table of the difference between each frame of one motion and each frame of the other. Then we fit a line to the table that minimizes the total cost of the motion.

Where it works, and where it doesn't: Our splicing algorithm works well for motions that are linear in time. It doesn't work well for motions that slow down and speed up too much. There's also a limitation that the beginnings of the motions have to be roughly aligned. For example, it won't work well if the beginning of one motion is about to take a step with its left foot, while the other motion is about to step with its right. This was something we were working on near the end, but couldn't get it working in time.

Tools: In addition to the tools documented in P2 (boost, fltk, a tree library), we used some 4x4 matrix code from Alex, Cory, and Tom's group.

How to use:

The program: http://www.upl.cs.wisc.edu/~jhugo/pics/p3ui.jpg