Hi, I'm about to attempt to program the fastest plain-polygon terrain engine that I can using C++ and DX9. The process will allow me to hone my programing skills and refresh my C++ knowledge. The end result will hopefully be an extremely fast and well-designed rending engine that can be easily upgraded to use textured polygons, map objects, sky boxes, etc. I'd like to know if any of you have attempted something similarly, and if so, what your general results were. Also, if you know of any similar attempts by others and have links, please provide them. My only fear is the a design for the fastest plain-polygon engine will be totally different that one for the fastest textured-polygon engine! :)

You make it sound like your preparing to break some world record at break-neck speed [smile].

If your using dx9 as your renderer then you don't have to worry about the rendering of polygons since directx will handle that for you.
Some things you may need to consider are:
* the format for polygons: indexed triangle strips are generally the fastest
* the batch size: different for every card, but several thousand polygons generally.
* spatial partitioning: quadtrees are well suited for terrain engines
* occulsion: you may want to consider the amount of occulsion, for example large mountains the occlude large distances, you can use hardware accellerated occlusion tests.

Edit: There is no be-all and end-all of terrain engines, especially when you consider different cards and different manufacturers recommend different formats, data, etc for optimul efficiency.

I admit that I have much to learn with how to go about making the fastest one I can. It's that the process will allow me to enhance my understanding of designing, coding, and hardware, with a end result which I can later use to expand into what I really desire -- a realistic-looking terrain engine.

It seems this is a more practical and logical goal than attempting to out-do the Farcry engine on my first attempt at DX programming! lol.

It will be interesting to figure out the best ways for the two main brands of cards -- nividia and ati.

Thanks for the tips. I've read people mentioning strips and lists before but haven't done any research into it yet.

Quote:Original post by crocomire
You probably want to implement some level-of-detail techniques. Check out
the Virtual Terrain Project especially here.

Thanks for the links! I'll do my best to read up on them. :)

Quote:Original post by matches81
one problem I see about doing a really fast terrain engine using untextured polygons is the following: It is quite simple to batch those, since you´ll use the same texture for all of them (none) and will probably use the same lighting settings and stuff for all of them. So you´ll simply be able to batch as many as is good for the hardware you´re using without having to consider any changes.
Now, if you plan to add textures to it, batching becomes more complicated, since you have to take those into account, as well as things like lighting, shaders and so on... this will surely change the way you have to batch the polygons quite dramatically.
I´m not saying your plan is useless, but you should consider this and other future expansions if you plan to use the engine further... otherwise you might run into serious problems changing your fast plain-polygon engine to a textured-polygon engine and retain the speed of it.

Well, at this point I'm not even quite sure what batching is other than what the words suggest. That is, sending batches of data to the GPU to be processed instead of all at once.

I did want to have lighting and shading effects for the plain-polygons, or else I wouldn't be able to tell them appart and it would just look like a wierd shaped colour-thing. Perhaps if I work with that in mind it will be more similar to also using textures that it won't be such a large leap to add that feature.

The idea, which may not be sound, was to learn DX9 and refresh my C++ knowledge by programming an efficient and fast terrain rendering engine by focusing on the basic essential, which is to render the polygons that form a terrain. By focusing on speed and efficiency I will improve my overall ability. Issues that I wouldn't care to focus on because CPU's and GPU's are so fast would have to be focused on. All of that is essential since when I add features to the engine more CPU and GPU power will be required, and so by making the fastest to begin with at its core I will be in a better position to make a solid engine.

I realise that whatever I make will probably be archived and the experience and knowledge gained used to design a better terrain engine from scratch. But to do that, I first need to make something and figure this all out as best I can. It is an iterative process and so I don't expect to replicate farcry on my first, second, third, attempts at a terrain engine. Maybe the fourth! :)

All of the subsytems used for a better terrain engine will be made for my first one and so used again on subsequent attempts. That is, a console system, camera system, heightmap loader, and even physics code if I choose to add that before writing a further terrain engine from scratch.

It's just that I read so many articles and websites by novice programmers that attempted too much at once instead of gradually building up there abilities and so wasted there time in failed projects. And I use the word failed because I don't even think they get much from the experience since they don't learn how to do anything with great expertise because they spent there time focusing on an entire project and so settled for mediocre parts. Does that make sense? I don't want to be one of those people. If I design a plain-polygon terrain engine I'd like it to be close to the best possible, and likewise for a console system, physics system, etc.

Thank you for the great input. I will read more than I need to for plain polygons to heed your advice and perhaps make a few changes to better facilitate the use of textures, lighting in future upgrades.

You might try using an atlas, then you dont have to swap any of the textures XD

Something really easy to add would be fustrum culling.

Quote:Original post by blizzard999
There is not the perfect terrain rendering algorithm; do you need it for a flight simulator, or the observer walks on the ground? Do you see the entire terrain or only a part of it? How big is your map?

The most important thing is the algorithm; without LOD I think you will go to nowhere because it can drastically reduce the number of renderered polygon (10-100 or even more)
Before going to write your killer algo [smile] remember that a lot of academic researchers have spent their life in develop these algorithms.

Google keywords: terrain algorithm lod geomorphing.

I've done lots of reading now. Some understanding is still needed for CLOD though in terms of how it can be integrated with culling means such as quadtrees.

I eventually want to write a terrain renderer that can model areas such that a person flying a jet at cruise speed, say an f16, will take around 5 minutes to traverse the map. I'd like people to be able to drive around in tanks and have battles on the ground as well. Sort of like a more realistic version of Battlefield 1942 but with updated graphics and larger areas, unlike BF2. :)

But, for now, I'll focus on rendering plain polygons as fast as possible. :)