Hi,
my program does its own backface-culling, so i disabled OpenGLs backface-culling.
However you can tell OpenGL to render the front- and back-faces of polys differently via glPolygonMode.
So now my question: Is it faster to tell GL only to draw frontfaces (GL_FRONT with GL_FILL), or is it faster to tell it to draw both (GL_FRONT_AND_BACK).
I would say that the latter should be faster, because then it would not need to test if the face is front or backfacing.
Or is both equally fast?
Basic questions…
Originally posted by Jan2000:
my program does its own backface-culling, so i disabled OpenGLs backface-culling.
Let OpenGL do the backface culling, it’s faster.
You should only cull complete objects, not triangles.
However you can tell OpenGL to render the front- and back-faces of polys differently via glPolygonMode.
I would say that the latter should be faster, because then it would not need to test if the face is front or backfacing.
Believe me, it’s slower.
It’s not necessarily slower to do your own backface culling – e.g. you could make use of clustered BFC, which is more efficient than regular BFC. Doing your own BFC on a per-triangle basis is a definite no-no, though.
Changing the rasterization mode only for backfaces is rather pointless, though: if you use backface culling, backfacing triangles won’t get rasterized at all. If you’re using a conservative BFC mechanism (like clustered BFC as mentioned above), I still recommend enabling the OpenGL BFC as well.
– Tom
>>Doing your own BFC on a per-triangle basis is a definite no-no, though.<<
on my vanta(tnt2) doing your own bfc + then passing the tris to gl is about 10% quicker than letting gl do the culling.
though (i havent tested) on a hrdware tnl card will be a ‘nono’
By doing my own bfc, I can get rid of a lot of tris earlier. Then I wont have to collisiondetect those and so on. Is it a better choice to let gl do bfc in a real app like a game?
By doing my own bfc, I can get rid of a lot of tris earlier. Then I wont have to collisiondetect those and so on.
You have to do collision detection on backfacing polygons too. Just because they are not visible it doesn’t mean that nothing can collide with them.
I’ve heard of problems with app-side BFC where the app’s calculations are slightly different from the driver’s. If the app thinks an edge-on poly is frontfacing but the driver/GPU thinks it’s backfacing, you could end up with cracks.
Personally I’d only disable GL’s BFC for completely clear-cut situations like billboarded particles. For normal meshes, if you’re doing app-side culling as well, allow a margin of error to make sure that borderline cases get sent.
[This message has been edited by MikeC (edited 02-18-2002).]
Yeah, I know, stupid me! Must have been up to late again…
But what about if I perform raycast-culling like in Oni? Guess I’ll have to test.
MikeC has an interesting point about on edge errors. Although I haven’t really noticed an issue with on edge errors and doing my own culling I haven’t really tried it. You in a way end up doing your own back face culling if you are using a bsp tree for example. Basically I would always let the driver to the culling except in a case where I was going to do the normal/dot product anyway (for lighting for example). Basically if you are gonna do the calculation anyway then disgard the tri but otherwise let the driver do it.
Hardware T&L should always win over any software math. But at the same time less geometry over the agp bus is definately good. But again at the same time its worth a few extra tri’s going over the bus only to have the card disgard them as backfacing.
A few xtra tris over the bus? More like 50%.
This sounds like yet another case where you should benchmark the target platform (at run-time) for finding out the best solution. For instance, if you’re sending your calls over a 10/100 Mbit/s network you should definitely gain alot if you do your own BFC. Poor software-drivers (non-TnL) may be another example. In the general case I would go with OGL BFC, especially as you normally want the card to do TnL.
Hmmm… Has anyone really answered the real question??? Is it faster to disable BFC when you know that all your polys would pass the test (e.g. billboarding)? I think it would be faster (at least not slower) - again, why not benchmark?
[This message has been edited by marcus256 (edited 02-21-2002).]