Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 8 of 8

Thread: Test for visibility

  1. #1
    Junior Member Newbie
    Join Date
    Apr 2000
    Location
    New Zealand
    Posts
    12

    Test for visibility

    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.

    Ciao...
    SHAYDE

  2. #2
    Advanced Member Frequent Contributor
    Join Date
    Feb 2000
    Location
    London
    Posts
    503

    Re: Test for visibility

    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.

  3. #3
    Junior Member Newbie
    Join Date
    Apr 2000
    Location
    New Zealand
    Posts
    12

    Re: Test for visibility

    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.

    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.

    Ciao...
    SHAYDE

  4. #4
    Advanced Member Frequent Contributor
    Join Date
    Feb 2000
    Location
    London
    Posts
    503

    Re: Test for visibility

    :: 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.

  5. #5
    Intern Newbie
    Join Date
    Mar 2000
    Location
    UK
    Posts
    36

    Re: Test for visibility

    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.

  6. #6
    Advanced Member Frequent Contributor
    Join Date
    Feb 2000
    Location
    London
    Posts
    503

    Re: Test for visibility

    Fatbuddha, I think he was hoping to do occlusion culling, rather than just view frustrum culling.

  7. #7
    Intern Newbie
    Join Date
    Mar 2000
    Location
    UK
    Posts
    36

    Re: Test for visibility

    Maybe

  8. #8
    Junior Member Newbie
    Join Date
    Apr 2000
    Location
    New Zealand
    Posts
    12

    Re: Test for visibility

    Yes, the question was relating to occlusion-culling research. Back to the drawing board!

    Ciao...
    SHAYDE

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •