   huge terrain rendering
  I''m currently building a flight sim (www.web-discovery.net), and i actually use a 2048x2048 raw heightmap to generate the terrain to fly over. To keep a decent detail, the map is covering an area of about 30km x 30km (or about 19mi x 19mi), which is covered in less than 5 minutes of flight.So, before i can have missions of about 30 minutes, i need to find a way to have a much larger terrain.I know it''s not possible to load a whole heightmap of about 12288 x 12288 pixels (i.e. 6 times what is now), so perhaps there are other sort of solutions.Maybe loading dynamically terrain from disk ? But how do i deal with 6 heightmaps ? When i approach the end of the first area, i should load the second from the hard disk, and it would take a considerable time and loss of performances.Any suggestion is greatly appreciated. Thx
  You could do:1 Divide the terrain into smaller portions (loading time will be a lot less).2 Is it really that impossible to load a 12288x12288 heightmap ? ;  Make a kind of frustum culling algorith and load only the parts of the map you can see in memory. Split the terrain in 256x256 or 128x128 heightmaps and load them if the frustum is near that part of the map and unload it if it''s to far away. Make a cache program for it.;  that is what you are gonna have to do.but i would consider this....break your 2048x2048 down into something smallerlike maybe 512x512 at most and at all times have at least 9 of these sectors loaded in at one time, the sector you are in and the 8 immidiately surrounding the one you are innow when you are drawing, you generally only need to draw the sector you are in....but as you approach borders of sectors then you need to draw the one whose border you are crossing which is why we keep the 8 surrounding sectors already loaded in...now when you actually fly into this new sector you need to make it your current and load in the 9 surrounding that one...although some of them will be the same as ones already loaded in so it wont really be loading in 8 new ones but loading in maybe 4 new ones and moving some pointers aroundsee pic below123456789// you are in the 5 sector with the 8 neigbor sectors loaded in// now you fly to the right into sector 6 so update your// neighbors23A56B89C  so now you are in sector 6 but you only really loaded in 3 new sectors (A, B, and C) and just updated which sector you are inso this way you use much less memoryif sector sizes are like 512*512then you use about 9MB if you use floats for storage of the heightsyou could bump that down to 2.25 MB if you can use just one byte to store the heightthat is of course not including memory for textures but for just the terrain data itselfbut then if you use sector sizes of 256*256 then you use about 2.25 MB while still keeping floating point precision.so the smaller your sector sizes are the less memory you will be using.but dont make sector sizes so small that you need more then 9 in memory at one time.  like if you can see "5000 meters" away..dont make sector sizes that stretch for "1000 meters" or you will need more loaded into to cover the drawing area.now when you cross into a new sector and need to load in the new neighbors, create a separate thread to load them in and keep the main thread keep on going with the game "A soldier is a part of the 1% of the population that keeps the other 99% free"  - Lt. Colonel Todd, 1/38th Infantry, Ft. Benning, GA ;quote:Make a kind of frustum culling algorith and load only the parts of the map you can see in memoryargh, no! not with the view frustum! the lag would be horrible, you can (even in a flight sim) turn around much more quickly than go from one terrain zone to another.what ncsu121978 said seems pretty good, and I currently use a similar method (not for a flight sim, but the "terrain" needs to be quite huge too, with a high enough visibility range).basically, have two vision range (so that could be represented by two circles surrounding the player).when a zone enters the nearest circle, load it, when it exits the furthest circle, unload it.the second range should be slightly bigger than the first one, this is to avoid load/unload flickering when you are right on the load/unload point and you move from one side to another.here are some pics to illustrate that.clicky!clicky^2note that the outer range is voluntarily exagerated, for the sake of clarity. in reality, it would be much smaller, but that depends on your travel speed. you can take a step further and make the two ranges completely dynamic, and adjust the delta between the inner and outer range depending on your travelling speed...hope that helps (btw, on the screenshots, each cell is 8.192 Km wide)EDIT: ncsu121978:quote:so this way you use much less memoryif sector sizes are like 512*512then you use about 9MB if you use floats for storage of the heightsyou could bump that down to 2.25 MB if you can use just one byte to store the heightthat is of course not including memory for textures but for just the terrain data itselfbut then if you use sector sizes of 256*256 then you use about 2.25 MB while still keeping floating point precision.that's pretty optimistic... that data could only be used as is for collision detection, or by a voxel renderer.you need 3 coordinates per vertex, that's already 4 * 3 * 512 * 512 ~= 3Mb just for the vertices.add triangle information to that. (assuming you use ushorts (split your terrain in 256*256 chunks) and tristrips), that's (2*256 + 2) * 255 * 2 * 4 ~= 1Mb of indicesadd to that 2 texture coord arrays (2 * 4 * 2 * 512 * 512 ~= 4Mb) and one color array (let's say rgb, not rgba, so 3 * 4 * 512 * 512 = 3Mb), and no normals if you use a normalmap for the lighting, that's already 11 Mb per 512*512 chunk. if you've got 9 chunks it'll take around 100 Mb...you could use vram to store some of these, but anyway, it's still huge. you need to subdivide further each cell, and only load LODs as needed, I think this would bring down memory a lot.   [edited by - sBibi on February 14, 2004 3:55:04 PM];  "Lazy caching" helps too: Request a load of a subsection when you get close to it. The loader will walk through its queue and load some of the current subsection every frame. When a subsection is finished, it''s given to the engine and it starts loading the next subsection. This can help with automatic LOD too (the loader will start processing a chunk it has just read and not share it until the LOD-calc is done). The amount of work to devote each frame can be taken directly from the FPS. ;  There is a terrain generator plugin for Milkshape on the parent site, maybe when you are in the vicinity of the next sector just show the next model and unshow the one when you leave it............... ;  Thank you for all your suggestion guys ! I think you clarified most of my doubts !    ;  I''m reading up on different methods of rendering huge terrains, and like most people I have equally huge dreams. One thing that I haven''t really worked out is how to store large terrains like this. If I for instance want to create a game where the hero is free to walk everywhere, how could I create and store a massive world without releasing the game on 15 DVDs? ;  Duplicate the world every so often, if it really is that big the user will have forgotten they saw it............. 