Phase 2 Status – Chaman, Jim, Raja, Xiaolu

by xlzhang on March 25, 2011 · 2 comments

in Project 1 Post-Break Checkpoint

Main Idea / Objective

Implementing Laplacian Path Editing, and a subset of path editing features inspired by the “Synchronized Multi-Character Motion Editing” paper.

What we will demonstrate by the due date

  • Multiple character loading : load multiple BVH files or make multiple “clones” of the same BVH motion, offset in space.
  • For each skeleton, the ability to draw the path of its root node to show the user where the skeleton will be as it travels.
  • For each skeleton, the ability to drag and edit the root path so that the skeleton will move to the desired location.
  • For each skeleton, the ability to implement idling in place, halting its action.
  • A mechanism to ensure realistic motion as the edited character moves along its new path. Have not decided on whether the mechanism should be a motion graph, or whether to search through the motion data to find a “loop” to replay. Objective is to avoid obvious footskating.
  • Joint angle based skeletons will be converted to quaternion based skeletons.
  • Temporal and spatial constraints along the lines of “this character will be at this place, at this time”.
  • Possible features: Group motion editing, planting obstacles in the path of a skeleton which the skeleton will detect and walk around.

Success Criteria and Evaluation

  • User is able to load skeletal data files.
  • User is able to switch on / off ability to view root paths.
  • User can edit motion paths by dragging the existing path to where he desires
  • User can preview changes in real time before finalizing the path, possibly at reduced frame rate due to Laplacian calculations, but at least can have an idea of the result.
  • User can load multiple skeletons, select the individual skeletons and edit all their paths at any time.
  • User can play back the resulting animation after editing, motion will look smooth.

Current Status

What has been done, what is working :

  • Multiple skeletons can be successfully loaded, playback enabled.
  • Joint angle based skeletons are converted to quaternion based skeletons, interpolation is done for quaternion based skeletons.
  • The path of one skeleton can be edited by dragging discrete control points, direct manipulation of the path itself is not yet implemented.
  • Laplacian path editing that fits a new path to the edited control points is working.

Problems, difficulties, stumbling blocks :

  • How to produce smooth realistic motion when the edited path is noticeably longer or shorter than original motion. Current thoughts: use motion graphs, find a loop within the motion sequence (the ending frame is extremely similar to an earlier frame) that we can reuse.

Data

CMU motion capture database contains a large variety of motion including jumps, swordplay, run, walk, etc.

Plan

To be modified based on the results of this weekend’s experimentation:

Chaman – Finding loops in motion sequences; other alternatives to using motion graphs in order to produce realistic motion for stretched / shrunk paths.

Jim – Trying to use motion graphs to produce realistic motion for stretched / shrunk paths.

Raja and Chaman -Using streamlines (of a potential field) to dictate group motion with obstacles;  if that doesn’t work, use concepts of mesh deformation for group motion with obstacles.

Xiaolu – Rendering, path editing UI; modifying framework to accommodate staggered playback, delayed playback similar to Synchronized Character paper; selection of single skeleton or subset of skeletons for editing; any other UI things the team needs.

Screenshots


{ 2 comments }

raja March 27, 2011 at 1:41 am

Answers to couple of Mike’s questions:
i) Regarding control points and laplacian editing:
Right now, the UI interface doesn’t support “line dragging” to set the constraints of the new path.
Instead, it populates a bunch of points (which we called control points) on the original path that can be dragged to set the constraints.
For the final submission, we will definitely try to get the more intuitive line dragging UI working. Laplacian editing works once the constraints are set.

ii) Regarding where we’ll be getting the group motions to edit:
The inspiration for the kind of group motion editing we’re trying comes from http://mrl.snu.ac.kr/research/ProjectGroupMotionEditing/index.htm

Essentially, there will be one (yes, just one) motion that an army of characters will use. The main focus of this part is to maintain the “group” characteristic of the characters in the presence of obstacles.
So, as the user, you get to specify the number of characters in the group, choose a motion file and place obstacles. This is a lofty goal, but its something Chaman and I want to get working. Lets see how far we get with this.

xlzhang March 28, 2011 at 11:43 am

More answers to Mike’s questions:

In the final state of the project, a user will be able to load in BVH files of motions, and change the path (direction, length) of the motion. See the screenshots where the original motion goes in a straight line and the modified motion walks in a loop. “A mechanism to ensure realistic motion” just means that whether we decide on a motion graph implementation or simply finding a loop within the file that can be replicated, a path can be stretched and the resulting longer motion will be created with extra steps inserted.

Previous post:

Next post: