View Full Version : Test for visibility
04-04-2000, 07:55 PM
Just curious if anyone knows whether OpenGL can be set-up to report whether a polygon was successfully rendered. I have a visibility system idea which would be very rapid in hardware if there was a way of telling if a polygon, when drawn, had any parts visible, ie. was every pixel skipped by the Z-Buffer test, or did some show through.
The reasoning is I draw something like a portal polygon (actually it's an octree separator) and if any of it's pixels are visible through the Z-Buffer then render the scene represented through the portal, else if no pixels made it to the screen skip the geometry represented through the portal.
04-05-2000, 07:16 AM
No, I can't think of any way to do this in OpenGL. And there are very very good reasons why you wouldn't want to.
General rule : using ANY type of feedback mechanism in a realtime app can absolutely murder performance on hardware-accelerated systems.
Most if not all hardware drivers are pipelined. Many are very heavily pipelined; there may be a latency of entire frames between issuing a GL command and actually seeing the results on your screen.
So lets look at what happens if your idea was feasible. Suppose your driver has a 2-frame pipeline latency, and you're currently drawing frame 3 of an animation. You issue the command to draw a portal quad, and you want to know whether any pixels were affected.
Unfortunately, the actual hardware is still rendering frame 1. Before it can give you an answer, it has to finish rendering frame 1, render the whole of frame 2, and render everything you've issued so far for frame 3. Meanwhile your app is just sitting there twiddling its thumbs; it can't do anything else until you get the answer.
Then you get the answer, make your decision, and carry on issuing commands for frame 3.
But now all those commands have to go through the entire rendering pipeline - a pipeline that's supposed to take about 2 frames, remember - and until they do your hardware is sitting around twiddling its thumbs with nothing to do.
End result: in this case, your "optimization" test could theoretically wind up taking as much time as 4 full frames every time you called it.
Pipeline flushes are BAD, and most feedback functions will cause them. Avoid them like the plague.
04-05-2000, 06:16 PM
Thanks for the reply.
Surely something like a call-back system would prevent the problems you describe. For instance, my program could send the portal polygon to OpenGL with a flag saying "tell me when it has been drawn and let me know if any pixels made it through the pipeline to the screen". Then my program can continue on with other things while it waits. Mind you, that makes formatting a 3D-engine rather tricky. http://www.opengl.org/discussion_boards/ubb/smile.gif
Anyway, you have answered my question; there is nothing in OpenGL to support the above idea. I will have to do the portal visibility test in software as originally planned.
04-06-2000, 03:40 AM
:: Surely something like a call-back system
:: would prevent the problems you describe
No. The whole point of your visibility test is to determine whether you need to draw a cell FOR THE CURRENT FRAME. My point is that by the time you got a reply (via callback) you could have finished drawing that frame, and maybe the next one as well.
04-06-2000, 04:09 AM
Hi Shayde, there's always an alternative way of doing things...
I've got some fast code that can tell you if the current modelview position is in the cameras viewing frustrum, and get you the distance from the camera as well.
Send me an E-mail at Fatbuddha@hotmail.com, and I'll send you the source.
04-06-2000, 04:49 AM
Fatbuddha, I think he was hoping to do occlusion culling, rather than just view frustrum culling.
04-06-2000, 09:24 AM
04-09-2000, 12:12 AM
Yes, the question was relating to occlusion-culling research. Back to the drawing board! http://www.opengl.org/discussion_boards/ubb/smile.gif
Powered by vBulletin® Version 4.2.0 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.