Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Bucket_Head

OpenGL Optimizing a 3D OpenGL Terrain Engine

This topic is 6708 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
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/

Share this post


Link to post
Share on other sites
>> 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

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!