General Group Structure:
David Guild has officially dropped the class, and therefore is no longer part of our group.
Current Project Goals:
- Implement the system detailed in the following paper:
- James McCann and Nancy S. Pollard. Responsive Characters from Motion Fragments, ACM Transactions on Graphics (SIGGRAPH 2007), August 2007, Vol 26. No. 3.
- The task is to, based on the current motion fragment and next input control from the user, select the next fragment to play from a generated policy table. During run time this operation should be quick and require little computation. The policy table will be generated with a Reinforcement Learning technique, using non-animated runs to collect initial seed data (traces from the paper), though given our internal discussions perhaps more than one technique will be developed for experimental comparison. The motion fragment data will be stored in a database as frames, whose data has been marshaled via python’s pickle module. Additionally, the policy tables and associated data structures will also be stored in the database – by this method we will move the data from the offline RL system to the run time visualizer. We will modify and use the infrastructure client from Phase 1 to act as our motion loading and fragmenting interface. As it has the ability to load and display motion already, a few additions to support fragmenting and user tagging of fragments ( which correspond to buckets from the paper ) will be added.
- We are focusing on the Reinforcement Learning technique which is core to the paper, while putting less focus on other issues (such as blending )
- While blending will make for better transitions between fragments, we are curious how close the RL technique comes to matching fragments. If the fragment similarity is high enough, the fragments should hopefully provide their own transitions ( at least at the quality expected for games and related interactive systems ). If we determine the quality is too poor, we will integrate blending into the system again.
Demo Expectations:
- We will provide a simple world and character. There are visual obstacles to avoid, though they do not restrict movement. The character will have the following actions: Walk forward/backward, Walk left/right, Turn left/right, Jump, Sprint. Any one of these five basic actions can be done at the same time and the animation should match the appropriate movement the user is directing the character to preform. The user will remain in direct control of the character as the animations will not effect the root position of the character.
- During the demo, the system will load a precomputed policy table that we generated before hand. Then the character will be able to moved through the scene.
Success Evaluation:
- Success will be determined by how well the character’s animation matches the current movement ( ie. does the correct action visually, does not lag behind the input controls, etc… ) and overall how good the character’s movement looks. Obviously this is a subjective measure, but there are certainly very concrete evaluations that can be made ( no sudden jerks, animation that flows from one fragment to the next without discontinuity, etc… )
Current Status:
- Animation Loader (Nathan) – Currently having issues. There seems to be some cross platform issues with the glsl shaders used by Ogre3d. We have been using the sample shaders for linear blend skinning, but they seem to be unreliable on Linux. This may be related to graphics drivers, but we are not sure yet. On Windows the shaders seem to work fine. It may be possible to write new shaders that overcome the difficulties, but that is probably an unwise use of time.
- Database Connection (Nathan and Daniel) – A SQLAlchemy python module has been written to model the database schema we have developed. Currently most tables are implemented and working, including the ability to load and unload raw frame data to and from the database. This is accomplished via SQLAlchemy’s built in pickle field type.
- Reinforcement Learning Module (Daniel and Danielle) – A rough draft of the RL algorithm has been coded, though not well tested. It will probably need refinement and will need to be connected with the other pieces already implemented. Due to the discussion we had on Sunday, we will probably be implementing an additional RL algorithm that solves the problem in a slightly different fashion. More details on that to come once it has been roughed out in code
- Fragment Loading (Nathan and Others) – No progress yet, but that is the next task after the Animation Loader is deemed complete. Probably this next week. Then we will need to spend some time loading the motion data in by hand.
Data:
- We will be using the CMU motion data database, as did the paper authors. As they do not specify which five minutes out of the large collection they used, we will need to examine the labeled clips and decide what we want to use. We will be looking for clips that generally match the buckets we are using, hopefully to generate better matching fragments.
Plan:
- This week:
- Danielle is busy this week but will be free after the paper deadline on Thursday. Then she will turn her attention back to the RL algorithm. By the weekend, we expect to be in a position to run some tests on that code.
- Daniel is working on the alternative learning algorithm and will be exploring how best to link it and the one Danielle is working on to the database ORM.
- Nathan is working on the run time visualizer and then the fragment loading system, which will be a modification of the Infrastructure code base.
- Next week:
- Individual assignments have not yet been determined.
- Will finish data loading and running test cases to determine the learning algorithms are functioning. Assuming everything goes as planned, we will spend any remaining time adding niceties like between fragment blending and perhaps a parallel thread to do current policy re-computation (I wouldn’t count on this one too heavily).