PDA

View Full Version : terrain rendering for flight simulator - many questions



JacekPoplawski
07-28-2002, 03:23 AM
Hello OpenGL gurus!

I am developing free (Open Source) helicopter simulator - you can find it here: http://decopter.sf.net.

I've read about terrain rendering. First I wanted just to draw whole terrain with brute force method. Then I read about LOD - small triangles near, big triangles far - sounds good. I though about quadtree, then I discovered ROAM.

Now I read 2048x2048 picture with heightmap, generate patches, every patch contains 2 binary triangle trees. Every frame I am recalculating trees.

This method sucks. First: terrain is to small, I need something 100 times bigger. Maybe I should load 2048x2048 picture, then add some sin/cos functions? Then I will have 32768x32768 map, but don't need to remember it all the time - just visible patches.

Second disadvantage of this method is: it needs a lot of calculation. I don't have split/merge queue yet, but is it really worth to code it? I mean - maybe it's better to produce (binary triangle tree!) 2-3 levels of detail for every patch and put it in display lists?

I need 9 (3x3) or 25 (5x5) or 49 (7x7) patches at one moment. Camera will be in center patch. I think best choice is 7x7, becouse I could have 3 levels of detail (3x3 - high detail, 5x5 - medium detail, 7x7 - low detail). So I will create "cache" which will remember about 100 patches. When camera move from one patch to another - recalculation will be needed. First engine will check cache - if there is no patch there - oldest patch will be removed from cache and new patch will be calculated (generate sin/cos points, calc bintrees).

The problem is - I can't just calculate new patches at one moment, becouse game will stop for a while! What can be solution for it? Second thread?

Textures... How could you make LOD with textures? I mean how can be triangle with many textures inside? Should it be always splitted? I don't want to have one texture for every patch. I need texture for water, other for low land, other for mountains, etc...

Lighting... I've read about lightmaps, yes, it's easy to generate it. But I can't modify lightmap, what about moving lights? Even Sun is moving on sky. The second problem - I need to remember lightmap for every patch. So patch generation will be longer again.

Do you know any solution for calculating Normals when using LOD?

Please help me - my game needs good terrain engine :-)

Don't Disturb
07-28-2002, 04:40 AM
For all your terrain needs see http://www.vterrain.org/

richardve
07-28-2002, 07:18 AM
Yes, I've got one small suggestion..

Did you know that not everyone is using a resolution of 1600x1200?

(see webpage)

BlackJack
07-28-2002, 07:46 AM
Hm... about the webpage: Some of the sceencaptures look really very fine... others very blury and/or ugly.

To JacekPoplawski: There are unbelievable many ways to manage it. Some of them are gotten old already as they were still written for non T&L cards, others say of themselves they would be great, but are everything else.
For the visibility testing I would propose octtrees... for the LOD... hm... here what I'm using... may not be the best way, but is a very simple and effective one:
The landscape is subdivided into cells. Each cell holds 16x16 fields. At highest resolution 16x16 fields are drawn, then 8x8, 4x4 and so on. It works very fine for me.
Which LOD will be taken is influenced by following two factors:
-distance to the cell
-normal vector angle difference on the cell (if you use 1 or 512 polygons for a flat cell anyway doesn't make any visible difference)

Just one of many possibilites.

BlackJack

[This message has been edited by BlackJack (edited 07-28-2002).]

JacekPoplawski
07-28-2002, 08:07 AM
Hello BlackJack, you wrote:

"The landscape is subdivided into cells. Each cell holds 16x16 fields. At highest resolution 16x16 fields are drawn, then 8x8, 4x4 and so on. It works very fine for me."

How can you avoid "cracks" when one cell is 16x16 and another is 8x8 ? What about vertices on edges?
What about lighting? Are you using normal vectors?
What about texturing? You have one big texture (for whole terrain or for single cell), or you using different textures for water/land/mountain like I want?

And most important - do you have display lists and/or (OpenGL) arrays?

pleopard
07-28-2002, 05:11 PM
I struggled with high polygon terrain rendering for years. There are so many different libraries available and just about every one of them requires a PhD to use or is written so sloppy I wouldn't use it for production code. I finally got fed up and took the Real-Time Terrain rendering course at the Game Institute online (www.gameinstitute.com). It cost $65 and took 6 weeks to complete but it was well worth it. The instructor Bryan Turner is really good and covers a lot of different data structures, algorithms, lighting, and texture mapping techniques that may help you. I hightly recommend it.

jubei_GL
07-28-2002, 06:35 PM
how about loading 1024x1024, and then just seperate each Vertex by 10.. Thus you will get 10240x10240 ... Im doing this when I draw my terrain from RAW , and it looks smooth, and real ..


Don't know if you have started working on Helicopter or not .. If not I would recommend working on it first, its physics and such .. Terrain is NOT THAT important , you can ALWAYs add it later on .. Doing a realistic Helicopter , now that is hard , ofcourse if you will try to implement all the Physics..

[This message has been edited by jubei_GL (edited 07-28-2002).]

[This message has been edited by jubei_GL (edited 07-28-2002).]

BlackJack
07-29-2002, 02:02 AM
"The landscape is subdivided into cells. Each cell holds 16x16 fields. At highest resolution 16x16 fields are drawn, then 8x8, 4x4 and so on. It works very fine for me."

How can you avoid "cracks" when one cell is 16x16 and another is 8x8 ? What about vertices on edges?
What about lighting? Are you using normal vectors?
What about texturing? You have one big texture (for whole terrain or for single cell), or you using different textures for water/land/mountain like I want?

Cracks between cells: I make a copy of the heightdata before the calculation. And this copy I adapt to the LOD level of the neighbour fields. First all LOD levels are set/calculated, then the cells themsleves.

Lighting: No, I don't use normal vectors, they just cost FPS. I thought of using them, but well, the sun does not move, so they're senseless. Each cell has at the moment a 32x32 pixel big lightmap. The lightmaps holds the coloring of the landscape, a simple shading and a shadow thrown by hills etc.

Texturing: As said already, I have one lightmap per cell, which holds the color. This lightmap is multiplicative textured with a basemap. I tried to use also different base textures, but the texture transfer killed my FPS heaviest unfortunately and the lightmaps were more important for me than having multiple base textures.



And most important - do you have display lists and/or (OpenGL) arrays?


No, display lists suck in my opinion on today's hardware. I use display lists only still for material settings and so, but never for any type of vertices. The whole landscape is stored in video memory. Video memory is in general expensive, I know, but because I am only updating the cells VERY rarely, in normal case only the ones getting into viewrange when moving, there is absolutely no performance problem with them.

For nVidia I'm using VAR, for ATI cards (Radeon 8500 etc.) VAO. For both there are a bunch of demos available in the i-net.

BlackJack

p.s. Screencap: http://www.lyxion.com/images/lsv134.jpg
p.p.s. The textures I'm using, you can use the freely for all non-commercial purposes: http://www.lyxion.com/files/lvtextures.zip

[This message has been edited by BlackJack (edited 07-29-2002).]

JacekPoplawski
07-29-2002, 03:57 AM
hello BlackJack, you wrote:

"Cracks between cells: I make a copy of the heightdata before the calculation. And this copy I adapt to the LOD level of the neighbour fields. First all LOD levels are set/calculated, then the cells themsleves."

You calculate are cells at once? How much memory it eats? How big terrain you have?
I thought about calculating only needed patches (+cache).

"For nVidia I'm using VAR, for ATI cards (Radeon 8500 etc.) VAO."

I have Voodoo3 now, I will buy Radeon later, but I want my code be full compatible with OpenGL standard.
So what is the good way to store patches/cells vertices? No arrays? No compiled vertex arrays? No display lists? Then what?

BlackJack
07-29-2002, 10:55 AM
****... my whole post got lost... stupid internet explorer. No, I have a cache for 400 cells. In normal view 120 are visible, from top 300 anything. The remaining 100 ones for the case that the observer only moves a bit back and forward. Only cells which aren't in the cache yet are recalculated, where by the engine offers a function "field x,y changed", which automatically throws it out of the cache as well. Each "cache" also holds the lightmap... may be I'll move that to some other place anytime, but at the moment it's this way.

Because of your Voodoo 3: Well, I personally don't develope for non T&L cards anymore. Who has none shall buy one and who doesn't have the money to buy it doesn't buy the game anyway. The game which will use our new engine will be published XMas next year. Already now days people demand a GeForce or Radeon and latest end of next year we will do as well. So I would also propose you to buy either a GeForce 3 or Radeon 8500. If you don't want to spend so much money a GeForce 2 is fine as well, but that one doesn't have pixel shader yet.

Because of the storing:
Well, I have one big array and this one is divded into tons of little regions which are all even big (one region for each cell). This array is in the video memory of the card. I know to make them even big is wasted space... after all the far distanced fields need far less vertices... but I didn't want to make all more complex than needed.
I use coord, UV0 and UV1 in my vertices, so each vertices is 28 bytes. At the moment I'm getting along with 5 MB of video memory. I know that's a bunch but as... at least in our game... the landscape is one of the most important parts this is it worth. But I will still write a version for 32 MB cards as well, cuz to steal a GeForce 2 5 MB of memory is no really good idea.

Because of the way of displaying:
Well, as said, I use VAR for nVidia cards and VAO for ATI ones, WITHOUT indices. Indices make no sense in my case, the tristrips do theirs work very well. I connect the stristrips of full filled cells with zero dimensional polygons so that I only need one call per cell. The one additional polygon is "for free".
Because of display lists: they are only senseful for flag settings, but not for vertices as they are nothing else than limitated vertex arrays. Limitated through the matter that you can't change them. And as I want to run everything on OpenGL and Direct3D I anyway can't make any use of them... and you should not as well.
To get all relative compatible between OpenGL, Direct3D, nVidia and ATI I have a Vertex Array and Index Array class which use a special function for Lock, Unlock and Draw depending on API and vendor. You should do it this way as well, work arounds within add ons.. and a landscape is an addon... aren't very clean and make just more work than needed.

BlackJack

p.s. "to be full compatible with OpenGL standard" Which standard? Haven't seen anyone since years anymore, after all ATI and nVidia go theirs own way and don't care about standarizing at all. Just hope that GL 2.0 will get them a bit closer again... the incompatibility in the DOS times were already awful enough... I just say "page switch" =/... let's hope they won't destroy GL that way.

BlackJack

BlackJack

JacekPoplawski
07-29-2002, 12:46 PM
Hello again BlackJack.

"No, I have a cache for 400 cells. In normal view 120 are visible, from top 300 anything. The remaining 100 ones for the case that the observer only moves a bit back and forward. Only cells which aren't in the cache yet are recalculated, where by the engine offers a function "field x,y changed", which automatically throws it out of the cache as well. Each "cache" also holds the lightmap... may be I'll move that to some other place anytime, but at the moment it's this way."

My first question is - how your engine updates cache? I mean - you are moving inside world, then crossing the line - oops, new cells are needed. What are you doing in that moment? Calc all needed cells at once? Or you have second thread which takes care about it?
What about lightmap? Is it stored somewhere, or are you calculating it in realtime?

"Because of your Voodoo 3: Well, I personally don't develope for non T&L cards anymore. Who has none shall buy one and who doesn't have the money to buy it doesn't buy the game anyway."

I am creating Open Source game. It can be slow at beginning, but I will try to optimize it. And I hope it will work on every modern computer. Another problem is - Linux OpenGL drivers aren't great, yet. There is support for T&L in Radeon 7500, but it isn't perfectly stable yet. And Linux is my primary target OS.

"So I would also propose you to buy either a GeForce 3 or Radeon 8500."

I will buy 8500 as fast as Open Source drivers will be ready and stable.

"Because of display lists: they are only senseful for flag settings, but not for vertices as they are nothing else than limitated vertex arrays. Limitated through the matter that you can't change them. And as I want to run everything on OpenGL and Direct3D I anyway can't make any use of them... and you should not as well."

Currently I use ROAM (yes, I know it is old method). But why you said I shouldn't use display lists? I read this forum archive and people wrote that display lists is fastest method (I don't understand why compiled vertex array isn't better).

'"to be full compatible with OpenGL standard" Which standard?'

I don't know. Probably OpenGL-1.3 or 1.4.

"the incompatibility in the DOS times were already awful enough..."

I think all this ATI/nVidia stuff is crazy. OpenGL developers should unite and create one, better standard. Functions which are in extensions should be inside next OpenGL standard, so everyone could use it. I don't understand for what OpenGL developers are waiting... time is passing.