Hello, I have a scene rendered without any optimisation. I'm planning on using octrees, and I have my data hierarchically organised. However, I'm getting some strange results testing the speed of the raw algorithm. I have a scene with just under 2000 vertices. Here is an md2 character about to run into a bush, with an orbit camera set up: The framerate averages 125. Since I'm not using high resolution timers, this means 8ms per frame. Most of the scenery is being rendered in this view. However, when he runs into the bush the framerate drops to 76 fps. I don't understand why, if I haven't done any optimizing, there should be any difference in framerate here. The graphics card is receiving the same number of vertices. Surely OpenGL should be making a very slight increase in framerate due to the lower number of polygons inside the frustum? This problem occurs in both fullscreen and windowed mode, but the framerate is far higher in [edit]fullscreen[/edit] mode, hitting 500 or even 1000 when out of the bush, and going down to 125 when inside the bush. I'm using the following: MacbookPro 1.83, with radeon x1600 (128mb) OS 10.4.10 OpenGL and SDL GCC 4.0.2 with Xcode. [Edited by - shotgunnutter on September 29, 2007 3:32:08 PM]

The first thing that comes to mind is fillrate limitation. You are suddenly filling the screen with a lot of polygons, and if the ones behind aren't clipped or even depth-tested out, you are re-filling over and over. In the first show you may have the same number of vertices, but you are filling a lot less of the screen.

OK, so its the density of the foliage and the way several leaves overlap when projected into 2d that causes the problem, because the graphics card is continuously re-filling the screen.

I notice that the problem is less serious when I reduce the depth buffer to 12 bits (from 24).

What system of culling should I use for foliage of this nature?

Being a primarily 2d programmer of OpenGL, I myself have never had to solve this problem. However, OpenGL says this (IIRC): Enable culling and depth testing, and draw your polygons front to back. This would mean you have to sort them in shortest distance from the camera to the furthest, and draw them in ascending order.

Well these are all above my target frame rate of 60 when in fullscreen mode. I've only tested this on a core duo and an x1600 however. I expect when I start using frustum culling I can reduce the amount of data going to the graphics card, and get better speeds out of lower spec cards.

Well I'm well below that spec- (Sempron 3400+ and 6600GT) so just PM me if you want a lower end tester and I can tell you whats up.

Likely this is occuring because Alpha testing breaks Early-Z.

On modern hardware, Early-Z allows the pixel shader+textures to not be evaluated when the depth test will fail.

However, since alpha testing requires that the 'alpha' must be read from your texture before it can be determined to be visible, the texture lookup (+pixel shader) per pixel in the polygon must be executed anyway; hence Early-Z does not have an effect.

Sadly there's not much you can do about this if you want to use alpha-testing. Just make sure that you don't have lots of dense, overlapping alpha-tested polygons and that they don't occupy the majority of the screen.

http://http.download.nvidia.com/developer/GPU_Gems/Sample_Chapters/Graphics_Pipeline_Performance.pdf
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1393798&SiteID=1
http://ati.amd.com/developer/SIGGRAPH04/Scheuermann_HairSketchSlides.pdf