So I've decided to pick Height Field Terrain and Level of Detail for my project in class. I originally started the class with a desire to learn a lot more about terrain rendering anyway, so this seems like the perfect opportunity to do so. If it's easy, I'd also like to do a seamless, streaming world, but we'll see. My time this quarter is severely limited compared to last quarter because of work getting a lot busier, so I have to really cut my expectations for what I can do in class. C'est la vie.
Anwyay, part of my initial research this quarter was looking into using a third-party engine instead of writing my own. I've learned a ton from writing my own engine, but it's also been a lot of work, and so I was thinking that it may be a lot less work to pick an engine like Ogre, Irrlicht, or Torque and rewrite my current game in that, then add the new stuff for this quarter. I spent a couple weeks evaluatiing engines, going through all the tutorials, writing little sample programs, and poring over all the documentation as well as digging into the source code.
I ended up deciding to stick with my own code. I'm a bit surprised by this as I was really hoping that using another engine would really speed up my development. But, I've thought about it a lot and really decided that, for now, with my current time constraints, it really does make more sense to stick with my current code base. In any other engine I looked at, it would take a minimum of a few weeks to get my current game working the same (none of the engines had the shader support I was looking for, and their architecture was different enough that it would take a fair bit of rewriting to get things working again). In addition, as I looked through the source code, I just plain didn't like a lot of the things I saw. The underlying math libraries were inefficient in many cases, the SceneObjects (or equivalents) were extremely heavyweight, there were mysterious memory leaks reported by Visual Studio and Memory Validator but were not believed by the library creator (though it's likely the library creator was correct in that specific case, it still made me extremely nervous), etc.
The time spent was extremely worthwhile, however, and I got a ton of good ideas for expanding my own engine. Someday. I even started writing a features list that I plan on implementing (someday) much like Irrlicht has done. There were lots of good things about all the engines and many good ideas I'd never thought of, so it was very useful to mine the code like I did. If I was planning on a longer-term project (instead of the next month and a half or so), I would probaby bite the bullet and dig in to using another engine as their feature lists are all much bigger than my current list and they have a lot more man-hours of work put into them. There are definite tradeoffs to doing so, but it would probably be worth it if I wanted to spend my time writing a game instead of writing an engine.
For now, though, I think it's probably more useful to continue with my current codebase. I'm still learning a lot from doing engine code and I think I'll spend less time getting the assignment done using my current code than I would starting from scratch with a library.
So, for the assignment, I'm thinking of trying to implement Geometry Clipmaps. It's a fairly new method for terrain-rendering that seems to be very efficient. I've read the paper and can tell it's going to take several readings to really digest it. There's an article in GPU Gems 2 about it where they implement part of the algorithm in the GPU, so that might be worth getting the book for. There really doesn't seem to be any example code out there that implements it, so I'd have to just go from the paper. Not necessarily an easy task, but doable.
If anyone knows of an implementation I could look at for reference, I would greatly appreciate it.
