simple TERRAIN?

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!

Why not take a look at what FlightGear has done? (http://www.flightgear.org/)

mmmmm Free Software.

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.

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

Hope this helps,
-Lev

thanx all! I am sure this will help! at least now I have some ideas!
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! Thank you again!

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?

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.

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.

-Lev

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.

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.

-Lev

what about VIPM (see http://www.cbloom.com/3d/index.html )?
anyone used that and what do you think?

thanks

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

Quote:
“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.

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.

kieranatwork:

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

-Lev

Macke
“Not OpenGL, I know, but nevertheless quite interesting questions.” So what is that?

Thx all! I am sure this’ll help a lot!
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?

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).

Siwko

Geomip-mapping is a very good algo, static LOD is also good.

Tiles of static VIPM meshes sorted in a quadtree with AABBs for view frustum culling would probably rock.

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.

Originally posted by robert_s:
Macke
“Not OpenGL, I know, but nevertheless quite interesting questions.” So what is that?

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