Wow, it's been quite a while since I last blogged, I guess my excuse would be midterms and my internet being out for two weeks, but mostly it's just me forgetting. Anyways, let's get down to business.
I remember mentioning a while ago that I wanted to implement a better animation system in our game that can support multiple blend poses (secondary and primary poses), and for the most part, I am done this system now. It works fairly differently than what we had implemented before. What happened earlier is that all the animation system would do when called is set what the next pose would be, and let the drawing function for each raptor determine the actual positions of the vertices & normals that correspond to the model. Each raptor would call this drawing function one at a time, and all of the code used to be in main, and it looked fairly ugly. The new system takes up a bit more memory, but I hope it proves itself to be more useful and flexible down the road. This new system, first of all, cleans up all of the animation code out of main, and in a special function in RaptorClass that gets called by the player and each raptor AI. I have an OCD-like tendency to clean up main as much as possible, and seperate everything into classes. Unfortunately this is a luxury when trying to code something up really fast, and this is the reason why our original animation code was all over the place. RaptorClass also recieved a couple of new member variables. One of which is fairly huge, which is an ObjLoader object. There are several huge arrays for storage of vertex/normal/texture information, and I'm not sure why they are this way. Apparently messing with the max values completely screws up our texturing, and sometimes our normals. I have a suspicion that not all the arrays need to be that huge (10,000+ max size!!!), and that only one array needs to be big enough to store all the information related to faces. I don't know though, I'd have to bring this up at the next group meeting. The other variables are pretty insignificant, and are just integer values.
One new function was written to take care of just the interpolation. The theory is that instead of drawing the object as soon as you interpolate it (our old system), you do all of the blending in one place multiple times to achieve in-betweens of different poses and store that in memory. All you'd have to do in the render function is just to draw the information that is in the variable stored in the RaptorClass (our new system). I'm hoping this will be somewhat more efficient, because the actual math is all being done in one place, and in bulk, separate from the drawing.
A pretty significant downer I did not anticipate though, is that when blending multiple poses together the latest pose often takes precedence. This produces a result that looks almost exactly the same as the previous animation system. Maybe it's just the way I'm blending, because the theory sounds to be correct.
I may tweak the code in the future for the animations to be more dynamic. Right now, I'm going to try to focus more on shaders, getting a proper HUD to work, our very simple 'level creator' or maybe trying to fix textures (using PNG's instead of BMP's due to size issues).
No comments:
Post a Comment