So far the terrain has been colored using a half-baked scheme I cooked up at the beginning. This system was intended to be temporary, until I can use proper texture mapping.
If you recall, here is how things look now:
The surface looks bland because it doesn’t have a texture. You can think of it as the grassy areas being made of this:
Intead of this:
The latter is far better because it will look more interesting. But… in order to use textures, you need to blend them together. Some polygons will be grass (as above) and others will be dirt:
And it won’t look right to have a hard line between them:
Instead, you want to “transition” from one surface to another, sort of like this:
My first solution was a failure. My thought was to render the entire terrain first as grass, then render another layer over top of it using the “dirt” texture. (Polygons that didn’t have any dirt would be left out.) Imagine you’re painting a wall. The left side of the wall needs to be red, and the right blue. You paint the wall solid red, and then paint over it again in blue paint, laying the paint on thin on the left and making it thicker as you go right. When you’re done you’ll have a nice smooth gradient from red to blue. Obviously you’re painting the wall twice, and the second coat is a lot more difficult than the first.
I implemented this, and it more than doubled the number of polygons the program had to draw. Worse, the extra transparent layers were much slower than drawing opaque polygons. And finally, if you remember back in Part 3 of this series that my program cuts up the terrain into triangles. The closer you are, the more triangles you get. Well, the changing shape of the polygons underneath didn’t look so bad using flat color, but when using fading textures as I just described it looks terrible. The patterns of textures fading into each other would shift whenever the viewpoint moved around, which was very distracting.
So the system looked worse, was slower, and was also a lot more complex. After investing some time into this, I concluded the entire idea was flawed and unworkable. Time to start over.
After giving the problem a lot of thought, I’ve come up with a different way to handle things. First, I break the terrain into seperate areas. (This was done back in part 4, to solve the stuttering problems I was having.) I call these parts “zones”. Here, I’ve rendered the scene with each zone a different color:
For each zone, my program will create a special texture just for that zone. It puts all of the transitions and fading into this texture. Going back to the wall-painting analogy, this is like making a big piece of wallpaper with the red-blue fade built in. The wallpaper will ONLY work on this wall, BUT it can be slapped in place just as quickly as a single coat of paint.
I can spend as much time on this texture as I want. Intead of simplifying the pattern, I just draw all of the fading for every tiny little polygon in the zone. After all, wallpaper takes the same length of time to put up no matter how simple or complex the pattern is.
Here is an example of one of the textures it makes:
It will then slap this over the intended zone. The results are stunning:
I’m back to rendering each polygon only once. This system is simple. It doesn’t hurt framerate. It does have a few disadvantages, though:
- It takes a couple of seconds to create the textures at startup. If this were a game, this would contribute about 2 more seconds to the “loading screen”.
- These textures use quite a bit of memory. I’m using 64 of them, and at the resolution I’m using now they will eat up about 16MB of video memory. That is acceptable by today’s standards, although I do need to keep an eye on this.
- The ground looks blocky in close-up. Check it out:
Again, this is not a deal-breaker, since one of the original goals of this project was to make terrain that looks good from above and not close up. Still, I’d like to have done better than this. I can make it look better by using higher resolution textures, but that will up the video memory useage from 16MB to 64MB. This is still acceptable, but I want to see if I can come up with any more bright ideas before I use the cudgel of more CPU and memory. I’ll have to give this more thought.
I’m happy with how this turned out. I know I said I wasn’t going to prop up the engine with a lot of makeup, but I can’t resist adding one shot with fog enabled:
This is starting to look pretty nice.
The Strange Evolution of OpenGL
Sometimes software is engineered. Sometimes it grows organically. And sometimes it's thrown together seemingly at random over two decades.
A screencap comic that poked fun at videogames and the industry. The comic has ended, but there's plenty of archives for you to binge on.
A horrible, railroading, stupid, contrived, and painfully ill-conceived roleplaying campaign. All in good fun.
The Gameplay is the Story
Some advice to game developers on how to stop ruining good stories with bad cutscenes.
Mass Effect Retrospective
A novel-sized analysis of the Mass Effect series that explains where it all went wrong. Spoiler: It was long before the ending.