Jump to content
  • Advertisement


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


Terrain optimization

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

Hi I''m making a small game that uses a landscape with 32x50 quads, each quad is 20x20 units, (but the quads are made with GL_TRIANGLE_STRIP, not GL_QUADS), after initializing (making the quads, and putting in a random y-value at each point) i put the Vertex, Color and Texture informataion into Vertex Arrays (locked va''s if supported) with some calculations done in at nighttime i get it to be 1600 vertices. then when i render the terrain i call glDrawElements() which as far as i know is the "fastest" method. the only problem here is that i get a framedrop from 700 fps to 60-70 fps. I''ve tried to only render the player ship and the enemies (+ collision and logic etc) and that''s when i get around 700 fps. And that is with one player model (all models md2 format) with about 50 vertices, and 100 enemy models with 24 vertices = 2400 + 50 vertices. the difference is that the terrain is textured (repeated 256x256 bmp image) and the player and enemy is non-textured. is that the bottleneck or might i be doing somethin wrong here? the code for initializing and drawing the terrain is almost identical to OGL Game Programming book''s example "cacti in the desert" which can be found at glbook.gamedev.net -> code -> chapter 15 or similar. (wonderful book btw) i''ll try to render it without a texture to see if that can be the bottleneck (sitting on a different comp right now). But other than that, what might be the problem? I''ve also tried to change it to 100x100 quads, but the fps decrease just drops like 10-20 fps, not a few hundred! I''m thankful for any help since this is my second game (after a pong clone, you just gotta love ''em ) and I really want it to be at least a bit optimized. Btw, vsync is off (always ) Thanks alot for reading, BauerGL. CUselessStuff::NiftyQuote();

Share this post

Link to post
Share on other sites
are you saying that the drop is when drawing the terrain with glDrawElements over, say, immediate mode, or when drawing compared to not drawing at all..
if it''s the former, then it would certainly be a case that fill rate is being punished. especially:


and putting in a random y-value at each point

if you do this overdraw will go through the roof... each pixel may well be being drawn 10s to even 100s of times...

Share this post

Link to post
Share on other sites
The drop is from drawing 100 enemies + player = 2450 vertices (approximately) in 700 fps, to drawing 100 enemies + player + terrain = 2450 + 1600 vertices in 70 fps. Although I have a kinda high enemy count I get around 60-70 fps with zero enemies + player + terrain = 1650 vertices.

I can''t really understand your pixel stuff, but I''m guessing that you''re meaning that the depth buffer has to do a lot of "overdraws" per pixel? And that is probably true, but how can I skip that each pixel gets "changed" a lot of times without having some fancy culling algorithm?

The view of the camera is moved a little over and a little back from player, so most of the terrain is seen. It''s not like I just see one hill, and that it''s a thousand hills beyond it. I can actually see about 95% of the terrain all the time, although some parts of it are ofcourse "shaded" by the hills.

I wish I could send some screenshots but I have no means to transfer my program (or anything) from my computer to this one :/

One other question: if I make the terrain perfectly flat (y = 0) should the framerate go up then? I''ll try that..

My comp:
amd athlon 1200mhz
geforce2 gts 32mb
512mb sdram

I''ll also try to texture the models to see if I get the same framedrop with so many vertices textured or if it''s the terrain that''s the problem.

Thanks very much for your help, BauerGL.

Share this post

Link to post
Share on other sites
if you draw a big triangle, it takes a lot of pixels to be processed and drawn (and textured etc).

if you draw your terrain with random values you normally get quite big triangles and a lot of them behind eachother..

say your ship eats up a 100x100 pixelsized rect on screen, it will at max have drawn 20''000 pixels (assuming normal mesh and backfacing on about 10''000 max). if you draw a single triangle over the whole say 640x480 screen (2 triangles) you draw 307200 pixels, about 30 times more.. now if you have tons of triangles behind eachother you draw for each of those (big) triangles tons of pixels resulting in possibly 1''000''000 pixels drawn for the landscape.. make your landscape flat and draw it again.. change the res and measure again. if changing screenres changes fps, then its the amount of drawn pixels that count, NOT the vertex count at all (you chan have 100 times more vertices anyways..)

"take a look around" - limp bizkit

Share this post

Link to post
Share on other sites
Just some new info:

I tried doing it with everything textured (enemies and player aswell) which was around 4050 textured vertices at 55 fps (about 10 fps drop from drawing textured terrain and untextured player/enemies). So the texturing was not the problem.

I then tried to make the terrain flat, but the fps count was about the same as with randomized height.

I''ll jump right away to test it with a smaller window resolution and see if the results are different. They should obviusly be different, but about how much different if it is a fillrate problem? Btw, I''ll also test windowed vs fullscreen (windowed right now) and see if it is any difference..

The only culling I have is backface culling, so it''s not drawing the back of the polygons. Nothing else because I''m kinda new to all of this.

One thing I noticed was that when I''m rendering everything but not looking at it (iow the enemies/terrain is outside of the view frustum) I get around 560 fps. So you guys are probably right about the fillrating stuff..

Well I''ll be heading back into my crash-test-dummie-corner again

Thanks alot for your help, BauerGL.


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!