No, it’s just not practical to have that kind of 2 way communication with a card - certainly not in a reasonably low level api like opengl. I don’t care how fast your gpu is, you will never benefit from this approach. So, do the work yourself on the CPU.
Blimey, it’ll soon come to a point where peoples CPU’s are 99% idle most of the time.
The occlusion test functionality exposed recently on nvidia hardware is for very special cases - it goes against the grain of opengl, but it is useful in a very limited number of cases.
The occlusion extension is very useful if you store the results of previous tests and use them in the later occlusion queries as reference. This reduces communication with the graphics card and moves most of the occlusion calculations to the cpu.
So basically I use the extension to get a crude mask of areas that are occluded. Then I check the boundingbox of an object against that mask (done on the cpu) before resorting to the use of the extension. The system is still very much in-development and needs a lot of optimizations. However, it already minimizes an occlusion query to a couple of if-statements instead of a bunch of gl-commands and communication with the graphics card.
Well, I’ve tried and I failed. I tried to explain what OpenGL is (see: section titled ‘Our view’ in the glspecs) in admittedly brief words. Then I’ve taken it to the extreme to demonstrate it a little further
Originally posted by Humus:
[b]GL_ARB_friendly_forum_where_people_doesnt_try_to_make_fools_out_of_people_with_regards_to_honest_ideas_regardless_of_how_silly_you_think_it_is
