I'm still developing on OGL2.0+extensions, though here are my experiences/knowledge:

1. I draw gui elements (including letters for text!!) the old way (glVertex..,glColor, etc.), not using any buffers or lists and still the performance is remarkable (300-500 + few thousand letters,this will slow down the game, but most often only half the FPS on my nvidia8800).

2. Particles and decals are in a VBO (dynamic), no CPU update once they have been spawned (they move along a spline which is calculated on the GPU alone).

3. Static ad-hoc batching for grass, stones,small plants.

4. Every other object is rendered as single VBO call.

In my pipeline the most significant impact has the post-processing effects (screensize-bottleneck). I see it like that, that we (hobby-indie) devs have so much GPU/CPU power at hands, that up-front over-optimization is seldom necessary , your game will most likely benefit more from maintainable code.

Best to check, if you are pixel shader bound (screensize test), then try to check, if some state changes (texture switches etc.) are limiting your performance and eventually check if really draw calls are a limiting factor. I.e. most of my models don't have less then 1000 vertices, I never use LOD after seening no performances improvements.

But it depends on your hardware target and what you render (200 zombies  or 10 enemies ? A forest ? ).

If you want to optimize I would take a look at the particle system. The geometry shader could be used to improve the particle throughput (one vertex expanded to 4), though particles are most likely although pixel-bound.

I'm still developing on OGL2.0+extensions, though here are my experiences/knowledge:

1. I draw gui elements the old way (glVertex..,glColor, etc.), not using any buffers or lists and still the performance is remarkable (300-500 elements will slow down the game, but most often only half the FPS on my nvidia8800, when rendering more then 400 elements per frame).

2. Particles and decals are in a VBO (dynamic), no CPU update once they have been spawned (they move along a spline which is calculated on the GPU alone).

3. Static ad-hoc batching for grass, stones,small plants.

4. Every other object is rendered as single VBO call.

In my pipeline the most significant impact has the post-processing effects (screensize-bottleneck). I see it like that, that we (hobby-indie) devs have so much GPU/CPU power at hands, that up-front over-optimization is seldom necessary , your game will most likely benefit more from maintainable code.

Best to check, if you are pixel shader bound (screensize test), then try to check, if some state changes (texture switches etc.) are limiting your performance and eventually check if really draw calls are a limiting factor. I.e. most of my models don't have less then 1000 vertices, I never use LOD after seening no performances improvements.

But it depends on your hardware target and what you render (200 zombies  or 10 enemies ? A forest ? ).

If you want to optimize I would take a look at the particle system. The geometry shader could be used to improve the particle throughput (one vertex expanded to 4), though particles are most likely although pixel-bound.