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!
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:
math routines for graphics and collision detection
efficient and easy to use file IO
think about how to organize stuff in 3D (data structures)
visibility deternimation (VERY important for a terrain engine)
how is you collision detection supposed to work
physics (aerodynamics for a flight sim, collision response)
terrain engine (efficient and good-looking)
support for wide range of hardware (LOD)
input & sound
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 …
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!
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)
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.
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.
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).
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.