Here's my approach. You have two files lets a bigtextures.dat detailed textures.dat. Now bigtextures.dat is broken up into different maps, and the entire map is loaded into memory once it starts. Detailedtextures.dat is broken up into maps, and map sections. When you approach a certain my section the detailed sections are loaded. Now heres the clever part, lets say your viewing distance is 10 units. it would load 50 units squared into memory, and every ten units you moved, it would load maybe 3\4 of that reducing load times and stuttering.

Really though the ideal approach has already been invented. It's called MegaTexture.

The LOD is vary usefull approach.
Everybody now trying to guess, how do the Black&White game 3D engine works. There was a big isnland, that was wery detailed, when you move camera closer. (:

Bassic idea of lod is simple - you have a 3D object, that finaly consists of verticles/edges/polygons (verticles are preferable) and texture. And you can dynamicaly make the object a little less detailed: it would not look bad from far, but will eat less resources, like memory or rendering time.

Texture LOD usaly (as i know) is just a few precalculates textures, that generated from one hi-detailed. i.e. you have one 1024x1024 texture for a rock. when the "rock model" is loading (in a background, while the camera moves, or in main thread, while all the environment loads) there are some copies generated: 512x512, 128x128, 32x32, 8x8. last copy is only 64pixels and therefore eats almost no memory. you can hold 1 or 2 of that set (include main, hi-detailed) in memory. when LOD is decreesing - more detailed texture throwed away, and less detailed are loaded. if there is 2 textures in memory, you can render it both with a different alpha, to make their switch softier.
the other half is a model itself. there is a ready technology from microsoft (in directX of course) that allows mesh-LOD. the idea is simple - you index all verticles by its "contribution in model". and while LODing the least powerful verticles/edges just removed, the gaps are filed. but (i guess) that needs 2 copy of model permanently loaded - high detailed original and current LODed copy. only advantage, is there is no need to put original in video memory.

in your case the objects is square(in projection) parts of your landscape. in easy way all the squares are equal-sized and forms grid. but you can make (if the landscape is hand-drawed, not generated) some least significant deserts be 4,16,64 etc squares glued together.

and the process of indexing may be like that: four corner verticles are indexed as most powerfull( i.e. index 64535) so your square will apper as real square when LODed down completely, just 4 verticles connected. but will preserve the average angle of object.
After that you may divide curent square on 4 equal squares and make every not indexed verticle in corners of each square like [index_of_that_big_four_aroud_it/2]. and so forth for all 4 new squares recursively.
if the post will interest anyone, I'll draw some paintings to explain.

BUT all the post is pure theory. i've never wrote 3d engines, but want to do it in future. :o
ps: sorry for my english.

Prophile, I think this challenge is now dead. Let's get another going.

Yes please. And I would like some more like these, without code. I'd rather create the concepts instead of the code. I'm a... Conceptionist. (If that is a real word...)

I agree with you. I am one myself. You had a good approach though. However, for the quality of the textures, I would go with with something bove low, but not that high so people could actually see more than just low quality textures of the landscape. (As a viewer, it would be more enjoyable to see more as long as the computer is capable to do it.)

I declare no winner, since nobody even said the word 'octree' let alone advanced paging

I've just read this, and I'm really surprised at how much people missed.

The main performance enhancer would be prefetching of higher detail map sections. The area closest to the player has the highest LOD (maximum particle count, highest texture quality, etc). The further away from the player that a model or terrain section is, the lower the LOD.

Say for example we define 5 levels of detail, LOD_LEVEL_1 through to LOD_LEVEL_5 (where 5 is the highest detail).

The immediate area around the player gets LOD_LEVEL_5 applied. Areas that are a reasonable distance away get LOD_LEVEL_4 applied and even further out from that gets LOD_LEVEL_3. The horizon would be LOD_LEVEL_1 (minimal texture quality, few/no particles, simple lighting, reduced polygon count models, etc). We mask off the low quality of distant quality with a bit of blur, bloom or fog, and it looks great.

The prefetching should work by loading the next available level of detail from disk into memory during less intensive periods of the game. As the player moves, the areas that were previously on LOD_LEVEL_4 now get LOD_LEVEL_5, which has been conveniently prefetched for us.

The next thought is selective processing. While a player battles with monsters or other players, they will not be paying so much attention on the distant horizon, so we can tighten the LOD falloff a little (increase the gradient at which LOD falls) to allow for better performance during high-movement and high-particle count periods.

Another great performance enhancer is the use of precomputed occlusion volumes. For example, say we have a set of player starting points which face a large building, in a hollowed out crater. Dotted around the edge of the crater are fountains of lava and large glittery and sparkly statues. When the map is created, an occlusion volume is created around the player starting points, which is linked to another volume on the other side (see attached image for demo - red = player start, blue box = occlusion volume, dark grey block = building). The occlusion is precomputed at map-compile time (at the end of development) and requires very little processing.

Sometimes a technical problem can also be solved artistically. If the close environment is kept rich and interesting, the player will be less likely to stare off into the distance.

This is old, but reading the first few posts i'll add what I would like to do (I am an idealist). Generally speaking, you have a ton of geometry, most games deal with this in several ways, area loads and a view distance. If you want a nice way to display it all at once you would probably have to do something simular to the way they handle the graphics scaling in games. Level of detail, in graphics you generally have a bunch of graphics, one at high quality then decrease it by half every step of distance (1024x1024, 512x512, 256x256, 128x128, etc), place it where it needs to be, most the LOD scaling would happen near the horizon (ergo 90% is the 1024, 5% is 512, 2.5% is 256, etc). Generally I wouldn't care enough about very far off geometry to even notice it was there in video games, which is why most cut it, unless the video game made it a big deal.

Oh also, octrees are your friends.

Run the application on a server farm when client is run.

Client captures and sends user input (keyboard/mouse), server farm runs application and renders, and pushes the picture back to client.

Extensible and independent from user's computer specs!

*ducks*

Massive grave digging!

But anyway one way to do it is just calculate the viewable portion of the 'map'/'world' on-the-fly with use of a height map.

I'm afraid that I always viewed LOD s a cheap hack to fix things that the rendering developer couldn't.

My recommendation would be to make a draw sphere. The entirety of the sphere starts out as invalid, and sections of the sphere become invalidated yet again when the distance between the camera and the sections differ from the radius of the FOV by a certain threshold. When they do become invalidated, a full trace render is done in that section.

Pros:
-No loss of quality can be seen by the user.
-You are rendering large distances, but only sparingly.
Cons:
-Massive lagspikes when teleporting or traveling high enough speeds to pass through the threshold on a regular basis.
Recommended fix: Multithread the rendering and create a buffer. Traveling would then cause some small loss of quality as the camera got close enough to the drawsphere to recognize it as a sphere.
-Small moving objects do not update properly from a distance.
Recommended fix: Use *ugh* LOD to omit small objects from being rendered at all. If a lot of entity data changes beyond a specified amount, invalidate that direction.