I've been playing Dark Age of Camelot for a couple of weeks now, and I've been trying to figure out (with my meager knowledge of game programming) how the landscape is implemented. I'd appreciate it if anyone could help me speculate. One nice thing about this game is that all the textures are in separate .tga files. A couple of other files are exposed as well. Take a look at this screen shot (300Kb). I think that's obviously a heightmap. One texture file I found, which was by itself in a conspicuous place was this one (200 Kb). So it seemed to me right away that this texture is used for the whole landscape. It would be very economical to use this same texture for grass, dirt paths, snow, etc. You could just assign different colors to the vertices to get the texture to be the different colors. But if you look close, you'll notice that that's not all there is to it. There are blotches of color that could not have been formed by simply using vertex colors. So I don't know how this is done. I assume it's some kind of layering of textures. But that would mean you'd need a lot of these second-layer textures because the blotches vary a pretty lot. So this presumed layering is the biggest mystery in my mind. I haven't found any textures that look like they could be used for this layering effect. You'll also notice that they use actual polygons to do the clumps of grass. These seem to be randomly placed. In fact, there is a text file that can be loaded into Excel that is a table of percentage chance for different types of grass. So I figure that these are placed randomly for that reason, and also because it would take too much room on disk to keep track of their location and it would be too tedious to place them during design. However, I noticed that the placement of clumps does not change when I exit the game and restart, so I assume they are seeding the random number generator the same each time. One thing that limits the possibilities as far as the landscape implementation goes is that this game really doesn't take up much disk space and the landscape area is very large. Based on the subdirectory layout, I'm pretty sure that all landscape data is kept in files with a .mpk extension. The size of these files total about 113 MB. If you assume that the heightmap points are a meter apart, and that each point is two bytes (one for height, one for palette color ?) then the map is about 7k x 7k meters square. It very hard to estimate how big the world is by looking at it, though. But perhaps this seems about right. However, this data size doesn't leave any data space left over for anything else like a second layer of textures. Any ideas how this is done? Jim P.S. Sorry I don't know how to put links in this message board. P.P.S Now edited with the links fixed. Edited by - JimH on November 19, 2001 3:40:58 PM

They may have used a two-pass technique, with one large low-res texture of the terrain and another high-res detail texture that is tiled (that grayscale one).

The blotches are most likely the product of detail textures blended with the terrain textures. They''re most likely generated procedurally using some noise function, so they don''t need to be stored on disk.

I believe they are using a tiling system for texture mapping, and heightmaps. The link to the second image you posted really looks like a detail texture ( noise function ).

Y.

Ah, I think I get the general idea. Since the terrain colors come from a large, low-res bitmap, the smallest blotch of color would be one pixel in that bitmap. This bitmap would need to be blended with the detail texture somehow and I''m not yet sure how that could be done with DirectX. Specifically, how do you layer two different resolution (or different sized) textures? But I''ll look into it.

It would be nice to find some heightmap code examples that produce something like this, but so far I haven''t come across anything.

What I was doing was making a quad tree with the leaf nodes representing and 8x8 region of terrain. Then for each of these 8x8 regions I would build a vertex buffer and an index buffer. But I''m suspecting another way to go with this is try to build the whole terrain as a single mesh. Then when rendering, each 8x8 region would contribute to the whole mesh. (Of course, each 8x8 region would be reduced for level-of-detail). But I didn''t do this at first because I imagine you''d have to keep rebuilding the mesh every time the camera moved, which doesn''t sound reasonable. As you can tell, I''m still trying to figure it all out.

Thanks.