 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| Terrain Algorithm |
|
 |
JoshG Member since: 11/21/2001 From: Australia |
|||
 Posted - 9/25/2002 8:05:46 AM |
||||
| Hey All, I thought i'd pose a question to you all tonight, I'm trying to build an engine...(as you do)...I am currently thinking about the terrain engine that it will need. It is going to be a 1st person Strategy game, Outdoor...and multiplayer...So that means that the algorithm needs to be (I think): 1. High detail close up where the user can see 2. Low detail in the distance (Mountains, water or something on the horizon) 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) 4. The Scene needs to have animated objects...ie. Trees, People, Structures such as buildings etc. 5. It needs to be rendered in Real-time 6. The terrain needs to be dynamic, (points can be lowered or heightened) and 7. The terrain needs to be able to be updated quickly and efficiently through a network broardcast.. Target Recommended system: Celeron 850 128mb ram 32mb Video Card Those ideas seem rather demanding for an algorithm, and particularly for the recommended system. However, I am quite interested into your ideas on ways for this to be implemented, ideas of how to make it efficient, and some places where i could economise. Thanks --Josh |
||||
|
||||
|
RavNaz Member since: 7/7/2000 |
|||
 Posted - 9/25/2002 11:31:35 AM |
||||
| you definately need to use a CLOD algorithm, look-up some terrain algo's like rottger or ROAM... |
||||
|
||||
|
Yann L Moderator Member since: 2/6/2002 From: Breizh |
|||
 Posted - 9/27/2002 7:02:00 AM |
||||
| 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] |
||||
|
||||
|
JoshG Member since: 11/21/2001 From: Australia |
|||
|
Posted - 9/27/2002 6:58:29 PM |
||||
| Thanks for your opinions, What do you think the minimum specs for such an engine would be? --Josh |
||||
|
||||
|
Xarragon Member since: 7/27/2002 From: Sweden |
|||
|
Posted - 9/29/2002 7:25:46 PM |
||||
| 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 |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
