hi gang,
the occlusion query extension is asynchronous. that is, you submit
query geometry, and later check to see whether the results of the
query are ready. essentially, a query inserts a token in the gl
queue, and when it pops back out the end of the pipe, a
glGetQueryObjectivARB will return that a particular query id is now
ready. if you actually _invoke_ the data query and it's not done, it
will block. so don't do that. :)
so, i've used this extension since sgi first introduced it with the
320/540 NT boxes (remember those? sniffle.). i did a lot of work with
CAD/CAE companies who need to render lots of geometry, and we used
this test for dynamic occlusion culling, performed by the harware.
here was the rough algorithm:
1) render the likely occluders (determined either from the previous
frame, or from
an initial guess).
2) instrument the rendering of a variety of smaller objects with proxy
geometry (bounding boxes, typically), by using the occlusion
query extension tokens
3) now, start rendering 'real' geometry.
4) checking every few objects to see if query results are back.
5) when query results are positive, check to see if object is
occluded or not, and
render as necessary.
6) keep track of overall occluded/not-occluded objects, and use a
heuristic like
'large-objects near the eye that were not-occluded last frame'
as the seed for
step 1) for the next frame.
the overall cost of this was virtually zero, and it had the very real
consequence for
many typical cad scenes of improving performance by a few 100 percent...
bob
On Dec 12, 2006, at 11:57 AM, Robert Osfield wrote:
Hi Zach,
On 12/12/06, Zach Deedler <[EMAIL PROTECTED]> wrote:
Well I want the sun glare to be potentially occluded by everything
in our
scene. So if a small sign post occludes the sun, I want it to
affect it.
In a driving simulation the one frame delay will not be noticeable
guaranteed. At least when talking about scaling a lens flare.
It sounds to me like you guys think occlusion querying the whole
database
for the sun would be taxing? Maybe I should go back to querying
the depth
buffer then?
The actual depth query probably won't be very expensive down on the
GPU, its waiting for the results to get to you on the CPU which is a
potentially block, its the flush of the fifo and round trip to the GPU
which is performance bottleneck.
Getting the results after swap buffers then altering your affect for
the new frame is the way to hide the latency and avoid blocking, but
this has the hit of being one frame out of date.
Robert
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
