Say I want to draw a quad on the screen (say, like something covering a door to another room), is there a way to detect if any of that quad actually got drawn... (detect if it was fully occluded by other geometry...) Is there a way to count the number of pixels it actually effected? How about a way to detect the number of depth tests passed as opposed to those attempted (without counting the stencil buffer... aka, setting the stencil to 1 if depth failed, and 2 if depth passed, then go through the buffer and count the number of 2's vs the number of 1's and 2's... that make sense?) Just wondering if there's a built in DirectX api way of detecting these changes... since counting the stencil changes (ala reseting the stencil buffer everytime I need to draw a new portal/effect and then locking/copying the stencil buffer to read) seems a tad slow for my tastes... (I read something in an article once about improving a particle engine by detecting what was drawn last frame, and if something wasn't drawn, marking it as not visible as long as the camera didn't move... but it never said how to detect if nothing was drawn to the screen).

Regarding queries, start here - it even has a snippet of code for basic occlusion querying:



Bare in mind that the final while() loop can stall the application and actually hurt your overall performance. Because of the way the hardware/drivers implement the D3D pipeline the results may not be immediately available (I've read a few places saying it can take multiple frames)...

hth
Jack

Hmm, seems interesting, thanks for the link... I'll have to test whether stencil testing or using the D3DQuery is faster for the effect I'm trying to pull off...

Again, thanks for the replies... Can't wait to get done with work and try it out...

Quote:Original post by jollyjeffers
Bare in mind that the final while() loop can stall the application and actually hurt your overall performance. Because of the way the hardware/drivers implement the D3D pipeline the results may not be immediately available (I've read a few places saying it can take multiple frames)...

It's not that it can stall your app - it's that it will. Generally, applications that use occlusion queries in an attempt to predicate rendering actually do the complete opposite - their performance actually becomes worse.

Note that with D3D10, you can use occlusion queries efficiently for things like this.

I recently used occlusion queries for a lens flare effect, and found what circlesoft said to be very true. If i loop for the results using D3DGETDATA_FLUSH right after the request it takes about 1 millisecond, which is a lot of time for such a small effect. If i check for the result every frame without flushing it can take anywhere between 3-20 frames (about 15ms each) to get a result, but the CPU doesn't stall. I ended up waiting a frame before getting the results and then looping with D3DGETDATA_FLUSH. My performance counters show that using this method every fifth frame or so I get a query for free. I'm not really sure why though.