I have a large terrain with multi texing and it's an airplane fighter game. I have done the following: 1. split the terrain up into smaller chunks 2. only render the chunks that are in the frustum 3. for terrain a larger distance away I draw much lower resolution versions (ie one third of the width and length or the original chunk) 4. I'm using Compiled Vertex arrays - I don't have VBOs on my card and nor do my friends ! The CVAs sped things up by 50% 5. the aircraft are drawn using display lists 6. the aircrfat are frustum culled 7. I have a skybox each texture is 512x512 8. I have yet to do any collision detection or AI 9. The terrain textures aren't that detailed - what I mean is I'm not tryign to render 700k textures into a tiny part of the ground - I spread the textures out over the terrain. For most of my game if I can see the terrain then I'm at 16 FPS Even if I make the whole terrain LowRes (ie instead of 180x180 height map I in effect make it a 60x60 map by taking every third vertex) then it can go up to say 18 FPS which is a bit better. Without using VBOs is there any other ways I can speed things up ? (I tried putting the CVAs in Displaylists but that wouldn't work for love nor money !) cheers

the first thing i'd suggest is to run a profiled build so you can see which part of your program is actually eating up all the time. from there you can try and work out different algorithmic approaches. for generic starters, i'd suggest looking at quad-trees or oct-trees for starters; they'll allow you to cull huge portions of your world with a single frustum check.

-me

Just a little suggestion i lately got baffled by, have you tried display lists containing glVertexX calls and such instead of VAs? As strange as it might seem, it might make a difference.

Quadtrees are indeed a good optimisation, it might give you a framerate of 160 or more instead of 16. Also, what texture filter are you using, mipmapping could speed things up.

And about the optimizing after profiling, yes that would be best although adding quadtrees will certainly speed things up a lot so they can be added anyway IMO.

EDIT: typo, i said VA instead of quad tree.

you can still get stuck inside the drivers if a the command queue to the gfx card becomes full.

Everyone should read this performance tuning pdf its pretty much THE guide to sorting out problems with OpenGL apps

The 60x60 map should have 7200 polys, right? Even with a brute-force rendering approach, this should be managable even on older graphics hardware (GF2 or so). Even if you don't have quadtrees, it should not be so slow.

VBOs wouldn't probably speed it up too much since the amount of graphics primitives is not too high. VBOs pay off if the transfer of grapgics primitives to the GPU is the bottleneck, but it sounds like the fillrate is your problem.

What graphics card do you have?

I got a huge performance improvement in my engine when I eliminated all divisions in my time-critical code (well as much as possible) and replaced them by multiplications.

Things like normalizing i.e:

float len = sqrt(a*a+b*b+c*c);
a /= len;
b /= len;
c /= len;

are significantly faster if done that way:

float len = 1 / sqrt(...)

a *= len;
b *= len;
c *= len;

so search fpr divisions, especially in time-critical code.

What's fillrate ?

I have an Intel 82865G - I've downloaded the latest drivers for it - it's at opengl version 1.4

I'll try a (my) version of octree processing - I can't see how it would speed things up too much anyhow - I mean I've divided the terrain (180x180) up anyhow into a ten x ten grid where each grid contains 18x18 vertices and I only draw each 'square' if it's in the frustum.