On 12/12/06, Paul Martz <[EMAIL PROTECTED]> wrote:
> I would expect the occlussion querry will be similiar to
> glReadPixels as for both you have to flush the contents of
> the OpenGL fifo in front OpenGL call to retrieving the
> results, the only way to avoid this is to not querry for the
> results time after most the frame has been drawn. If the
> special effect that requires the pixel coverage count can be
> drawn after then rest of the scene then potentially things
> will might be doable within one frame.
The usual way this is ensured is to use the occlusion result from the
previous frame in the next frame's rendering. This is easily done in apps
with strong frame-to-frame coherency.
I'm curious how many apps would qualify for using occlusion results
this way. I would have thought that in most graphics apps the view
point and objects in the scene would move too much between frames for
their to be enough frame coherency to rely on occlusion queries from
the previous frame.
The new/up coming OpenGL extension that allows one to do an occlusion
query then rendering something if the query passes would be a real
winner, no round trip between the CPU and GPU is required.
This new extensions doesn't help in sun occlusion query though :-)
In the case of Zach's needs I do wonder if rendering at 60+Hz will be
enough to hide the fact the glare effect is computed based on the
previous frame rather than the current frame. It certainly shouldn't
be as critical as using the occlusion query results as to whether to
cull a subgraph or not.
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
