to clarify the result returned is the num of pixels/frags that pass the depth/stencil test
eg a model that covers just one pixel onscreen can return a figure much higher than one because the same pixel can be written to multiple times.
im writing to a 64x64 sized window thusmax number pixels covered is 4096 yet im getting sometime > 30,000 with the following
-There are many situations where a pixel/sample count, rather than a
boolean result, is useful.
Objects that are visible but cover only a very small number of
pixels can be skipped at a minimal reduction of image quality.
Knowing exactly how many pixels an object might cover may help the
application decide which level-of-detail model should be used. If
only a few pixels are visible, a low-detail model may be acceptable.
Occlusion queries can replace glReadPixels of the depth buffer to
determine whether (for example) a light source is visible for the
purposes of a lens flare effect or a halo to simulate glare. Pixel
counts allow you to compute the percentage of the light source that
is visible, and the brightness of these effects can be modulated
accordingly.
This way only the first pixel written will pass the stencil test.
(Of course if you have multisampling on, there will be more than the number of pixels returned)
If you are using the stencil for something (or don’t have it) you could render twice, first to prime the depth buffer, then enable the query and render to do the count. This would only work if the geometry does not have any polygons that resolve to the same depth.
Counting the number of depth/stencil test passes is much easier for hardware, and it tells you something about whether you’re getting good early occlusion. If you’re writing samples multiple times, and shading them multiple times, it’s probably wasteful.
But as sqrt[-1] says, there are ways to use stencil to count the actual number of samples (on the screen) that are written. I would use a different technique than he described though.
Counting the number of depth/stencil test passes is much easier for hardware, and it tells you something about whether you’re getting good early occlusion. If you’re writing samples multiple times, and shading them multiple times, it’s probably wasteful.
But as sqrt[-1] says, there are ways to use stencil to count the actual number of samples (on the screen) that are written. I would use a different technique than he described though.
-clear stencil
-set stencil to 1 on depth pass
-draw objects that need to be counted in this query
-set stencil test to reject except where stencil == 1
-draw a bounding or full screen quad with an occlusion query to get the sample count
To avoid clearing the stencil for each group that needs to be tested, you can increment the stencil value from 1 up to 255 for an 8-bit stencil buffer. You can actually draw the object to the framebuffer with this approach, because it won’t kill successive fragments, if that’s what you’re after.
Edit: by increment I don’t mean any of the stencil increment functions, just the value you use.
thanks guys, yes i was sure u could use stencil to do it correctly, this part of the spec though is misleading ‘Knowing exactly how many pixels an object might cover’
and it tells you something about whether you’re getting good early occlusion. If you’re writing samples multiple times
but in the above example theres nothing u can bascically do about (apart from sorting the tris indivually based on depth)
btw cass if u wanna see the occlusion slowdown (ive mentioned before) on nv3x u can download my game here www.zedzeek.com both win + linux exes
(change occlusion in the options.txt file)
yes its hard to see the difference between the two cause theres not much occlusion but it is there
thinking about it more sqrts method aint gonna give the right results ( as only the first pixel will get written, even though it may not be the closest)
, i believe the only method that’ll work would be like AlexN descibes ie 2 passes, unless someone else knows a sinlge pass method