Performance Issues

I was wondering how triangle bound video cards are, because it doesn't seam to matter if i'm at 200x200 or 1280x1024 with a full screen of pixels or an empty one, my FPS is ALWAYS directly related to the number of triangles I have. Here are some numbers

each "tile" is 2 triangles

31x24 map (35+ FPS)
31x117 map (idk how many FPS, but I think it was around 12)
47x147 map (7 FPS, but it looks ALOT better)

I am using prebuilt triangle lists here too (on the map, but not the golf club). It doesn't matter if I am looking backwards at 10 triangles, or forwards looking at all 1000+ of them.

Quote:Originally posted by jabber Your performance will always be tied to the number of triangles that you have to draw. Using vertex arrays can really speed up your performance, along with clipping, culling, etc.

Looks like I have LOTS of work to do, I am using GL_Triangle now, oh well, I will just make my maps lower resolution

My next game is going to be 10X as fast and understandable (code) than this one

Quote:Originally posted by Jake Looks like I have LOTS of work to do, I am using GL_Triangle now, oh well, I will just make my maps lower resolution

My next game is going to be 10X as fast and understandable (code) than this one

If you are coding in OpenGL using glBegin(GL_TRIANGLE) and glEnd() and calling glVertex3f(), I can't remember the correct name for this style of the top of my head?? Yes you are limited, more or less by your CPU might be running out of gas, do the math on the number of times you are calling functions. I know I ran out of gas with my code because of that. You need to move to vertex arrays at least or VBO's or display lists. Culling will help a lot but I haven't gotten around to implementing it yet, due to I really don't want to do that for my game.

before you start going to wacky arrays, eliminate unnecessary triangles first, this will be much better. Also, you might want to rethink what you are doing too. Are you using LoD? do you really need 400 triangles at 100 meters away as you do at 10 meters?

If you're using immediate mode (meaning that the renderer doesn't retain any non-critical information between calls), then you're taking a significant speed hit. However, the numbers your stating are a little low even if you're on an old iMac.

For the fastest way to get triangles onto the screen (well, fastest as of about a year ago), see this thread.

Thanks, I need to do some tests, and probably redo my entire level format (it uses the same sized triangles for EVERY tile, when in some cases 20 triangles could easily be replaced with 1 (but in other cases like on the green I need more detail)

Also, I think my golf ball is set WAY to high, because its pretty small and I have the detail up their.

And also right now I am checking EVERY polygon for collision detection ( I am working on some code to just do the 9 triangles its above, but I haven't implemented that yet)

I have a few questions too:

1) Right now for testing about all of my textures are 256x256 mipmapped. Mipmapping INCREASES performance right? also, how much of a performance increase will I get from going down to 128X128 or even 64x64?

2) Does the CPU or the video card do all the translations, because with 3 vertice per triangle and ALOT of triangles, thats ALOT of math for a CPU to do!

3) How much does lighting effect speed? Right now i'm using an ambient and a diffuse light.

4) Will full-screen help out a little bit? (maybe 10%?)

Thanks for the help, their will probably be a lot more questions, and i think because of time I will have to stick with triangles and use a lower resolution map, but my next GL game is going to kick so much ass, look out uDG 2004

Quote:Originally posted by Jake And also right now I am checking EVERY polygon for collision detection ( I am working on some code to just do the 9 triangles its above, but I haven't implemented that yet)

I'd say that's more likely responsible for your framerate drop than the rendering. Profile the code and find out.

Quote:1) Right now for testing about all of my textures are 256x256 mipmapped. Mipmapping INCREASES performance right? also, how much of a performance increase will I get from going down to 128X128 or even 64x64?

Unless you're short on video memory texture size and mip-mapping aren't going to be a big impact on performance. However, mip mapping (and in particular tri-linear mip mapping, GL_LINEAR_MIPMAP_LINEAR) are a performance hit, not boost. btw, what hardware are you on?

Quote:2) Does the CPU or the video card do all the translations, because with 3 vertice per triangle and ALOT of triangles, thats ALOT of math for a CPU to do!

Well, anything since Rage 128 has been able to do basic transformation (modelview & projection) on-card. This is one area where glDrawElement, (or GL_TRI_STRIP/GL_TRI_FAN) can help, because the card gets to reuse two points out of the previous triangle.

Quote:3) How much does lighting effect speed? Right now i'm using an ambient and a diffuse light.

Lighting is a significant speed hit once you've got the rest of the rendering optimized. My testing indicated at least double the polygon rate when lighting is replaced with GL_UNSIGNED_BYTE vertex colors. What you could do is calculate static lighting for the map, and use OpenGL lights on dynamic objects.

I have little direct OpenGL experience, but I have a considerable amount of knowledge of 3D development on other platforms. With that in mind...

Quote:Originally posted by Jake 1) Right now for testing about all of my textures are 256x256 mipmapped. Mipmapping INCREASES performance right? also, how much of a performance increase will I get from going down to 128X128 or even 64x64?

Mipmapping will typically decrease the cost of fetching texels from your textures. This only improves your performance if you are memory bandwidth bound, and it does not sound like you are.

Quote:
2) Does the CPU or the video card do all the translations, because with 3 vertice per triangle and ALOT of triangles, thats ALOT of math for a CPU to do!

This will depend on a lot of things -- which GPU you have, which drivers you are using, and the details of your OpenGL state. Most modern (Radeon-class) GPUs will do the transform/light/project in hardware. If you are using a vertex program and your card doesn't support vertex programs in hardware, however, you will likely fall back on the vertex program emulator in the CPU.

Quote:
3) How much does lighting effect speed? Right now i'm using an ambient and a diffuse light.

It can have a considerable impact on vertex processing speed... if that is your bottleneck then it will impact your performance. In your case, however, you are spending all of your time submitting, not processing.

Quote:
4) Will full-screen help out a little bit? (maybe 10%?)

Probably not. I believe (hope?) that the page flip happens asynchronously (i.e. you don't spend any time waiting for it) and since you're not pixel rate bound there should be no reason that running full screen could benefit you.

A piece of advice:

It is very important to realize that on virtually all modern hardware the GPU can deal with the geometry much faster than the CPU can. You should do everything you can to avoid touching the individual vertices. Your program should operate on blocks of vertices which you can pass to OpenGL and have it work away completely in parallel. This applies to what is happening internally to OpenGL as well -- the various vertex array extensions are provided so that the OpenGL software doesn't have to do anything other than tell the hardware where to get the data.

This is more important than triangle culling at a fine level. I have seen cases where it was much much faster to just draw all 1,000 triangles rather than try to figure out which of the individual 10 triangle models to draw. At some point you do want to apply culling to your models, but given how fast graphics hardware is these days that point is suprisingly high.

Another side effect of this is that you want to minimize state changes. Lump everything you can into the largest batch size you can make and draw it all at once.

Quote:Originally posted by Jake thanks for the advice Programmer and inio!

My FPS have went up a bunch after I got the program to check only a few polygons for collisions instead of all 5000 of them.

Almost ready for a beta

Collisions are generally done on the CPU (unless you're getting really advanced) so any culling you can do there will help tremendously. Things like sphere trees and mesh simplification can help with this.