does anyone know where I can get some resources on view frustum culling. I want to increase the perfomance of my app (by not sending down so many polys to the geometry engine) thanks
Well, there is no particular trick…
OpenGl already uses 2D,3D clipping via the transformation pipe… Thus if you want to use hardware transformations it could be interesting to get an ‘optimized’ | ‘low detailed’ version of your scene using 3D boxes or 3D blocks… and then with a software
transformation engine mark or determine which sets of ‘hi-res’ primitives will be visible and then send only them to OpenGL…
Of course simple backface culling always help
to kick approximately 50% of primitives… I don’t think that occlusion culling would help
to get fastest rendering bcoz it also cost a huge amount of cpu time in rendering the occlusion buffer and moreover the gain on the
entire scene is approximately 30% more than
backface culling… Try first to send a minmum of points to describe your entire scene via strips or fans… forget triangles.
Changing the scene is not an option. I am reading in a file (OpenFlight) and displaying it for realtime simulation purposes. I need an algorythm that will cull out the faces (groups maybe) before sending them to gl…therefore they are never clipped by gl down the pipline they don’t exist (at least this time) Thanks
seems like you need early culling…
the simpler implementation costs 3 adds and 3 mults per face… how many faces you’re willing to render in a frame?
I don’t know, but I would like to see some info on early culling if possible
i seen some infos about EC somewhere… probably on gamasutra.
however, i reinvented the wheel a year ago before i knew that the algo was yet published… oh, well… i made a performance test application to see how effectively it could improve rendering speed.
it effectively improves rendering speed :
the bigger the model (or the number of primitives you’re willing to send) the higher is the difference in FPS.
i can’t give you a compilable source, only the main and the part where EC is performed.
the application is about 700k: it uses unextended gl and works on every card, afaik.
email me if you’re interested.
Take also a look at octrees. They’re a hierarchical data type used to partition the 3d space. You’ll find infos on them at Gamasutra and flipCode.
how you going frogger, latest news?
Still working dilligantly after a short vacation, but I thought I might write something of my own
I might be wrong about what your are trying to say exactly, but there is an extension called EXT_cull_vertex and is VERY efficient.
But I’m sure you know all that…so for the benifits of others… here it goes!
When you renders polygons on the screen, GL in background performs a face culling test based on the projected vertices used by the fragments. In simpler, GL renders only polygons that face the camera (you)!
This NORMAL test can be non efficient, cause it requires 2 matrices calculations, normalizing and convert to device space (window coordinates).
On the other hand, the EXT_cull_vertex gets all non visible vertices out of the pipeline ASAP, which prevents polygons that are NOT facing the camera(you) from being rendered. Look at the EXT documentaion for details…
A nice and fairly CPU friendly approach is to first do a Bounding Sphere Object culling on all objects and then let the
EXT_cull_vertex to the rest.
And if you are the hardcore high-frame-rate type, implementing a state sorting by grouping primities that used the same effects (textured and non-textured, lit or non-lit, and so on) is the way to go.
This will add an substantial boost to you program.
Note on that: The state sorting should (as much as possible) be precalculated before any rendering starts.
Hope this might help!
One thing you can do is to do your own backface culling on groups of polygons. You determine if the whole group is back-facing with just one test, and if it is, you don’t render it…
Maybe I am not so clear… I need an algorithym that will determine based on the current viewing volume if a polygon is visable… if it is it is sent to gl if it is not it is not sent to gl therefore we only do geometric calculations on the vertexes and polys that are possibly viewable and therefore reducing load on the gpu. Thank you for all who are replying
did you received the performace evaluation test of early culling i made?
by reading this topic through, i suppose you didn’t got my e-mail.
early culling is exactly what you need, so tell me if i have to send you again.
this also is valid for the others interested …
I’m currently playing with view culling in the little scene graph i’m writing. I’m testing object bounding boxes against the 6 planes of the view frustum - is this what you’re doing - I’d like to see the code regardless…