On Nov 30, 2007 5:36 PM, Paul Martz <[EMAIL PROTECTED]> wrote: > > > 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.
Yeah, given the complex nature of the problem it seems to me a very good and general solution. The one frame latency shouldn't hurt too much anyone, and if it does, it means that the frame rate is already very low and the scene is moving too fast compared to the frame rate, which means that the user is anyway annoyed by the lack of interactivity, or that objects are moving so fast that you can hardly see them, but at decent frame rates let's say already above 20 or so the one-frame-latency should hardly be noticeable. Thank you for sharing this info, bye, Michele > 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 > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
