As time has gone one, I have been able to successfully support multiple textures per model! This is really important because my original model code did not look so good... What had to be done was re-organize all of the 3D data the model after it had been loaded from the original .x file. Then, I would take all of the meshes found in the model, and combine all of their data into one unified mesh. The next step would be to build triangle lists from the mesh by material associated with it. I use materials instead of textures since the .x file stores the texture file name information in the material information, and so, that is how I store the information in my code. Plus, if I decide to add material support later on, it's easily possible, but for now, I will not waste time on it since it may be pretty slow.
After the triangle lists are built, I split the unified mesh into an array of meshes --one for each triangle list that was just built. Then, I use that index information from the triangle lists (now located within their respective meshes) to grab the other vertex and skinning data from the unified mesh.
Another positive outcome to this is that I can specify my vertex format either automatically based on the vertex data found in the file, or manually during the loading process. That way, I can do benchmark tests on the same model data with different vertex formats!
I refer to this entire process as "compiling" the mesh. This process takes about 30 seconds to complete after all of the data has been allocated and loaded from the ~4,500-vertex model file originally on my laptop. I have not tried this on the iPhone, but it does take much longer to load files on the iPhone than it does on my laptop, so compiling these models in-game would be bad!
To get around this, I created my own model format that is based somewhat on the .x format, but the format really follows how I store the my model file in my program code. I call this format .OX format (optimized-X format). Since I only work with text-based .x files, parsing the data is slow and causes my files to be pretty big. My .OX format is completely in binary which cuts down model data to about 1/4 - 1/8 of its original size!
Even though my .OX file contains some animation data, it would be very inflexible to store any animation data other than the model's skeleton in the .OX file, so I decided to store animations in a separate file format called the .anim format. I know, it's not that original :(, but it works, and it loads fast on the iPhone too! Another plus is that now, I can store multiple animations within the same file by treating these .anim files as archives which can be used by multiple models provided they have the same or similar skeleton configurations!
My code that stores, loads, and manages the .anim file format also allows me to trim out uneeded animation keys and animation bones. This is great because I have interpolation code to process my animations, so why bother storing every single keyframe of the model's skeleton as my exporter seems to do? Also, my .x exporter seems to store animation data for every single frame in the model's skeleton. If I wanted to have a running animation and a shooting or reloading animation play at the same time for a first-person shooter, it would not work out correctly and be slow because both animations have information for the bones they should be be influencing. So, I added a tool to trim any uneeded animation frame data... It works well, and it cuts my animation data down about to about 1/13 of what it was originally!
Now that I have finished my rant, I would like to demonstrate the results of my efforts:
This is actually running on my 2nd Gen iPod, and was recorded with my iPhone 3G-S. The framerate is a bit slow --19 to 21 frames per second which is not good. The soldier model is about 4,500 vertices, and the windmill is about 1,500 vertices. All of them are skinned vertices as well which means there was a lot of software matrix-vertex multiplication involved when skinning.
I hope to get around this issue by adding ASM implementation for my matrix-matrix and matrix-vertex multiplication algorithms. Also, the vertex counts per mesh are quite large. I have a few models on the way that have about 11 times less vertices than the soldier model, and it looks just as great! I also haven't implemented by frustum culling algorithm in this demo, so the windmill is constantly skinning --even when it is off the screen. I have fixed this since then though!
All in all, if I can get my ASM implementation added and an effective octree rendering system put in place, I will have some really powerful code to work with on our latest project. We will have full-3D, lush environments in our next game. I'll admit it, Blitz Blok was rushed during its planning phase, and in fact, it did not have a planning phase, so it has not been as successful as I have hoped. However, this code I have been working on for the past 2 years, and the help of a couple of modelers will prove that simple arcade-like games just aren't quite our style. We need something with a little more depth... an RPG maybe... For the iPhone OS platform.
No comments:
Post a Comment