Archived

This topic is now archived and is closed to further replies.

JimH

Dark Age of Camelot

Recommended Posts

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

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
To put a link in your post, just use the regular HTML anchor tag. Make sure you put the "http://" part though, or it thinks you mean a page on the GameDev.net server (I learned the hard way).

--- krez (krezisback@aol.com)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Here''s what I''ve come up with.
The map is a simple height map, it is divided into chunks (call them 8x8, one could figure this out from examining the game world, but I haven''t)
Each node stores it''s height. (1 byte) nodes are approximate 1 meter apart. Each chunk also has a color map associated with it that is at least twice the resolution. There are a very limitted number of colors(32 probably), and they are stored in a look-up table. In the map file these are also highly, or at least run-length compressed. Even uncompressed our theoretical chunk is only 8x8 (64)+ 16x16 (256) = 320 bytes but you can get a lot out of rle''ing the color data at least.
The same noise map is applied to all chunks when rendering, then the unique color map (generated when the map chunk is loaded) is blended on top of that, single-pass multi-texturing. So the tiling is all done really with the colors, vertices are lit normally and normals calculated at run-time as the heights for a given chunk are loaded.
So basically you''re correct, but the color information is not per-vertex, but rather in textures for each chunk which are created at run-time by filling in a texture with values from the look-up table. You can often find the edges of the chunks where the colors don''t quite blend properly.
maketh sense kinda? blarg,
-m





mat williams
Lead Programmer, Designer
Zero Sum Software
www.zero-sum.com

Share this post


Link to post
Share on other sites