What kind of hardware are you working on? Can you confirm the CPU load while your program is running (simply look at Task Manager, it gives a little clue what's going on).

Alpha testing via discard or clip is always slower than shader without it. Only thing you can do about to not use alpha testing (clip / discard) in shaders which don't need it. Alpha blending of course takes even more fill rate.

Cheers!

What kind of hardware are you working on? Can you confirm the CPU load while your program is running (simply look at Task Manager, it gives a little clue what's going on).

Alpha testing via discard or clip is always slower than shader without it. Only thing you can do about to not use alpha testing (clip / discard) in shaders which don't need it. Alpha blending of course takes even more fill rate.

Cheers!

My hardware is i7 920 CPU and GTX 260, so should not be too bad.

The CPU load is pretty much 100 % for a single core, regardless of how much stuff is being drawn. I don't limit FPS explicitly.

The CPU load is pretty much 100 % for a single core, regardless of how much stuff is being drawn.

So can we deduce here that your program may be (at least partly) be CPU bound? If your program was GPU bound, the CPU usage wouldn't be 100%. Of course we have to keep in mind that drawing forest quantity of trees takes its toll too.

Are you doing some CPU intensive stuff every frame? How are you sending your geometry to your GPU?

Cheers!

[quote name='jmakitalo' timestamp='1338322729' post='4944421']
The CPU load is pretty much 100 % for a single core, regardless of how much stuff is being drawn.

So can we deduce here that your program may be (at least partly) be CPU bound? If your program was GPU bound, the CPU usage wouldn't be 100%. Of course we have to keep in mind that drawing forest quantity of trees takes its toll too.

Are you doing some CPU intensive stuff every frame? How are you sending your geometry to your GPU?

Cheers!
[/quote]

I think the CPU load is 100 % because I'm not limiting the framerate in anyway, so the program updates and draws as frequently as possible. Basically
I have a loop which calls update(), draw() and checkInput(). A frame time is evaluated for each cycle and this is used for updating stuff. Maybe the
updating should be fixed to 30 times per second or something. So even if there is not much to draw, CPU usage is 100 %.

For sending the geometry to GPU, I use static VBO with glDrawElements. I think this part is pretty well managed, as the buffers and textures are bound only once
per tree type, so basically once per drawing the whole test scene. The tree branches and leaves use the same vertex position etc. buffers, but they have their own
index buffers.

Nothing else to do, I tried some sprite-like tree drawing by using my static mesh renderer. I placed around 8000 meshes consisting of two triangles, to get some feeling how well impostor drawing could look like or perform. At first I got again 30 fps in many places, which seemed a bit depressing. The mesh shader is a bit too complicated with normal mapping and so on, but mesh rendering uses the same system as the actual tree rendering, so states and binds are sorted.

Then I decided to change the order of drawing my terrain and the meshes, and this had a significant impact in cases when the trees block most of the terrain. I got steady 60 fps in such cases. So maybe my terrain fragment program is a bit demanding, but it still does not explain the poor performance with the more detailed trees. I tried also rendering first the detailed trees and then terrain, but there was no gain.

Here are some screenshots of the simple two-triangle trees:

tree1
tree2
tree3

To me it seems that only the few front most trees should be rendered with detail and other could be drawn as it seems in the figure. Of course this
can depend on the tree types. Could work well just for the spruces. I'm also a bit worried about the complexity of impostor scheme implementation.

I'm quite sure that for the game that I'm aiming at, the trees would not be viewed from very high positions. Do you suppose that it would work, if I precomputed for each tree type, a set of impostor textures for different view angles (rotations around the tree axis)? A texture would then be selected based on the orientation of the tree relative to the camera. There could be e.g. 20 different angles and the textures would be placed in a texture array, so that only one bind would be needed per tree type. Of course the switch from one texture to another could be noticable, but texture arrays should enable the use of more textures. One could also mix between the textures smoothly in the fragment shader. The textures would need to be update only when the lighting (or time of day) would change. I feel that this could be more suitable for this specific case, rather than a general impostor system. Do you think that this would give notisable perspective errors, if the impostors would be used for trees, say, at least 50 m away?

I'm quite sure that for the game that I'm aiming at, the trees would not be viewed from very high positions. Do you suppose that it would work, if I precomputed for each tree type, a set of impostor textures for different view angles (rotations around the tree axis)? A texture would then be selected based on the orientation of the tree relative to the camera. There could be e.g. 20 different angles and the textures would be placed in a texture array, so that only one bind would be needed per tree type. Of course the switch from one texture to another could be noticable, but texture arrays should enable the use of more textures. One could also mix between the textures smoothly in the fragment shader. The textures would need to be update only when the lighting (or time of day) would change. I feel that this could be more suitable for this specific case, rather than a general impostor system. Do you think that this would give notisable perspective errors, if the impostors would be used for trees, say, at least 50 m away?

We more or less did this on a project at a previous company I worked at. We rendered the objects out into a grid where the cells mapped to a range of polar coordinates. We also rendered out minimal gbuffer for the object and lit the sprites like you would in deferred lighting. Perspective errors were there, but were never bad enough to care about, given the number of angle cells we used.

[quote name='jmakitalo' timestamp='1338461817' post='4944935']
I'm quite sure that for the game that I'm aiming at, the trees would not be viewed from very high positions. Do you suppose that it would work, if I precomputed for each tree type, a set of impostor textures for different view angles (rotations around the tree axis)? A texture would then be selected based on the orientation of the tree relative to the camera. There could be e.g. 20 different angles and the textures would be placed in a texture array, so that only one bind would be needed per tree type. Of course the switch from one texture to another could be noticable, but texture arrays should enable the use of more textures. One could also mix between the textures smoothly in the fragment shader. The textures would need to be update only when the lighting (or time of day) would change. I feel that this could be more suitable for this specific case, rather than a general impostor system. Do you think that this would give notisable perspective errors, if the impostors would be used for trees, say, at least 50 m away?

We more or less did this on a project at a previous company I worked at. We rendered the objects out into a grid where the cells mapped to a range of polar coordinates. We also rendered out minimal gbuffer for the object and lit the sprites like you would in deferred lighting. Perspective errors were there, but were never bad enough to care about, given the number of angle cells we used.
[/quote]

Thanks for sharing that. Maybe I'll give this a try.