• View
• History
• Print

Main / P3

1.  Objective

The goal of this project is to give you the opportunity to implement a more complex motion synthesis/motion editing technique. The idea is to let you make the concepts of a more complicated method concrete.

Here are some choices:

1. Implement an automatic method to build a motion graph (e.g. create the distance grid and find good transitions). Do something to show that the graph is good (even just randomly generate motion). Preferably (you should have time to do at least something) have more controlled generation.
2. Manually construct a motion graph (by manually finding good motions and selecting transitions), and create a controllable character from it. (either a character that you can interactively "drive" or one that you can specify some goals and have it synthesize a motion for)
3. Implement a simple parametric graph - make single step "loopable" motions for 1/2 steps of walking and running with left and right turns. Have each step be a blend of those input steps, and the character take step after step.
4. Implement motion splicing (like in the upper/lower body paper). First try the naive version (just sticking the upper body on the lower body), then add each of the other parts to show how they help.
5. Create a character where the upper and lower parts of the body are driven by different motion graphs. To start with, you'd probably want to use a simplistic splicing method, and probably build the graphs by hand.
6. Implement motion blending between longer clips of motion. (like walk to run). Implement both manually specified alignments as well as dynamic time-warping, and see if DTW really is better (or, if you need an excessive number of points to get a decent blend manually). For example, I'd be really curious if its even possible to do the cartwheel example by hand.

I am open to other ideas, but I want to make sure we have things nailed down soon.

Ideally, you will go beyond the minimums. Once you get the basic pieces working, you can add to it or evaluate it. For example, once you get a basic motion graph thing working (#1), you might try to implement search-based control or you might do some experiments to see if changing the way the distance grid is computed effects the quality of motion.

The idea here is that you should get something simpler to work first, and then add on to it. For example, get a motion graph that generates motion by random choices, and then you can do a spiffy optimal control thing to make good choices.

There is an expectation that 838 students will take on more ambitious projects than 638 students (which is why the groups are of one type of student or the other).

Be aware that there is only 3 weeks (really a little less), so you can't be too ambitious.

2.  Requirements

You should build this using Project 2 as a starting point. If you don't think your project 2 is good enough, you can ask a different group if you can use their code.

All requirements and ground rules for Project 2 apply. For example, you need to be able to demo in 1358 (either on one of those computers or on a laptop), but you can chose your own tools.

There is an emphasis here on actually making something work on real motions, and being able to show motion results. So there is a requirement in being able to show results.

Part of showing results is picking good demos. It will be important for you to choose motions and examples that really show off what you've done. If you implement a fancy method, you may want to also implement the simple version to show the improvement (and pick examples that really illustrate it).

You are required to make regular posts to the blog.

3.  What to hand in

A big part of your grade will come from the project demos.

You will also turn in all code required to build and use your project, as well as a document describing what you've done. The details of the document will be described soon.

4.  Project Milestones

I've learned from past projects that regular deadlines are really helpful.

• Monday, April 20th - ideas email - before class, each group needs to send me an email with the basic idea of their project. If you don't tell me, I reserve the right to pick for you in class on Monday.
• Wednesday, April 22nd - project meetings - each group will meet with me to discuss their project. before the meeting, you should have an idea of what you want to do for your project.
• Friday, April 24th - project plan - each group will post to their blog with a message about their plan. You should describe the project, what you plan on doing, and how you plan on doing it. You should have some evidence that you've started working on things, even if its just a detailed read of the papers you're going to use.
• Friday, May 1st - project status update - class will meet in 1358 for looking at progress, discussion, and maybe some plan adjustment. Each group should also make a blog posting updating their status.
• Friday, May 8th - project "due" - Technically, the project is due by 5pm. We'll meet in 1358 to look at what people have. You can turn things in by 5pm to be "on-time", or take advantage of the late policy.
• Wednesday, May 13th - final exam - you need to deliver your final project to me sometime during the day on Wednesday. If you want to give another demo, you need to arrange a time with me before Wednesday (e.g. send me email Tuesday to set up a time on Wednesday)

5.  Late Policy

Officially projects have to be due before reading period.

However: I will accept late projects without penalty up until Wednesday, May 13th at 12:05pm. I need things before then because I need to get grades in so that people can graduate. Your self-evaluations can be a little later since I don't need to look at those too carefully before giving you a grade.

6.  Handing Stuff In

6.1  Demos

A lot of my assessment of what your program can (and cannot) do will come from watching your demo. So give some thought to how you show off your program. Pick good examples and motions.

We'll look at demos on Friday, May 8th 2:30-3:45 during the "Open Lab".

If your final demo is substantially different than what you demonstrate on Friday, May 8th at the open lab, you might want to show me a demo in person. Send me email to set up a time. Note: you'll have to show me stuff before Wednesday when everything is due (and I have to grade it). Also, I usually need to leave early on Tuesdays.

If your demo is different than what I've seen, be sure to describe these differences in your writeup.

6.2  Writeup

Please place your writeup on the Wiki. I'd actually prefer it to be as a Wiki page, but if you do it using some other thing (like word or LaTeX), please convert it to PDF and upload it.

In your writeup, please be clear about:

• What you were trying to do
• What you actually achieved (both in terms of what kinds of demos you can actually show off, as well as what is going on behind the scenes)
• What the "artifacts" are (what tools did you use to build your program, what does it look like, what does the user do, ...)
• A description of where it works, and where it doesn't. What examples have you tried? What is the coolest thing you can do with your program? What limitations are from things just not being implemented, and what limitations come from the approach.

When your writeup is done, please send me email (one per group, please) with a link to it. That way I'll know that its done.

I need to get your email (and therefore, your writeup) by 12:05pm on Wednesday, May 13th (the end of the official exam time slot). I really would like to get these from everyone so I can get the grading done and get grades turned in so that people can graduate.

6.3  Self-Evaluation

Please send me email (each person individually) with a self-evaluation of your group's efforts. I am specifically asking for this by email (not public), so that you can be honest in your assessment of yourself and others.

Note: I basically am evaluating the projects, and will pretty much give everyone the same grade since I have no reliable way to assess individual efforts. But, if I get a lot of emails saying that people are unhappy because they had someone either doing nothing, or doing too much and preventing them from having a good learning experience, I might try to adapt how I assess group projects in the future.

This is a learning experience for me as well. So any thoughts you have on how to run these projects better is most welcome (including how to assess groups).

In your assessment:

• An assessment of each member's contribution to your project. Be specific about what each person's (including yourself) role was (or was supposed to be).
• A self-evaluation - how well did you think the project turned out?
• What did you think of your choice of topic? Did you choose a reasonable goal?
• What would you do the same if you had to do it again? What would you do differently?

And anything else you feeling like saying.

Officially, this has to get to me by by 12:05pm on Wednesday, May 13th (the end of the official exam time slot). I'd rather have your thoughts later in the day (but still on Wednesday) then getting something less thoughtful earlier.