Game Garden / Animation Blending

This quarter I came in with a bloated head. My expectations were high to push myself, even when they were cut back after half a quarter of struggle. Looking back at my project proposal I can’t believe I did this to myself. After a few days of watching particle effects presentations, over, over, and over, I felt I was over-shooting what was needed to pass with flying marks. Then I remembered, I’m in a competitive market and it’s great that I’m pushing myself more and more every quarter to meet the bar of commercial computer graphics.
From the get go I was trying to get started as early as possible. My first objective was to setup the data-driven environment and collision detection system. You saw this in the billiards project. This introduced the EnvironmentParser, EnvironmentItem, Object, Physical, Anchor, and environment.txt architecture. The way it worked is that several files were referenced in the environment.txt file and were of two types, Physical or Anchor. Physical objects were dynamic that had mass, velocity, and gave off forces. Anchors made up the scene used to describe unmovable environment such as the ground we stand on. The idea was that these would be linked by the Object class have different collision qualities and update functions (if they had them at all). I also made shape privatives that would make up the structure of the items being drawn in the environment. These ended up being MPolygon, MSphere, MBox, and Shape. The ‘M’ prefix was to stand for model, though they didn’t end up getting used much in the final project submitted.
With the framework to build upon, I pursued creating the structure of the model, the script to read in the model, and the technique for moving from one animation to another. It was then that I hit a rut that took weeks to get out of from. The first problem was how I build the model. If I were to use a data driven model I had to pass data all the way to the end effectors. If I were to use a tree I would get an ugly traversal that would make back talk a pain. Instead I opted for a map for quick access and elegant data handling via one master class for the entire model. The second problem was how I was I going to get the model to move from position to position, animation to animation smoothly? Inverse kinematics had an appeal from the start because of their recent use in videogames. Though its traditional implementation, which uses the Jacobian matrix, was trashed due to my underdeveloped physics and the lack of need for something so complex.
I then was directed to a paper on a fast inverse kinematics system built for real time (see my response for more info). It provided a method of building the skeleton out of normalized segments, splines, and variable length segments that contain a one-degree joint such as legs and arms. Using this skeleton, I created the BodyPart, Limb, Joint, and Hinge classes and started on my scripting system. The abstract class body part requires an axis-angle direction (theta, x, y, z) and an id tied to it. Limb added a scalar for length, and Hinge extended Limb further with a sub-length and scalar value for extended and closed. This allowed me to break animations into stances built by sub-hierarchies, and even allow me translate in between them with a simple quaternion slerp. Finally the individual animations were simply described as a list of stances. I marvel at its simplicity and effectiveness.
The animation was only half of the assignment. The way this all fit into the game theme of the project was that these animations are a result of a state based. The idea was to describe the different verbs of the active avatar and use an identification to access the correct animation. This is the part that needs the most work. I used a hack of a collision system based upon boxes of four points. Player control was poorly implemented, though the running and jumping controls feel pretty good. This is where I plan to expand upon next. I want to take my effective animation system that I built from the ground up and prepare it for a more defined script that I hopefully could churn out levels, new models, to even being integrated with a GUI to make a full fledged tool. The shortcomings of my near-sighted implementation did not allow me to make my character to wall jump (result: upward teleportation), or do the rocket burst I hoped so much to get into this demo.
Ultimately I have put my all into yet another project and learned every step of the way. That is how computer graphics should be learned, by just doing it. So, in conclusion, I have succeeded. It didn’t come easy, but there is much to learn and much to do to get where I would like to be. I just await the opportunity that will let me add textures, and graphical models around my different limbs. The more I learn the closer my game’s existence is getting.