source can be found at: http://www.upl.cs.wisc.edu/~jhugo/jeff_ryan_will.zip
Limitations of the parser
Our parser currently isn't correct, so that will be the first thing to fix for P3.Our parser has been fixed, so it now loads motions correctly, and people no longer defy gravity.
The biggest limitations of our parser are it only handles ZXY ordering for rotations, the root must have 6 channels (xpos, ypos, zpos, zrot, xrot, yrot), and joints must have 3 channels. The code has machinisms to easily support other orderings (add a define, and add two ifs in specific spots). Adding the ability to handle other channels would require an extensive refactor (and only came up in one file we randomly picked where a "knee" joint only had an xrot channel).
Other limitations include things like the expectation that there would only be one hierarchy. It wouldn't be too hard to fix this, if it ever came up. Unnecessary white space is considered a syntax error. Our parser throws out CONSTRAINTS and TAGS if they occur, only because we couldn't find any documentation as to what it was used for, and they rarely came up in our random sampling of files.
Working basic requirements
- Read BVH files
As mentioned above our parser isn't quite correct. We suspect one of the axis is being confused for another. This is best demonstrated when displaying the dancer files where the dancer moves in mid-air in a physically impossible manner.
- Display motion data
- we have a ground plane, an actor made of ball joints and cylinder bones, and drop shadows
- when selecting a motion, the camera moves to a position that allows full view of the motion by moving back to the greatest Z position of the root, positioning to the mid point on the X axis of the motion, and then moving back a bit more to account for X axis motion and to get the entire actor's body in view at all times
- the camera can be manually moved at any time
- the motion can be "scrubbed" or played at one of two speeds: the framerate listed in the file or at 30fps.
(no frames are dropped or added, they are just played at 30fps instead of the file listed speed). The motion is now played at the requested fps regardless of whether or not the computer can keep up (frames can be dropped to keep the motion playing at the desired framerate).
- Displaying other information about the motion
- we did not implement traces, instead we allow the user to display all of the frames of the motion at once, or select a number of adjacent frames to display (strobes).
- Concatenation and blending
- concatenation and blending are implemented using Euler angles. Our blending does a simple linear interpolation of the angles using a constant, or linearly varying, weight. Newly computed motions can be saved to a file.
Bonus features
- Helpers for visualization of motion.
- We had a "show all motions" button which showed all the motions at once. For large motions this isn't terribly helpful, but with small ones we can foresee it being helpful. This feature is also the reason that the end-sites are all different colors, since this helps differentiate the motion.
- We have strobing working. It shows the X adjacent frames to the current frame, and you can choose a value of X using a slider. It's kind of chaotic at first, so we added an option to make the additional frames transparent or opaque. We found that transparent looked better, so it's the default. The further a frame is away from the current frame, the more transparent it should be.
- Concatenation stuff.
- We rigidly align the end of the first motion with the beginning of the second motion.
- We also blend the "transition frames" between the two motions, theoretically to give a better looking transition. It uses the smaller of the sqrt of the number of frames per motion to choose the number of frames to blend together. It also does some bounds checking to make sure we have enough frames to do the blending with.
Outside code and resources
We used the Boost library's string algorithms to assist in parsing the BVH files. We also used a tree library written by Justin Gottschlich (found on GameDev.net) which could do a deep copy in a single operation. This aided in loading and displaying frames, because we could make a frame by copying the hierarchy tree and changing the relevant numbers.
Program description
- Load files in using the Open File button.
- Delete a loaded file using the Delete? button. Do so by selecting an entry in the first browser, and clicking the button. It'll be deleted from both.
- Write To File will write the entry in the first browser to file.
- To blend, select the first motion in the first browser, and the second motion in the second one. Select which frames you want to blend (using the sliders below each browser), and the beginning and end weights of motion 1 (motion 2 will use complement weights) using the sliders on the bottom. Once everything is selected, hit "Save Motion" to figure out all the details. Then hit "run" (the new motion will appear in both browsers and will be auto-selected in the first). If the number of frames aren't equal, it'll figure out how many frames to blend (using the smallest range).
- Concatenation follows the same rules as blending, including the weights (since it blends at the transitions). You also need to hit "save motion" here as well.
- If you make a new motion using blend or concatenation, it'll appear in both browsers with a format that'll tell which files it used, what the operation done was (C = concat, B = blend), the frames used (first motion first), the beginning weight of motion 1 (bw) and the ending weight of motion 1 (ew).
- Select currently viewed motion using the top-most browser. This is also the "first motion".
- Select the second motion using the second browser.
- Camera keys: standard wasd for movement, 'q' moves down, 'e' moves up. Left click to move forward, and right click to rotate around the view.
- Hit "30 FPS?" to render at 30 FPS. If it's unselected, the file's natural frame rate will be used.
- The scrubber is fairly standard.
- To see all motions in a file, select it in the first browser, and then hit the relevant button.
- To strobe, change the slider to however many adjacent frames you want seen. To make these non-transparent, hit the Opaque? button on the bottom right.
Screenshots
Here's some attempted proof that blending is working. You can see the hand (the orange part) transitioning from the walkStraight motion to the jogFast animation.
Here's a picture of concatenation working. Note the "jump" in the position of the arms. This is to show that concatenation is indeed working. Normally there'd be a blend here, but I turned off the blending to make the concatenation more apparent.
This shows our blends between the concatenation. Notice that the head transitions more smoothly, and that there isn't such a huge gap between then arms.
This shows that our motion is now read in correctly. Before, this guy would've been levitating around (kinda drunkenly), but here you can the correct motion (his head is the orangish dot at the front).
A picture of out "show all motions" button used on the Destroy motion. It kinda looks like a Native American in an Eagle Costume, so we think it looks cool. This one looks like he has a robe on.
Evaluation of other groups projects
We feel as if we couldn't get the best "feel" for which frameworks were better than others, since all we saw was the graphical part. Some of the frameworks probably looked great, but aren't too flexible. However, with that limitation in mind, here is what we thought of the other group's work.
Eric/Blayne's Project: From what we've seen, it looks like it'd be an alright framework. It basically seems like ours, but where we have all the concatenation levels done, but they have tracers.
Yoh/Brandon/Finn: we found this one pretty nifty. Their tracers helped visualize the motion quite well, and they had the nifty fade effect. They also had quaternions working, which is a big boost to how good their framework is. We also took the idea of round nodes and cylinders for bones from them, which made everything look a lot better.
Dan/John/Adrian: their parser sounded like a great idea, and I heard they had a .obj and texture loader working at one point too. It looked like they had a few problems with motions not working correctly, and their quaternions didn't *quite* work, but once they fix those problems, we think their framework would be excellent for P3. They also skipped frames if the timer was too slow, which is a nice feature.
Cory/Alex/Tom: It seemed like there framework would be alright. They had quaternions working, which is excellent. They also had strobing, which is a nice feature. All-in-all, unless the underlying code is a mess, this would probably be a decent framework.
Mick/Yang/Betsy: It was shiny, and it worked very well. It also had everything working. So it's a safe bet to say this is one of the better frameworks (as long as the code is fine!)
