Due to a fairly busy week, I haven't really gotten a chance to write an update about the work that was done on Rawr over the course of the Labor Day weekend, so here is this update. Progress on the framework may be a bit sporadic now that I'm doing some part-time journalism for a little-known gaming site (podcast, columns, and the occasional review/preview) for fun, and I'm also taking my final class at the University of Michigan while working full-time... So things are a bit busy right now. But, anyway, for the update.

I faced some issues when I was attempting to render the terrain with multiple different levels of detail, which was to be expected. Though, one of the first things I realized was that my idea to instance the blocks hit its first, ahem, roadblock when I realized that I couldn't just create one vertex buffer and one index buffer, and then just send the index buffer a stride for rendering different levels of detail; that was easily remedied by creating an index buffer for every level of detail; this wasn't too hard to work around, it just meant that I had to keep the instance buffers dynamic so that I didn't have to swap various instance buffers in-and-out as needed throughout rendering; so, whenever there is a change in the overall grid LOD, the instance buffer needs to be rewritten to encompass the block LOD data. So, yeah, here's some completely mixed-rendering screenshots which have no real method to determining the grid LOD; these screenshots were rendering at a solid 300+ frames-per-second for a 1024 vertex (at its finest detail level) grid.



After I got that handled, I held off on the crack-fixing shader code so I could work on a different task for a couple days; since I was tired of the giant zombie always being in its AF pose, I shifted my attention to reading in and rendering the MD5 animation files for each mesh. The first task for this was, instead of manually loading in every MD5ANIM file in a mesh's folder was just to give the class an option to automatically parse the folder for every MD5ANIM file present and just load it in for the mesh -- this has the unpleasant quality of not having any specific animations for any specific actions, since there seems to be no common naming scheme for all MD5s, though. It's a simplistic approach for now, but when I add some functionality in the framework for reading in XML files, I may just write-up an XML file for every mesh and then get the animation information (to keep a consistent set of indices for specific animation types) from that. As you may be able to see below, the skeletal animation isn't quite there yet.