This is a project I had started while I was in college. It's a level editor for my first "game engine" (before I knew what an engine should look like).
It had begun as a personal project during the summer, and some of my peers had joined in to use it as a group project. After the project had been submitted and graded, I continued to add features to it.
In the video, you'll see me load a terrain from a heightmap and set it's textures, set up some simple lighting, add a few objects (some with key frame animations) and move them around, and play a bit with some water settings.
Some features have been disabled (such as shadows and dynamic lighting on water), since they had been acting strangely on my newer hardware...but that's only interesting to know if you were already aware they existed.
This week, I thought I'd talk about the terrain in Elpis. I like terrain! Terrain is nice!
Also, an afore warning: this post is likely to transform into a musical featuring Julie Andrews...
Implementation of Choice
The terrain implementation in Elpis can be found in an article in Game Programming Gems 6, titled "GPU Terrain Rendering" by Harald Vistnes (Chapter 5.5). Seeing as the article in the book articulates the technique far better than I could, I will not be describing the method in detail. I will, however, skim over the implementation and record any modifications I plan to make and eventually how I intend to make them.
The general idea behind this algorithm is to provide a high detailed terrain while keeping memory and CPU requirements low, and pre-load time to a minimum. To do this, a small regular grid vertex buffer is repeatedly scaled according to the LoD (Level of Detail), morphed on the GPU according to the heightmap, positioned, and drawn.
Figure 0 - 17x7 LoD/Quadtree
The single vertex buffer used contains a 17x17 patch of vertices. As seen in figure 0, each patch of the terrain is divided into four more patches, which have been scaled to half the width and height. The division is essentially a quadtree.
The denser areas in figure 0 are one level of detail higher than the patch of lower density.
Figure 1 - Terrain
Figure 2 - Wireframe
The heightmap and normal map used for the terrain in figure 1 and 2 were borrowed from Game Programming Gems 6's CD-ROM.
Figure 1 shows the terrain in solid render mode and figure 2 is rendered in wireframe mode. In figure 2 we can see that it is a regular grid terrain implementation and there is a clear separation between terrain patches. Along the edges of each patch, skirts are generated to cheaply and effectively eliminate cracks that occur when mixing LoDs.
Feature Lust
It is a very good terrain rendering algorithm, but the article was kept intentionally simple and featureless for ease of comprehension. For instance: it is rendered in a single (kind of ugly) colour; lighting is static; culling is minimal; and other lacking features that I can't think of right now, or that I'll describe later.
Figure 3 - Bounding Boxes
Ah yes, here's another! In figure 3, the bounding boxes for a single LoD are displayed. It's plain to see that the bounding volumes were calculated using the minimum and maximum height of the entire terrain (since they are all identical in size and align at the top), rather than that of the patch's height. In fact, the implementation uses the minimum (0) and maximum ALLOWED height (1 * MAX_HEIGHT). The bounding box is currently used for frustum culling, but can later be used for other things like collision detection.
The point of frustum culling is to cut out unseen data as early as possible, to avoid unnecessary GPU work. The tighter the fit of the bounding volumes, the more accurate the incision will be, the fewer useless draw calls are made.
Summary of feature lust: I want sweet colours and textures, fancy dynamic lighting and shading, tighter bounding volumes for frustum culling, and maybe some occlusion cullingif necessary. It would also be nice to use displacement maps for terrain morphing, but I haven't a use for this yet.
Exit
You can expect posts regarding the features mentioned above to pop up every now and again. My next post will be of a more immediate feature that I have made reference to in my first post: Large world support.
Here's a small clip of the terrain in wireframe mode to show the changes in LoD:
Having a full time job and a 2 hour commute eats at your time and soul, but with the little time and energy you have left, you'd really like to build a game from scratch (for learning purposes as much as pride). A huge task by anyone's standards. So to get the most out of your time and to keep you from being reminded that there's a world outside, you'll need to do away with all them distractions and get some clairvoyance spells... or something. But enough about you, let's talk about me!
First thing's first: If this kinda-too-large-for-one-person project is going to succeed, I need to be the project manager, designer, director and hero (coder). Oh, and I need to cut the reddit feed from my iGoogle page before I hurt myself. [+3 productivity].
To keep me from hating life, I like to squeeze in some gaming and reading into my week [+4 happy].
I can read novels during my bus ride commute to work (and thanks to ebook readers, I can read any sloppy romance novel I please without the judging glares of those who sit near me!).
Since I must, I've allocated a small portion of time to the habits that make me go 'huh? where did the time go?!' (ie. Facebook, Reddit/Digg/etc...), but one of my eyes is fixated on the clock at all times.
Break it down! (-stop, Hammer time)[+4 focus]:
Identify the high level idea of your final product (game story, game type, game play, blah blah). Completing this game is the long-term goal.
Break it down some to get the features you'd like to have in the game.
Break the features down and gather all the components you think you'll need to make this work.
Select the most important components/systems for your game (I deem this Phase 1 of the project).
Ok, so I know what I want from my game, now all I have to do is skip sleep and finish it before the sun comes back up! Wait, I have a better idea...
Gonna' manage ma time! [+3 focus, +4 productivity] :
Set milestones for each broken down (reasonably sized) iteration or phase. I try to split up the tasks into 2 month iterations, but that is just my preference.
Using a ticket tracking system (I've been using Trac), I've placed a bunch of "feature request" tickets under the current milestone target for each major feature I'd like complete. The goal is to complete all of these feature requests before the 2 month period is over. This is the mid-term-ish goal.
Using a project management application (Example: OpenProj or Microsoft Project), I've estimated the amount of time to complete each feature. I've over estimated each by approximately 2.25x, in order to give me time for any hiccups. Ideally, these features should add up to the 2 month period milestone (I add more features to the list if I don't anticipate many complications, but I could instead set the milestone date to the estimated end of features date). This is the short-term goal.
Each day, I list the small portion of the current feature to cram into my daily TO-DO list to accomplish the short-term goal, which will accomplish the mid-term-ish goal and hopefully, eventually the long-term goal. This is the immediate goal.
Now that all this project planning is behind me, all I need to worry about is the immediate goal and I'll have a game in no time! [+3 happy]
Summary (tl;dr): To keep me focused and motivated I start from the end goal and then break it down into smaller chunks until my puny mind can comprehend the task at hand, and eventually my long-term goal will be realized.
