View Full Version : simple TERRAIN?

06-13-2001, 12:11 PM
Hi all!!
I would like to design a very simple Flight Simulator. I have a quite good understanding of C++ and a basic knowledge in OpenGL.
Now! the question is what sould be the first step to design a flight simulator. I don't have a clue how to start it.
I thought about creating terrain first!? but I am sure its wrong!
Can anyone give me some clues?.

By the way does anyone know where I could find some good tutorials or sites on how to create Terrains from scratch with some code examples? or anyone have a source code taken from some book or something that has a very simple terrain that I could learn from. I just want to see how it works.
I have the red book but surprisingly there is nothing about it.
Thanks for any help!

06-13-2001, 12:27 PM
Why not take a look at what FlightGear has done? (http://www.flightgear.org/)

mmmmm Free Software.

06-13-2001, 01:09 PM
Regarding terrain tuts.There's a good one on gamasutra.com by Bryan Turner based on a version of the ROAM algorithm by the late Seumas McNally.It's not too simple,but not too complicated either and there's code for it in C++.There are others as well but this is the simplest one,I came up with about ROAM.

06-13-2001, 03:48 PM
I wouldn't use ROAM nowadays, its too CPU intensive and takes almost no advantage of the very fast graphics cards available today. I wouldn't start with a terrain.

I prefer doing things down-up. Think what you may need:

1. math routines for graphics and collision detection
2. efficient and easy to use file IO
3. think about how to organize stuff in 3D (data structures)
4. visibility deternimation (VERY important for a terrain engine)
5. how is you collision detection supposed to work
6. physics (aerodynamics for a flight sim, collision response)
7. terrain engine (efficient and good-looking)
8. support for wide range of hardware (LOD)
9. input & sound
10. hmm, there a lot more...

The order is unintesional. Think what you need more and what is not so important.
Point 3 is very very important. Its not easy do organize your classes so that they are easy to use, easy to maintain, extensible and fast in execution (rendering speed).

As far as terrain goes, there are many LOD algorithms out there but only a few a suitable for today's hardware and these few are not the best-looking. The problem with many terrain LOD algorithms is that they are very CPU intensive, thus not taking advantage of faster graphics pipeline. (Example: I've implemented ROAM and its gave me ~200000 triangles/second, without any LOD I get up to 3500000 triangles/second (fully textured and lit)). So its may be better to use a not-so-CPU intensive algorithm, which will allow you to push more geometry.

Another big problem with terrain is texturing. Most flight sims have a problem that textures appear very blurry in a close-up terrain view. Is it better to use a unique texture or to use tiled textures? You decide for your project.

There are many more aspects to consider, and enough work to do http://www.opengl.org/discussion_boards/ubb/smile.gif ...

Hope this helps,

06-13-2001, 11:24 PM
thanx all! I am sure this will help! at least now I have some ideas! http://www.opengl.org/discussion_boards/ubb/smile.gif
This seems to be not too easy stuff but....
I have to do it!. One day hopefuly when I finish this project I'll post it here to help others! http://www.opengl.org/discussion_boards/ubb/smile.gifThank you again!

Don't Disturb
06-14-2001, 03:05 AM
Lev, I also found ROAM to be way too CPU intensive. You say that there are other algorithms better suited to modern hardware, which ones are they?

06-14-2001, 03:12 AM
is you have a look at the older crytek x-isle demo (geforce3 enhanced!) they dont use any terrain LOD at all. They do carry out some visibility (horizon) culling so they dont render chunks of island that are not visible BUT they basically chuck 60K+ poly's at the card as static geomatry and get 60fps on my P750+GF3.

However, there is a place for ROAM (or other split/merge type LOD schemes.) I want to render an entire planet. I can't do this with brute force - it would need billions (at least!) of vertices to map an entire globe. I use a subset of ROAM to maintain a dynamic bintree. Yes it's CPU intensive but I can start way out and zoom way in and get 10m resolution (terrain generated in realtime using Noise3 based function)

Rob J.

06-14-2001, 07:05 AM
Don't disturb:

one could use a multi resolution terrain, which has high memory requirenments though. I.e. you store a patch of say 32x32 vertices in 5 different resolutions and depending on a distance to the vew point you choose the appropriate resolution. This should be faster than ROAM with same triangle count, but it also gives more "popping". Well, but since its faster you can insrease detail level and the popping won't be that bad.


06-14-2001, 09:23 AM
The TIN (Triangulated Irregular Network) algorithm is the most efficient. It takes a field of elevation points and finds the point that is furthest from the current triangulation (which starts with two triangles covering the area). Now add the worst point, retriangulate, and repeat.
This comes up with a non-uniform triangulation (the disadvantage), but with far less triangles and a better looking approximation to terrain. Combine this with some LOD switching and you have a scheme that many of the best IG's (Image Generators) use.

06-14-2001, 10:05 AM
the irregularity is a _big_ disandantage when it comes to texturing, texture coordinates have to be genereted each frame, no good.

1. long winded
2. speed penalty

Though I argree, TIN produces the best looking terrain with minimal triangle count of almost all many LOD algorithms.


Sven Clauw
06-14-2001, 10:38 AM
what about VIPM (see http://www.cbloom.com/3d/index.html )?
anyone used that and what do you think?


[This message has been edited by Sven Clauw (edited 06-14-2001).]

06-14-2001, 01:26 PM
"the irregularity is a _big_ disandantage when it comes to texturing, texture coordinates have to be genereted each frame, no good"

Why not use automatic tex coord generation? It's apparently faster than sending a huge tex coord array every frame.

06-14-2001, 02:40 PM
We use VDPM (View Dependent Progressive Meshes) in our game (Reaper, URL to soddy alpha posted awhile ago).

Since we haven't implemented geomorphing (interpolating to avoid popping) or storing of the precalc and have not optimised memory usage that much, it's hard to tell how good it is going to be.

But it does work, and is quite fast since you can spread the work that has to be done over several frames.

We will implement dynamic loading and spread the terrain up into smaller patches, to try to get more detail into it, while still being able to see far away.

The biggest problem is actually to hold all the geometry in memory. LOD and dynamic loading works for the graphics, but can the same thing be done with physics and collision?

And how do you correctly handle having 100-200 freely moving objects, plus all laser shots and missiles?

Not OpenGL, I know, but nevertheless quite interesting questions.

06-14-2001, 03:42 PM

automatic texture generation is slower than specifying explicit texture coordinates on all cards I've used.


06-14-2001, 03:43 PM
"Not OpenGL, I know, but nevertheless quite interesting questions." So what is that?

Thx all! I am sure this'll help a lot! http://www.opengl.org/discussion_boards/ubb/smile.gif
One more Question- Should I draw the wireframe for the whole area in one go? even if it is not visible? and then put the texture on the visible part?

06-14-2001, 04:37 PM
Keep in mind that dynamic LOD algo's are for what is mostly a specific purpose: to allow the detail of a given object be reduced when the detail wouldn't be seen.

This mainly means FPS-style things, but it's easily usable in a flight-sim. And as far as CPU intensivity - you must have been doing something wrong. LOD for terrain requires the use of several intuitive metrics so that you won't be pushing 200k polys of a 350k poly dataset. Using a few culling options, and a few other error metrics, you CPU should never have to split/merge more than 1/2 your total count (meaning a 50%), and more optimally, it would never have to traverse and render more than maybe 1/4 of your polys. I would say that under worst circumstances, a properly crafted LOD algo will actually render (just a guess) 60k polys out of said 350k poly set, with a 20% overhead in CPU time.

Sure, the tradeoff is the CPU time, but dumping the polygon count by 1/4 or more will allow you to ultimately let the video card put more eyecandy on your scene. And for a 20% CPU penalty, I think it'd be worth it (in most cases - there are exceptions).


Tim Stirling
06-15-2001, 12:46 AM
Geomip-mapping is a very good algo, static LOD is also good.

06-15-2001, 01:27 AM
Tiles of static VIPM meshes sorted in a quadtree with AABBs for view frustum culling would probably rock.

06-15-2001, 04:57 AM
I use TIN and then clip my terrain into squares that match the size of my textures. This way I can assign texture coordinates in a display list. This works well. The clipping adds a lot of polygons, however.

06-15-2001, 08:43 AM
Originally posted by robert_s:
"Not OpenGL, I know, but nevertheless quite interesting questions." So what is that?

Those that were in my post about physics/collision/object management.

06-15-2001, 10:01 AM
Terrain CLOD: A properly implemented CLOD algorithm still beats the pants off a brute force system. This is due to the shear volume of geometry that a terrain contains. If you only render 10% of it, then your card is free to do other things. Not to mention the market penetration of T&L cards is still miserably low (give it another year..).

Texturing: It would be nigh-impossible to texture a terrain properly with auto-gen tex coords. Too many edge-blending issues. And a good texture LOD algorithm looks fabulous compared to a detail texture over a super-streched color map.

TIN: Too complex, too much memory, too many 'sliver' triangles...

VIPM: Why? Isn't 'View Dependent' the whole point? *shrug* Depends on the project I guess.

VDPM: Looks promissing, I need to read more. http://www.opengl.org/discussion_boards/ubb/smile.gif

Geomip-mapping: Does not allow for strong terrain roughness metrics. Works fabulously for 'smooth' terrain though. Try it with 'spikey' terrain and you'll understand.

Finally, robert_s: You do not need to draw the wireframe for any of the terrain. Instead, you want to draw only those parts of the terrain in the view frustum. Read my Gamasutra article to get an idea of the terminology used in Terrain Rendering. You'll be performing two phases: Tessellation and Rendering. During Tessellation, you decide which areas of the terrain to render, and how many triangles to use for it, this decision is called the Split Metric - and is also where you perform frustum culling.

I keep a fairly up-to-date bibliography of Terrain Rendering on my website, I recommend purusing it before beginning your engine. (http://www.fractalscape.org) Also check out the cannonical site (http://www.vterrain.org).


06-16-2001, 03:24 AM
FYI: Empire/Rowan Software is thinking about releasing their Battle of Britain flightsimulator as open source.

See this discussion:

See here for infos about BoB:

This could become a nice starting point, right now BoB is using DirectX as far as I know, but this could be changed. The flight model and engine are state of the art and can support several 100 planes at once in one game.

06-16-2001, 05:23 AM
BryanNC said:
VIPM: Why? Isn't 'View Dependent' the whole point? *shrug* Depends on the project I guess.

Well, the advantage is that you touch very little data each frame, and only indices, which means you don't have to write to agp mem which is nice. And not being view dependent isn't a very bad thing, especially if youre close to the ground most of the time. Then silhouette edges are fairly static (ridges and the like) so you can just add a cost to removing detail there, not at run time but off line. Of course there is _some_ view dependence, you use lower LOD for tiles that are farther away, but you never alter silhouettes or something like that.

06-17-2001, 04:30 AM
Thx all! you helped me a lot! http://www.opengl.org/discussion_boards/ubb/smile.gif