Im aware that this is largely system specific, but what is a good standard for determaning whether or not you have to few poly's to bother with frustrum and occlusion culling? When the code itself takes longer then just rendering the full picture? or does that even matter? let me put it this way. say I have 1 textured triangle floating around my screen. then I move said triangle off the screen. without culling im still drawing it so my FPS should stay about the same right? so then if I do cull it will I see any discernable increase in FPS or not? Or do I have to be dealing with ALOT of triangles for it to become effective? also...how does OGL deal with textured poly's that are edge on to the viewer. theoreticaly its a 2D opject, so without the 3rd dimention it should be invisible. so does OGL still render those poly's? Is there a form of culling that takes out edge on poly's if they are drawn?

You need not worry about the specifics of culling, at least not IMO. One software renderer I saw used image-space culling for half-visible triangles.

If you have a very good video card (heck, any video card), you will not see a difference with 1 triangle. Games are also build upon the assumption that rendering takes longer than logic (usually). For things like culling, you don't need to worry about the time it takes for the culling code to execute. If people could do it in DOS back in the 386 days, then we can do it with Pentium 3s and 3D accelerators.

You will need something north of 1000 polys to see some difference with culling. Culling is an optimization that you should make if you can (i.e. you can't if you are drawing transparent objects).

OpenGL does it's own culling/cliping(all offscreen polys), so if you move the triangle outside the viewport it will not be rendered, however this does take some time since it's only partialy done in hardware, so culling is advised when dealing with larger enviroments(lets say above 10k textured polys without any shaders).

Culling at polygon level in realtime is generaly a bad idea.
Instead, cull at object level.
If the object is to big(for instance your game world) then just split it up in smaller objects.

All 3d is 2D + the z value as a interpolated variable, so at render time the z value only matters when doing depth testing.
so the result of a edge on situation depends on witch way the normal is pointing, if the computer determines that it points away from the viewer, then it will not be drawn if you have your backface polygon culling turned on, else the result would be a textured line.

Ok so if OGL does its own culling, basically frustrum culling, then I really dont need to wory about that. what about occlusion culling then? understandably this only really matters with a large amount of poly's but in a truely dynamic game the poly count can go from relitively low to really high pretty fast. so working on the premise that "rendering takes longer then calculating"...that might not always be the case. Do you just turn the culling off/on depending on the poly count?

how about something as simple as say a flight simulator. im looking at my plane, from whatever angle, and I can only see half of it. no point in rendering the other half. if there a way to efficiently do that?

I suppose at this point im looking for code examples. ive googled all this but all im seeing are book references and we military enlisted cant afford to just keep buying books :-P

openGL only does offscreen culling as a result of fustrum clipping. What this means is that every triangle will be fully transformed (all vertex shaders etc) and projected into screen space, then have the 6 fustrum clip planes clip the triangle, and if nothing remains, then nothing is drawn. All you save is fill rate (shaders, textures, whatnot). So if your fill-rate bound, then you won't see any performance difference at all when doing manual object-culling. And with 1 triangle you most definitly will be fill-rate bound. However, if you are transform bound, and this is fairly common, then you definitly will see a performance boost when doing object culling.

What is the difference between fillrate bound and transform bound exactly? (still new to all this)

It simply refers to whichever takes longer. If you are fill-rate bound, your app will slow down while it waits for the graphics card to push pixels. If it's transform bound, you have to wait on them instead.
With a small number of triangles, you have few transformations but plenty of fill, so you end up fill-rate bound.
With lots of triangles, you have many transformation but not much more fill, so you end up transform bound.

ooOOOOooh...ok. I gotcha. That totaly clears up what RipTorn was saying. heh.

Ok then...how about occlusion culling? back to my flight sim thought. you can only see half the plane at any given time. no point in drawing the half you dont see...so then what?

still looking for any links to some good example source code if anyone has some. again we militants are poor. cant afford to keep buying books. :-P

Quote: Original post by Cannibal_Coder
Ok then...how about occlusion culling? back to my flight sim thought. you can only see half the plane at any given time. no point in drawing the half you dont see...so then what?

With plane, you are talking about terrain, right? If there are tons of ways to cull the not visible parts. Just a few keywords: (geo)clipmaps, geo-mipmapping, Chunked-LOD,... Occlusion is not that important if you are hight from the ground (there is not much to occlude).

im talking about culling the side of the plane(s) you cant see. though terrain is also important though I was speaking hypothetically. thx for the info anyways.