Terrain Algorithm

you definately need to use a CLOD algorithm, look-up some terrain algo''s like rottger or ROAM...

Not easy to achieve with those minimum specs...

OK, let's see:

"1. High detail close up where the user can see"
"2. Low detail in the distance (Mountains, water or something on the horizon)"

Long distance but still detailed near the viewer. This would be either:
* a very high resolution heightmap (with the resulting memory consequences) using some form of (C)LOD.
* or a prgressive mesh (complicated to implement)
* or a realtime fractally generated terrain (details are generated on the fly, but not stored).

"3. Items visible on the horizon should correspond to items that are actually on the map (ie, no Standard texture that is set as the horizon)"

Again, that's a large scale terrain. What about a hybrid approach ? Take a highres heightmap as the 'near terrain', the part where the player can walk around. Then take a second, much larger and coarser heightmap that represents the surrounding environment. You could also use a simple static mesh for the surrounding terrain, since it won't be modified.

"4. The Scene needs to have animated objects...ie. Trees, People, Structures such as buildings etc."

That's independent of the terrain engine. Your standard 3D geometry engine will handle that.

"5. It needs to be rendered in Real-time"

Of course

"6. The terrain needs to be dynamic, (points can be lowered or heightened)"

Hmm. A dynamic terrain will rule out any progressive mesh or geomipmap system, as those require extensive preprocessing. That leaves you with a heightmap. Either feed it brute force into the 3D card (if it's not too big), or use some form of dynamic LOD scheme on it. I would suggest a non-continuous form of ROAM (where the mesh doesn't change every frame, but error metrics are accumulated instead. The terrain patch adapts every 10 or 20 frames). Use geomorphing to avoid artifacts when switching between LOD levels.

"and 7. The terrain needs to be able to be updated quickly and efficiently through a network broardcast.."

Write a good transfer compression and protocol If you only update a few heightmap points every frame, that's no real problem. You could use some form of runlength encoding to compress the modified height data and position offset.

Keep in mind, that the ultimate terrain algorithm doesn't exist... You can go pretty far, and you certainly can create an algorithm that satisfies all your requirements. But not on those system specs - you'll have to compromise somewhere, if you want it to run somewhere near realtime on a Celeron 850 and a 32MB card...

/ Yann

[edited by - Yann L on September 27, 2002 7:02:36 AM]

Thanks for your opinions,
What do you think the minimum specs for such an engine would be?

--Josh

There are some good articles about this.

"Continuous LOD Terrain Meshing Using Adaptive Quadtrees" and "Real-Time Dynamic Level of Detail Terrain Rendering with ROAM" both presents good methods.

Personally, Im really impressed by Ulrich´s terrain demo (witch can be downloaded from "Continuous LOD Terrain Meshing Using Adaptive Quadtrees"). Im working on a simple terrain engine with the same routine, witch I´m trying to implement deformable terrain into in an efficient way. Can´t really say I´ve gotten somewhere yet thou. All this website designing I´m doing for get some additional income keeps eating all free time... Ok, I´ll stop whining... Hehe...

BTW: The articles are to be found at Gamasutra. You might be required to sell Gamasutra your soul to read them (register), but it´s worth it.

Cheers
Martin "Xarragon" Persson