Project Journal

Weeks 1 & 2
My first two weeks consisted of meeting people and learning the programs I am to use during my time here. I met the other people in the lab, including Claurissa and Hiba, who are also participating in the Distributed Mentor Project. The two main software packages that I am learning are Alias|Wavefront's Maya and Curious Labs' Poser. In Poser I animated a woman who sits down on a box. In Maya I followed tutorial one to create a bouncing ball.
Click on the picture to see an animation of the bouncing ball. Please note that the file size is 294K.

Week 3
This week I am still learning Maya and have pretty much got the hang of Poser. I am working on tutorial two in Maya to create a jack-in-the-box. In Poser I am animating some figures to place in the model of the Olympic Village. An ongoing problem is trying to figure out how to transport files from Poser into Maya. Hiba and I are both working on this. We have tried exporting files from Poser, importing files into Maya, and looking for plugins that will do the job. While we have found a way to import still objects, we have not found a way to import animations. We will continue searching for the answer.

Update: We had a meeting late this week where we discussed more in depth about the project. It turns out that I do not have to import the animations into Maya after all. Instead we will be using another program, World Tool Kit by SENSE8, and importing the Maya and Poser parts separately. Now my job is to figure out how to import the animations into World Tool Kit. There are a couple of ways to go about this. One way is to import the geometry of the objects (people in this case) and reconstruct the animation through the World Tool Kit functions. My main concern with using this method is that if one part of the body is moved, say the lower arm, will it stay connected to the rest of the geometry, or will there be a gap at the joint?

Unbent arm

Bent arm

Bent arm with gap at elbow

The other approach is to import the geometry of every frame individually and switch them out frame by frame during the animation. The problem with this approach is that it is taxing on system resources, specifically memory. The objects that we are dealing with are fairly large and complex. To utilize this method we would have to significantly simplify the mesh of the imported objects.

Week 4
This week I am learning how to use World Tool Kit. I am writing a program to test how it handles joint rotations. World Tool Kit (WTK) contains functions for creating movable node heirarchies. Think of a robot arm consisting of a base, upper arm, lower arm, and hand. If you rotate the upper arm, then the upper arm, lower arm, and hand will all move as one unit. If you rotate the hand, then only it will move. If you want to move the whole arm from one place to another, you only have to move the base. Thus you have a heirarchy (base -> upper arm -> lower arm -> hand) of movable nodes, which is useful for modeling human joints. My goal in writing this test program is to see if there will be gaps in the joints when you bend them.

I am also reading some papers on simplifying geometry meshes. If we can shrink the geometry of our people enough while still maintaining image quality, then the geometry frame switching method described above may be the best avenue to creating smooth animations. An added benefit of using this method is that we will not have to translate the animation from Poser to WTK, since the geometry and positions of each object will be exported frame by frame into a format that WTK knows how to handle. Using the other method requires importing a single object and translating the animation information in the Poser file (for example, bend the lower arm 2 degrees in this frame) into functions understandable by WTK.

Week 5
After working with World Tool Kit for a while, I have decided that trying to reconstruct the animation using WTK functions would be very difficult and time consuming. It would require morphing the mesh every frame so that the parts would stay connected when rotated. Even changing the placement of the pivot in WTK is not the easiest of tasks because of the way their scene graph heirarchy is set up. So it looks like node switching is going to be the best method to import 3D animation.

In the mean time I am also working on importing animation into WTK as 2D. Basically, every frame of the animation in Poser is saved as a separate image file. Then, a polygon is created in WTK to act as a sort of "billboard." The image files are used one by one as textures on the billboard, creating a flipbook animation. In essence it is the 2D version of the switching node method. While this method is more memory efficient, its main caveat is that it does not allow a great deal of flexibility for viewing the animation from different viewpoints. In our projects the animations should be far enough away that this won't be a big problem, but it is not very general.

Week 6
Work has continued on the importing 3D animation problem. The major holdup right now is simplifying the geometry. Most algorithms require that the mesh be made up of all triangles, so I wrote a program that takes a .obj file and turns all of its polygons into triangles. It works for polygons of arbitrary size (the largest one in the files I converted had 17 vertices) as long as all of the angles are convex. Now the problem is finding a usable algorithm. We found a publicly available one, but it does not accept the .obj file format. If we wanted to use it, I would have to write a program to translate the .obj file format into the program's file format and then another program to translate it back to .obj format when the simplification is done.

On the 2D animation front, things are going more smoothly. The flipbook method works very well. I have implemented it on a still polygon and also on a polygon that moves along a path. The reason the polygon moves along a path is because the animation shows a man walking in place. When the polygon moves, it appears that the man is walking along the path. The only problem with the 2D animation currently is transparency. Ideally we would like the background on the images of people to be transparent. That way when they move around, the user would see trees in the background instead of a black rectangle.

Week 7
So, this week went very slowly. I did more work on animation and modeling and less work on programming. There are some big, decorative rocks in the Olympic Village, and I set about modeling some of those to go in my animations. I also improved some of my existing animations. Our mentor wants us to demo our animations and stills, and that's why the work focus shifted to them this week.

I also got to be a subject in a research experiment where they paid me in Sprite and chocolate chip cookies, but I'm not allowed to talk about it.

Week 8
This week was a success because I finished some tasks that I had been working on for a while. First I finished the demos of my animations. They turned out really well. Secondly, I finished a program that I had been working on for several weeks. It should have been an easy program, but I was having terrible trouble with pointers. Finally with help from several people in the lab, I got it to work properly.

In addition I continued my work as a subject in part two of the research experiment. This time they paid me in Sprite and fudge cookies, but I'm still not allowed to talk about it.

Week 9
Well, this week I went into hyper-working mode. I think it's probably because I know there is only a little time to finish what I have to do. I added some more functionality to my program. It is not actually a stand alone program but will instead be a header file containing some functions and a struct that I have written. The purpose of these functions is to simplify the task of importing 2D animations into World Tool Kit. The main function is the one that actually loads the images for each frame of the animation into WTK's texture cache. The other functions that I have added include one for flipping to the next frame in an animation, one for deleting the images from the texture cache, and one that frees the memory which was dynamically allocated for the struct. The struct contains the filenames of each frame of an animation, the total number of frames in that animation, and the current frame the animation is on.

The other thing I did this week was to test the 3D geometry switching method in WTK. The test was done without simplifying the geomtry, since we never found a suitable application. As predicted, the result was as slow as molasses, switching about one frame every 3 seconds. So it looks like we will continue to do the project using 2D animations. The results we have gotten using the 2D animations so far have been very good. For the purposes of this project, then, I will agree that the 2D method is the best one for animations.

Week 10
Final week. This was my week of finishing up. I tried to finalize my animations and stills, positioning them in the village scene and fixing the lighting and camera angles to correspond to those positions. I also wrote my final report, but I won't be able to edit it with the recommended changes until after I get back from SIGGRAPH. Finally, I completed my documentation. It was long and extensive because it has to be as complete as possible. So that's it. It's off to SIGGRAPH and then back to school!