Anyone any idea if it's possible to do occlusion Queries on a per triangle basis in gl? Only wanting to know if any fragment passes the depth test for each triangle.
I think if you call glFlush then glFinish (before and after the triangle?) you should be able to use the tests per triangle. It'll be slow though.
Jim
yep, that was a crap idea.
It's a great idea, I used it on a 3dfx once - render an invisible bounding quad of some complex piece of geometry, say a 250 polygon character, and see if it's worth drawing any of it - but the cards today are using so much buffering to keep the speed up that you completely ruin the pipeline by waiting for your triangle.
Jim
Since at the moment I'm only using 1 TU and doing the rendering in quite a few passes I thought it might be worth it to test each tri on the first pass so I don't have to bother about them later but it really slowed it down. I see how it could be useful used with bounding boxes or whatever around an object though.
Jim,
How do you do that? I mean how do you test to see if the quad renders any fragments?
The 3dfx had counters which were accessible through the Glide API. So you could retrieve the current fragment count for a number of things, like z buffer hits,
typedef struct GrSstPerfStats_s {
FxU32 pixelsIn /* # pixels processed (minus buffer clears) */
FxU32 chromaFail; /* # pixels not drawn due to chroma key test failure */
FxU32 zFuncFail; /* # pixels not drawn due to depth test failure */
FxU32 aFuncFail; /* # pixels not drawn due to alpha test failure */
FxU32 pixelsOut; /* # pixels drawn (including buffer clears and LFB writes) */
} GrSstPerfStats_t;
So you could sync the renderer (slow) check the pixel count, render a quad, sync and check it again.
It worked OK on the original 3DFX card, but I think one of the counters was bust on the Voodoo2.
Jim