Request for performance tips

[Endolf]

Hi

I'm trying to render a simple scene and hitting some performance issues that I'm fairly sure are not hardware limits.

In my scene I have a skybox that is drawn first, with the depth buffer disabled so it's always over drawn. It's a cube and has 6 textures one for each side.

I also have a single model that I am rendering 100 times in a 10x10 grid.

The model itself is an AC3D model that has 833 triangles, a gl material (shinyness, specular, difuse, ambient colours etc) and a single texture.

The texture is 256x256 currently although I have tried different sizes.

I have tried creating a glList for the whole model including the texture calls, the material calls and the gl_triangles geometry calls all in the 1 list and rendering that.

I currently have a version that uses the triangle buffer class that kevglass wrote that uses ARB vertex buffers (source here).

This method seems to be faster when I'm calling the render method on the TriangleBuffer than when I call the list, but the fps is lower. I'm guessing the Display.update() is taking longer in this case though.

I'm currently seeing FPS around 8-16 on my laptop which has a Geforce 5650 card in it, and 83,306 surfaces, 83,300 of which are triangles, doesn't sound like the sort of quantity that should be causing the issues I am seeing.

I'm guessing I am doing something very wrong somewhere

Can anyone think of common mistakes that will cripple performance that I should check for?

The source for my code is available from websvn here and kevs bits are here

The important classes to look at are probably this one and this one

Any help/suggestions appreciated.

Cheers

Endolf

[Fool Running]

A couple of things I saw in the code you gave links to:
- You are setting your material properties for each render of the model. This is relatively slow in OpenGL. The engine should be able to keep track of the models rendered, change the material properties once and then render all of the objects with that material property.
- You have GL_NORMALIZE enabled. As near as I can tell you are calculating the normals yourself, so just make sure they are 1 unit long then you shouldn't need this enabled.
- You are doing 2 sided lighting and culling the back of the polygons. I don't know if there are wasted cycles or not, but it doesn't seem right. :lol:  2 sided lighting should be part of your material properties, if you need it.
- You are creating new FloatBuffers each render of the model. This is also probably some of your problem. Try creating a dummy one that stays around (like as a private to the class), with say 16 floats, and just reuse it.
- The same goes with the Matrix4fs and the Vector3fs, but those probably aren't creating too much of a problem.
- Also you are logging and insane amount of stuff. I don't know if that creates a noticable slowdown, but it wouldn't surprise me.
- ARB_vertex_buffer is mainly used for dynamic data. Its not meant to replace a display list. For models that don't change (probably most of the game world) you probably still want to use display lists.
- In general, the best thing you can do is to minimize the number of OpenGL calls.

That's all I can think of off the top of my head :lol:

[TalanOFF]

Hi, I can only agree with what Fool Running posted.

You're calling the new() operator a lot of times inside one single method and, as far as I can follow the code, the method is used pretty often (worker method vs. init method). Every time you call the new() operator a lot of "underground" work is performed for allocating resources. Generally, try to avoid using the new() operator in worker methods (methods that are called frequently; init methods are called just a single time on object creation).

I see that as a major performance impact source.

Signed: TalanOFF

[Endolf]

Kevglass tried my app and it fell over horribly. I was using VBO's and his card doesn't support them, so I switched to lists. The performance jumped from 80fps to 196fps. I suspect there was something wrong in the way I was using them, but the end result is the same. I've made a huge improvement in performance and there is still more room for introducing some of the things you guys have mentioned.

Thanks

Endolf

[Bvsemmer]

This is probably not your performance problem but rendering your skybox first is not a smart thing to do.  
You mention it yourself: everything gets rendered in front of the skybox.  This means you're sending fragments through your pipeline which get overdrawn anyway later on, this is ofcourse a terrible waste.

Always render your skybox last.