[osg-users] Retrieving occlusion query results prior to swap(was: RE: Need a post-swap traversal)

Bob Kuehne rpk at blue-newt.com
Mon Oct 22 16:43:23 PDT 2007

bob kuehne -
bobkuehne at gmail.com - 734-834-2696

On Oct 22, 2007, at 6:47 PM, "Paul Martz" <pmartz at skew-matrix.com>  

> Thanks for the note, Robert --
>> The high level approach does suffer from a round trip to the
>> graphics card - you still have to wait till all the queries
>> are returned before you can dispatch the last bit of data
>> into the OpenGL fifo.  Claiming this eliminates the latency
>> is rather stretching things, it hides it a bit, bit only a
>> bit, you are still stalling the CPU till the GPU is done so
>> parallelism between the CPU and the GPU is heavily compromised.
> The total time for the hardware to generate the results is the same in
> either case, you're right. The "latency" I was referring to is a  
> visual
> latency, not a time latency per se: seeing (or not seeing) the actual
> geometry in frame N is based on query results from frame N-1.
> My current implementation suffers from this latency. I'm not pleased  
> with
> the results, and recent discussions (such as the thread concerning  
> only
> rendering when needed rather than with a continuous rendering loop)  
> indicate
> that there are OSG use cases under which such an implementation  
> would be a
> poor choice.
>> Personally I'd rather taking the hit and doing everything in
>> one frame rather than having a frame overlap and then having
>> to come up with clever frame coherency tricks to ensure that
>> you don't get false negatives in the next frame.  There are
>> certain models types that are already breaking frame by a
>> long way - i.e. hitting 10fps, so for these a round trip to
>> the GPU is relatively low compared to the potential gain of
>> culling geometry and state from the draw dispatch, for these
>> occlusion culling in frame will be a godsend.
> Yep, I'm leaning this way as well. So, then, the question becomes:  
> How to
> implement this in OSG?
>> As for mods the rendering backend, I'd suggest some sort
>> RenderLeaf extension that allows leaves to be switched off,
>> and during draw traversal the switched off leaves are
>> ignored.  The toggling code be done be the pre RenderStage
>> you set up to do the occlusion query.
> Hm. I really want all the occlusion queries to be done after all other
> "normal" rendering has finished (to maximize the chance for  
> occlusion to
> occur). So it seems I really want a POST RenderStage that issues the
> queries, then iterates looking for available results; as each result  
> becomes
> available, it checks for visibility and renders or skips the actual
> Drawables accordingly.
> Also, I don't want to limit this to Drawable-level queries. It is very
> useful to be able to perform a single occlusion query to test for the
> visibility of an entire subtree. Thoughts on that?
> I'll look into this, but look forward to any additional thoughts or
> directions  from you.
> Paul Martz
> Skew Matrix Software LLC
> http://www.skew-matrix.com
> 303 859 9466
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

More information about the osg-users mailing list