Occlusion Queries?

[Stonemonkey]

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.

[Jim]

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

[Stonemonkey]

yep, that was a crap idea.

[Jim]

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

[Stonemonkey]

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.

[taj]

Jim,

How do you do that? I mean how do you test to see if the quad renders any fragments?

[Jim]

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