Another common use of the Occlusion Query extensions is to delay the results one frame. This follows the same parallelization used for cpu-limited apps, where you grab the results from the last frame and use them on the current. This method works quite well on its own and hardly noticeable to the end-user (particularly if you use some basic heuristics that can override the query results).
Two added features of the Occlusion Queries is that they are geometry independent (if you can render it, it works) and it's very precise. Unless you toss out many rays, you often run the risk of getting false positives. Since the queries return # pixels the object would occupy on screen, you can use this information for all kinds of nifty effects. (e.g. intensity of sun base on % of pixels drawn) E. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Monday, December 11, 2006 13:29 To: 'osg users' Subject: RE: [osg-users] Sun occlusion I think (hope) the occlusion query should not flush the rendering pipeline like glReadPixels. glReadPixels absolutely clears the contents of the rendering pipeline in order to retrieve the results. Occlusion query, on the other hand, allows the pipeline to stay full while results are retrieved. If you use the feature correctly, you're subject to the inherent roundtrip and readback latency, but shouldn't experience the latency associated with filling an empty rendering pipe after the results are retrieved. (Warning: apps can abuse this feature. If you issue a query and immediately block for the results, then yes, that will completely flush the pipe.) -Paul > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Robert Osfield > Sent: Monday, December 11, 2006 2:41 AM > To: osg users > Subject: Re: [osg-users] Sun occlusion > > Hi Zach, > > The highest quality solution would be to use the occlusion > querry extension which will return how many pixels of an > object are rendered. > This does require a round trip to the graphics hardware > though so could be slow as you'll have to wait for the > graphics pipeline to be flushed through before you can get > your results. > > Using CPU based intersection tests would probably be faster > as long as you don't have too complex geometry and too many > segment tests, I'm very surprised that you are seeing a > performance hit of down to 5 Hz with doing this - the drive > manipulator does a number of tests and doesn't typically break frame. > > I'd recommend having a look at the timing of your > intersections to see what might be causing it to be so slow. > > Robert. > > On 12/10/06, Zach Deedler <[EMAIL PROTECTED]> wrote: > > Hello, > > > > PROBLEM > > I want to change the size of the sun's glare dependent on > if it is occluded. > > > > INVESTIGATION > > I implemented this using the computeIntersections function. > > I convert the sun's 3D coordinates to screen coordinates. > > I check for about 6 intersections with various points on the sun. > > This affects performance by about 5Hz. > > Checking for 1 intersection still affects frame rate greatly. > > > > QUESTION > > 1) Anybody have ideas how to make this more efficient? > > 2) Would the LineOfSight class be better to use? > > 3) Would using the depth or stencil buffers be better? If > so, how do > > I query the depth buffer? > > > > Thanks. > > > > Zach > > > > _______________________________________________ > > 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/ _______________________________________________ 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/
