> Just a (bunch of) question: how this nodekit works? do you > give a defined set of occluders to test the node to be > occluded against? or you try to delay the rendering of the > potentially occluded node as much as possible and test for > occlusion against what has been already rendered? or are you > using other (possibly mixed) strategies? That sounds to me > quite an interesting problematic to solve, isn't it?
In the docs/readme.txt there is an overview of how you can use osgOQ in your app, plus an overview of the algorithm. The basic idea is you insert an OcclusionQuery Node into your scene graph, and it performs occlusion testing to determine whether or not to draw its children. You don't need to specify occluders; occluders are anything that is visible. The basic algorithm: 1. During the draw traversal, perform an occlusion query using the bounding geometry of the attached children. This query uses the RenderBin number to issue the query after all opaque geometry has been rendered (to maximize chances for occlusion). 2. In a Camera post-draw callback, retrieve the results for any/all queries that were issued. 3. In the next frame's cull traversal, use the previous frame's query results to determine whether to draw the children of the OcclusionQueryNode. This approach has a couple advantages: * It minimizes pipe stalls by not retrieving queries until finished drawing. * It allows osgOQ to perform queries for entire subgraphs. * It requires no modifications to core OSG. It also has disadvantages: * When complex geometry becomes visible, there is a slight delay before it appears due to the dependency on the previous frame's results. * Have to wait until all queries are retrieved before swapping buffers. I considered a few other approaches: * In order to eliminate the 1-frame latency, I'd have to issue a query, retrieve it, and then decide whether to draw or not. Not only would this stall the pipe, but it would prevent osgOQ from being able to perform occlusion tests on entire subtrees -- the queries could only be per-Drawable in such a scenario. * I considered adding a post-swap callback or traversal to retrieve the queries. This would allow OSG to issue the swap and then retrieve the results in the post-swap callback (presumably while the GPU is idle in vertical retrace). I might still do this in the future. But for the sub-20Hz test cases I've been working with, this wasn't really critical. I hope that makes sense. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
