Optimizing a 3D OpenGL Terrain Engine
Hey all. I am making a 3D Terrain engine in OpenGL, and so far it''s looking pretty good. Right now my major concerns are that of optimization, of being able to show a lot of the map while still keeping poly counts at a reasonable level.
I tried just showing ALL the polys at one time (heheh) but that was WAYYY too slow! Then I just made it where it draws all the polys within an x/y area from the camera, and that runs fast, but the wider I make the range, the slower it will get.
A few questions - I have heard something about implementing some sort of Level of Detail modeling for this, rendering the farther away stuff at less detail. How would one go about implementing this?
Also, it may go faster if I don''t even consider any polys behind the camera - how would I determine if a group of polys shouldn''t be considered? Would such a thing even be worth it, since the math involved may slow other things down?
Any help you can offer would be greatly appreciated. If you need any more information about my situation, I will post it. Thank you for your time.
Gamasutra has just put up a really good article on the ROAM terrain algorithm that I think is very easy to understand. You may want to check that out.
BTW You can find Gamasutra here just in case you don''t know:
http://www.gamasutra.com/
BTW You can find Gamasutra here just in case you don''t know:
http://www.gamasutra.com/
>> I have heard something about implementing some sort of Level of Detail modeling for this, rendering the farther away stuff at less detail. How would one go about implementing this? <<
The simplest terms to think of things is this: depending on the distance from the camera, nearby polygons can be merged to reduce polycount but maintain a similar appearance. This can result in cracks between polygons or "drastic popping" in the terrain, but there are solutions.
>> Also, it may go faster if I don't even consider any polys behind the camera - how would I determine if a group of polys shouldn't be considered? Would such a thing even be worth it, since the math involved may slow other things down? <<
You're heading in the direction of frustum culling. The fustum is essentially anything that the current camera can see...sort of like the range of sight (what you can see side-to-side and top-to-bottom).
There are also a large number of ways to cull/clip polygons...backface culling, guardband clipping, etc. look around. Check out www.tulrich.com for the author of a recent GDMag article on quadtree terrains. The article comes with source to play with, which should be of help.
Edited by - Revolver on 4/4/00 11:23:36 PM
The simplest terms to think of things is this: depending on the distance from the camera, nearby polygons can be merged to reduce polycount but maintain a similar appearance. This can result in cracks between polygons or "drastic popping" in the terrain, but there are solutions.
>> Also, it may go faster if I don't even consider any polys behind the camera - how would I determine if a group of polys shouldn't be considered? Would such a thing even be worth it, since the math involved may slow other things down? <<
You're heading in the direction of frustum culling. The fustum is essentially anything that the current camera can see...sort of like the range of sight (what you can see side-to-side and top-to-bottom).
There are also a large number of ways to cull/clip polygons...backface culling, guardband clipping, etc. look around. Check out www.tulrich.com for the author of a recent GDMag article on quadtree terrains. The article comes with source to play with, which should be of help.
Edited by - Revolver on 4/4/00 11:23:36 PM
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement