Have anyone tried using Frustum Culling to speed up the rendering in a game? I don’t know why even I have implemented such method, there is not much improvment in the FPS…(Even I have tried the sample in game tutorial, I find that even I have done the frustum culling, there is still not much improvement from the sample…)
It depends on the application. But if you’re drawing a significant number of triangles you’ll find that frustum culling is absolutely necessary to get a decent framerate.
For a reasonable field of view (say, 45 to 60 degrees) frustum culling will cause you to send less than a tenth of your geometry to your graphics card on average.
For static meshes, use display lists, and do not do your own frustum culling.
Sorry, could you explain why? And in what case should I use frustum culling? And is dynamic meshes referred to some meshed generated in run-time? (ie. currently I am loading a heightmap to generate the terrain, it is static one, right?)
Originally posted by ZbuffeR:
In fact, if you do culing yourself :
- the CPU has to compute what is viewable and what is not : slow with many triangles
- you have to send to the GPU the (new) data at each frame : slow with many triangles
If your terrain has a HUGE number of triangles, you can split it in several regions, put each on a display list, and do basic culling on the cpu for each region. So you avoid totally the problem 2) and limit severely the problem 1).
Hope I explained it well.
PS: to start, forget the culling totally, it will not be useful if you have less than about 500x500 triangles.
[This message has been edited by ZbuffeR (edited 01-10-2004).]
Thanks very much for your detailed explaination. Um... I am going to make a terrain which is going to accomodate near hundred users, so. I think the terrain size will be over 100000 x 100000. um.. I think your opinion is good actually..but just because I am new to computer graphics.. it is rather difficult for me to think of how to speedup the rendering and do the culling
Start first with much less triangles, just a little advice.
You can have a super-large terrain with only 2 triangles you know.
After you have a working prototype, you can think about LOD, culling, etc. to have much detailed terrain. But do not try to do everything at once.
Maybe you should explain how you did the culling first. Are you using a hierarchical approach?
check this out, it might help you. http://cslab.wheaton.edu/~dthulson/projects/Pirates/frustum.html
First get it to work.
THEN make it fast, if it turns out it’s not working fast enough.
I am always a little suspicious when frustrum culling becomes an abolsute necesity. Could your data be sorted pre-rendering in such a way as to avoid having to frustum cull so much data anyway?
For example BSP trees or portal rendering. If your data largly is static, BSPs allow rendering without depth-testing.
Perhaps you could use frustum culling but group your data in such a way so that large chunks of data can be culled by one test.
I guess my point is, if you are culling really small groups of objects, you may be wasting your time.
Originally posted by Dr Dogg:
I am always a little suspicious when frustrum culling becomes an abolsute necesity.
Why? If you are not culling your space partioning structure against a viewing volume, how are you doing your gross culling?
Unless you want to pre-calculate a lot(PVS).
If your data largly is static, BSPs allow rendering without depth-testing.
If you use bsps with the intent to not use depth-testing you need to split every polygon that crosses splitting planes. Studies have shown that this will severly increase your polygon count. It could be good to manage transparent surfaces though.
When talking about frustum culling and performance in general, I’d like to recommend this document about batching from NVIDIA. http://developer.nvidia.com/docs/IO/8230/BatchBatchBatch.pdf
[This message has been edited by roffe (edited 02-03-2004).]