View Full Version : Real time Terrain
10-30-2002, 05:06 AM
How do you manage real-time terrain like in a video game? I can generate heightmaps and textures, but it seems like I will need many hundreds of heightmaps and textures to make a big world like you see in video games. How do they make the worlds so big? Is there a trick to getting a 512x512 height map to make a huge world somehow? Or do you need many hundreds of heightmaps? I've figured out ways to compress heightmaps, by sampling tricks and using bytes, so I can squeeze them down. I have some fast heightmap generators I can do in realtime. My texturing can be done in realtime too.
But the problem is how do you edit terrain to put models on them and such? You need a mesh of the terrain to do this? I'd like to learn how the pros do this landscapes in games and stuff to make big interactive worlds.
10-30-2002, 07:41 AM
do a search for ROAM (Real-Time Optimally Adaptive Meshes). there's lots of great examples of how to draw fast LOD textured terrain. check here (http://www.gamedev.net/reference/list.asp?categoryid=45)
[This message has been edited by coredump (edited 10-30-2002).]
10-30-2002, 08:12 AM
I know about ROAM and CLOD techniques. I think I need to be more specific.
How do you create *BIG* worlds from heightmaps? I can stretch it out by making my polygons huge by scaling them, but I still only have a 512x512, or whatever size heightmap. I can't really practically create heightmaps bigger than 4096x4096. What I don't get is how to make really big worlds from heightmaps.
10-30-2002, 09:07 AM
A common approach is to use multiple/adjacent height maps. If you create your own height maps you need to insure that the seams (edges between adjacent maps) are identical so that the transition from map to map doesnt get funky artifacts in it. If you use USGS DEM elevation data or DTED elevation data, there is 1 pixel overlap between adjacent cells that you can exploit to do this ... you can safely assume that the elevations on the eastern edge of a map correspond to those on the western edge of the adjacent eastern map. Similarly, you can assume that the elevations on the southern edge of a map correspond to those on the northern edge of the adjacent southern map.
You will probably need to do some sort of caching for the terrain maps in use. One method is to keep 9 maps in memory at a time (the map the camera is currently over plus the 8 surrounding maps). Here you could track the camera velocity and estimate which cells were going to be needed soon and spin a thread to load them into memory.
[This message has been edited by pleopard (edited 10-30-2002).]
10-30-2002, 04:32 PM
thanks! Believe it or not I already thought about trying that hehe!
The big problem is that heightmaps take up alot of disk space and memory. For my 512x512 height map I put it into unsigned chars, which only takes up 256k compared to 1M for floats. And each tile texture is a meg. I guess if I have only 9 in memory at a time it will be all right.
I realized that if I step sample them, I can reduce them down in size alot and still get the same size map. But then I lose alot of details.
Powered by vBulletin® Version 4.2.0 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.