Jump to content
  • Advertisement

Archived

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

Optimization for a landscape engine

This topic is 5126 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

Greetings all I''ve been playing around with my landscape engine and figured it may be time to stop adding features and start optimizing. First, a brief run-down of the situation. I have very little OpenGL experience. In fact, this is week #1 for me. I''ve read NeHe''s tutorials up to #10, so my understanding of OpenGL is still in infancy. It was enough for me to write a pretty cool landscape engine, complete with water and sand and stuff, as well as a heightmap generated on the fly with my own custom-made noise function, and keyboard-based movement. While it runs at a decent speed, the problem is this... I have 80,000 triangles. 240,000 vertices. That''s a lot. Why so many? My heightmap is 200x200. Each pixel consists of two triangles, as in...
|¯¯/|
| / |
|/__| 
This works fine and gives me a very pretty and smooth landscape. What I do is, well, just render every triangle one by one. Basically, there''s very little going on. Just... loop through my 80,000 triangles and render them one by one... So what could I do to make this better? I''ll gladly provide code if necessary. I''m still learning OpenGL, so I''m afraid some of the more advanced landscape-rendering methods are beyond me at the moment. But a few pointers on how to handle a high amount of polygons at once would be very welcomed.

Share this post


Link to post
Share on other sites
Advertisement
Ok... I,ve just tried triangle strips and I''m getting pretty crazy speeds.

Well, kinda embarassing, but I think I''ve found the answer to my own problem, heh. Though if there,s anything better than triangle strips, I''m all ears.

Share this post


Link to post
Share on other sites
If you don't mind storing an extra copy of everything in video memory, use display lists. When you initialize your triangles at the end of it do something like:

int list = glGenLists(1);
glNewList(list,GL_COMPILE);
--- render all the triangles ---
glEndList();


Then in your display function don't draw the triangles, just call

glCallList(list);

Someone will probably respond to this telling you about VBOs but I haven't tried them yet as I'm pretty new myself.

Life would be so much easier if we could just get the source code.

[edited by - Venerable Vampire on May 9, 2004 5:36:28 AM]

Share this post


Link to post
Share on other sites
Display lists suck for terain, I actually got a speed penalty, for a 256x256 terain, on a TNT2.
I suggest using vertex arrays, since they are easy to use, and they give a good speed increase. You can also try VBO, but your program won''t run on older video cards.
You should also try implementing soem LOD algorithm.

Share this post


Link to post
Share on other sites
quote:
Original post by Venerable Vampire
Life would be so much easier if we could just get the source code.


Sure thing. It's right... here. http://www.geocities.com/RuneLancer/GLand_src.zip

(I'd make a clicky but geocities seems to block it, so you'll have to copy-paste it in your browser's address bar. Sorry!)

I've (very loosely) heard of display lists, but I was under the impression that they sped up cases where you had multiple similare items to draw. For instance, an enemy model. How does it work, loosely? I can't say NeHe offers the best of explanations...

And how would I go about using vertex arrays? Currently, I just precalculate everything in an array. Mind you, I'd be better off using an array of structs instead of a 3D array ( :x ) but I haven't gotten around to that yet and I honestly doubt it's a major cause for performance hits.

[edited by - RuneLancer on May 9, 2004 2:16:53 PM]

[edited by - RuneLancer on May 9, 2004 2:17:33 PM]

Share this post


Link to post
Share on other sites
Vertex arrays are very simple. Basically, you store your vertex info, normals, uv, color, whatever in a list of (preferably) consecutive values, and call a few functions, and that''s it.
Did you get the "OpenGL Programming Guide" Book? If not, get it, and read it. It has all the info there.

Share this post


Link to post
Share on other sites
quote:
Original post by Raduprv
Did you get the "OpenGL Programming Guide" Book?


Hmm, ''fraid I don''t read books (nor see much of a point to them). I''ll have a look on google for a tutorial or reference guide though; I''ll try to implant this and see how the results add up. Thanks!

Share this post


Link to post
Share on other sites
quote:
Original post by RuneLancer
Hmm, ''fraid I don''t read books (nor see much of a point to them). I''ll have a look on google for a tutorial or reference guide though; I''ll try to implant this and see how the results add up. Thanks!


Then have fun learning OpenGL without reading that book.

Share this post


Link to post
Share on other sites
quote:
Original post by Raduprv
quote:
Original post by RuneLancer
Hmm, 'fraid I don't read books (nor see much of a point to them). I'll have a look on google for a tutorial or reference guide though; I'll try to implant this and see how the results add up. Thanks!


Then have fun learning OpenGL without reading that book.


Thanks, I am actually. So far I'd say I've made quite a bit of headway, seeing as I've only started OpenGL a few days ago and never touched a 3D api before. I suppose you're going to reply with scorn when I'll also say I've learned C++ without a book?

I'm just looking for the next step in OpenGL optimization. Not a lecture on your personal means of learning.

[edited by - RuneLancer on May 9, 2004 4:16:44 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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!