Does OpenGL Clip on its own?

Started by
5 comments, last by SkinnyM 20 years, 3 months ago
I have been seeing changes in my FPS lately when i move around the camera. For example, say i dont look at the objects, the FPS goes way up, but when i do, it goes back down to normal. So is OpenGL clipping objects for me? If this is the case, what is the point of Frustum Culling? Why would someone do that if OpenGL already does it for you? Also, is there a way to turn this off? Thanks "What we do in life, echos in eternity" -- Gladiator
"What we do in life, echos in eternity" -- Gladiator
Advertisement
Yes OpenGL does do some limited frustrum culling on its own. Why would you want to turn it off?

______________________________________________________________
The Phoenix shall arise from the ashes... ThunderHawk -- ¦þ
MySite
______________________________________________________________
______________________________________________________________________________________The Phoenix shall arise from the ashes... ThunderHawk -- ¦þ"So. Any n00bs need some pointers? I have a std::vector<n00b*> right here..." - ZahlmanMySite | Forum FAQ | File Formats______________________________________________________________________________________
Frustum culling and other scene organization systems have a point because for large scenes/worlds with tons of objects, you dont want to send everything to the graphics card, because it sucks up your system bus bandwidth. every little byte you send to the graphics card uses up bus bandwidth, and its pretty easy to gobble up several gigabytes a second with large scenes...

1 GB/s / 60 Frames a second = 16.7MBs of data a frame. That may seem like alot, but it adds up really quickly in large scenes with lots of objects.

So anyhow, thats why frustum culling is useful.
Waramp.Before you insult a man, walk a mile in his shoes.That way, when you do insult him, you'll be a mile away, and you'll have his shoes.
it goes up becouse hardware culling. if you turn your camera off your scene, no vertices need to be rendered (no fragments are created as each of them fails culling). this process is done by the T&L engine (trasnformation, culling and lighting). the programmer needs to do things like culling, becouse he wants to avoid vertex data to the pipeline, that are not drawn (so he saves not only fragment creation, or whatever that is called, but transformation, and bus bandwidth)

"Knowledge is no more expensive than ignorance, and at least as satisfying." -Barrin
"Knowledge is no more expensive than ignorance, and at least as satisfying." -Barrin
one of the most expensive parts of the T&L pipeline in terms of speed is culling. What starts out as a single triangle may turn into 2 or 3 if it''s along the edge of the screen or might be culled to nothing if it''s off screen, but it still does get processed. So if you don''t want to be tranform limited (ie, vertex transformes and clipping are slowing you down) you cull objects that are off screen with the CPU (ie, gross cull, one model at a time).

However, what you discribe, having your object on screen slowing things down, is more than likly a fill rate limit.. When it''s on screen the GPU must draw the actual pixels as well, and this will slow things down. Probably not much if it''s a simple object, but it will still have an effect.

| - My (new) little website - | - email me - |
quote:
ie, gross cull, one model at a time


http://www.gametutorials.com/download/OpenGL/FrustumCulling_OGL.zip
When you do frustum culling by yourself, you generally do it using a pre-calculated bounding volume of the object.
Rejecting a bounding volume is very fast, but what you send to opengl is the geometry, not the bounding volume.. then, doing frustum culling yourself based on the aproximation of the volume of the object to be rendered is way faster than letting opengl do it for you..

This topic is closed to new replies.

Advertisement