|
|
| Tree view showing the joint hierarchy | GL view showing the skeleton and the bounding volume |
The goal of the project is to build a tool for visualizing and manipulating motion capture data. Screenshots of the tool are shown in the following figures.
|
|
|
| Tree view showing the joint hierarchy | GL view showing the skeleton and the bounding volume |
The tool provides the user with two views of the data. The first view uses the motion data to draw and animate a simple skeleton; this gives an immediate and intuitive impression of the motion. The second view provides a more detailed presentation of the motion: the skeleton is visualized as an hierarchy of joints, and the user can examine the rotation and translation channels of any joint by selecting it. In this manner, the user is able to examine the motion in two different levels of semantic "zoom". The interface also provides controls to replay the motion interactively, to control the camera of the graphical view, and to set interpolators for any range of frames.
In general, the implemented functionality of the tool can be broken down in the following six points ('*' indicates a bonus feature):
In the sections that follow, we first present the general implementation details of the tool, and proceed to discuss in more detail each of the previous points.
The tool is implemented in Java (jdk 1.1.7). Apart from the Java runtime, the following packages are required:
The implementation of the tool is based heavily on the Model-View-Controller (MVC) design pattern. Motion capture data represent the "model", which is visualized by a number of different "views". In our case two views are provided: the animated graphical view, and the more detailed joint hierarchy view. The visual controls for time and interpolators represent the "controller" that alter the state of the model, and therefore the state of the visualizations.
Figure 1 shows a simplified class diagram of the tool. The "model" is implemented in terms of the AnimationModel class. This class controls the time of the model and acts as a mediator for the following classes:
Currently, three factories are implemented:
The "view" of this model is abstracted by the ModelView class. This class is realized in two subclasses:
The "glue" between the model and the view is provided by ViewFrame. This class represents an association between an instance of AnimationModel and an instance of ModelView. This association is one to many, which means that different views can share the same model. This class also provides the visual controls that are common among all views.
At this point we conclude our short overview of the implementation. In the following sections, we will focus on the different functions of the tool and we will provide more implementation details as needed. In addition, the interested reader can find more information in the generated javadoc documentation of the source code.
The tool reads in motion capture data in the Biovision format (.bvh files). The parser for the data was implemented using the JavaCC parser generator. The tool makes no assumptions on the format of the input and can read arbitrary skeleton hierarchies. The only assumption is that translation channels will be named with Translate{X,Y,Z} and rotation channels with Rotate{X,Y,Z}. The tool honors the order of the rotation channels for each joint and the rotation matrix is calculated based on the specified order.
The camera eye and look at points are determined by Camera. Two primary types of implementation are:
It is important to note here that both main views share the same animation model. Apart from the obvious save in resource consumption, this also means that the two views are completely in sync: whatever change is applied to the model, it will appear in both views. Therefore, they will always display the same frame and the same interpolators will apply in both of them.
The user can control the replay of the motion using the "video" buttons that each window contains. The tool supports replay of the motion in normal and fast speed, and also in both directions (backwards and forward). There is also a looping option, which wraps the frame number around when the end or start of frames is reached. Apart from the automated replay of frames, the user can also move manually to the next or previous frame, or directly set the value of the text field that shows the current frame. As we noted earlier, since the two main views share the same animation model, the replay of frames can be controlled from either of them and they will always be in sync.
Internally, the model is traversed in a depth first manner to produce the expected matrix stack manipulations.
The interface allows the user to select a range of frames and the kind of interpolation that will be used (if there is actually a choice). The current version of the tool supports the following interpolators: linear interpolation for Euler angles, median filter for Euler angles, SLERP interpolation for quartenions and linear interpolation for exponential maps.
We have also used the interpolator framework to implement a median cut filter, suitable for smoothing out the high frequency components of the motion. This filter acts much like an interpolator, but calculates the value for each rotation channel by examining the values in the previous and next frames.
Since the framework allows interpolators to be stacked, one can imagine layering the median cut filter on top of the original motion data, and then applying linear interpolation on top of that; as a result, interpolation will be applied after the filter has smoothed out the high frequency "noisy" components. In this manner, users "mix & match" these simple interpolators and filters until they arrive at the desired visual result. Although we could potentially include the filtering mechanism in the interpolator, we believe that the direct manipulation of the interpolation stack provides a more intuitive and flexible interaction paradigm.
The map interpolator implements linear interpolation between the starting and ending parameterized quartenion. It uses linear interpolation independently on each coordinate of the quartenion, and produces aesthetically pleasing results, as longs as the two quartenions are close in Euclidean space. We noticed, however, that in some cases, the interpolation would produce spurious results even though the start and end keys represented similar rotations.
To illustrate this, imagine a starting rotation of -(pi-epsilon) around the positive y-axis, and an ending rotation of (pi-epsilon) around the positive y-axis. Although the two rotations are actually 2*epsilon radians apart, linear interpolation will travel counter clockwise around the circle in order to move between the keys.
We were able, however, to discover the source of the problem by examining the axis-angle view of the rotation. Since parameterized quartenions are constructed with the logarithmic map, this causes all angles to lie in [0,2*pi]; therefore, the negative rotation around the positive y-axis is transformed to a positive rotation around the negative y-axis. This means that interpolation has to work its way from a starting negative axis to an ending positive axis, thus causing the trip around the circle.
In order to remedy this, we have implemented a second version of the linear interpolator that aligns the start and end keys. More specifically, the interpolator computes the inner product of the keys, and if negative it reverses axis and angle of the start key. This has the effect of bringing the two keys closer together in Euclidean space, and decreases the chances of producing spurious rotations.
Euler Linear Interpolation
Linear interpolation in Euler space results in a trip in the wrong direction. Not only that, but the rotation is not smooth: it accelerates in the middle, and decelerates close to the start and the end.
 |
 |
'  |
 |
 |
 |
Quartenion SLERP Interpolation
SLERP interpolation provides a very smooth rotation, since it masks out the change of sign.
 |
 |
'  |
 |
 |
 |
Map Linear Interpolation
Plain linear interpolation in the exponential map gives poor results, since the two rotations are far apart in Euclidean space. We basically get the same results as the Euler angles interpolation, with an increased acceleration in the middle.
 |
 |
'  |
 |
 |
 |
Map Aligned Interpolation
Aligned map interpolation applies a simple heuristic to bring the start and end rotation close in Euclidean space. This simple heuristic produces very good results in our case, since the initial rotation is "mirrored" and the axis reversed. Essentially, we get results that look similar to SLERP interpolation.
 |
 |
'  |
 |
 |
 |