Response to Feedback:
1. How does this approach plan to handle computing where the blends begin?
Since our first post, we’ve better elaborated our approach to creating paths; instead of appending individual splines together, we are going to “decouple” the locomotion from the motion. Thus, the user will draw a single locomotion curve (i.e. where in physical space the character will travel) and then specify ‘breakpoints’ along this curve for what motions to use while locomoting. The program will then blend the overlap of weights automatically (for example, red to blue → gradient of blend weights).
2. Will there be any smoothing constraints on the input motion paths to avoid discontinuities? How will the tool handle the order in which different splines are traversed?
Since we will not be appending splines, we don’t have to worry about discontinuities between individual paths. The spline will be created by the user via setting points or ‘sketching’ sampled points along the ground plane which will then be put into a spline fitter; so no matter what, the curve will be continuous. Because we’ve decided to not append splines, ordering won’t matter.
3. What is the sketching interface?
We plan on letting the user set points or sketch a curve, directly on to the ground plane of our existing environment. Since there is only one curve to be drawn (which will be drawn one point at a time), the locomotion curve, there won’t be any vague curves. In addition to placing points on the ground plane in 3D, we’re also considering adding a 2D representation of the ground plane to the UI. The user will be able to place points on to the 2D representation and they will appear accordingly in the 3D window. This will help greatly with sketching specific shapes.
For ‘motion brushes’, at this point, we’ve decided to make a drop-down list of available motions that the user can select from. With the locomotion curve in place, the user can then, like with the spline point-placing, set motion ‘breakpoints’ where they want them. Based upon the motion ‘breakpoints’ the locomotion curve will be colored correspondingly. When motion breakpoints change from one motion to another, the locomotion curve will blend the colors of the corresponding motions along the curve.
4. Search strategy?
We haven’t discussed this too in-depth at this point. For now we have decided on A* search, but we won’t rule out bi-directional just yet.
Progress Since Original Proposal:
Due to some harsh deadlines, Adrian and Michael have been ridiculously (and understandably) busy with other projects. Reid and I on the other hand have been making some progress, but of course it’d be nice to have made more. Here’s what we’ve accomplished since the proposal:
-motion database structure for generating a motion graph
-distance metric function (uses joint orientations)
-preliminary blending between motions
-improved visualization of position constraints
-function for placing points on the ground plane
Luckily, I couldn’t be happier to spend my Spring Break indoors sitting in front of a computer monitor; so idealistically, we should be making some progress this week. Keep in mind, we ‘should’ be making progress (if only I can stop watching Dexter…).
Updates to Proposal:
The main conceptual difference from the original proposal is that we will ‘decouple’ the locomotion curve from the motion curve. Other than that, nothing else has changed much.
(Image below shows: improved constraint visualization, distance metric, and preliminary blending. Red Sphere w/line to joint = currently constrained, Green Sphere = not currently constrained)
