Sign in to follow this  

Hardware Occlusion Queries - question

This topic is 3320 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Has anyone implemented hardware occlusion queries using temporal coherence? I've already implemented a form of ray-traced occlusion culling in the terrain rendering part of my engine, and whilst it's relatively fast, it isn't wholly accurate. It never shows errors (i.e. patches not appearing when they should), but it can show them when they shouldn't be there (depending on your viewpoint). I'd just like to compare my occlusion culling with hardware queries. I've read the GPU Gems 2 article "Hardware Occlusion Queries Made Useful" by Wimmer & Bittner and done some other research and I have a question about the implementation (if anyone has successfully done it). There are two parts to their relatively simple implementation; part 1 processes any finished occlusion queries and part 2 traverses the tree (quadtree, octree, kd, etc). Part 1 has precedence over part 2 which is understandable. My query lies with part 1 which is (in pseudo):
TraversalStack.Push(hierarchy.Root);

while ( not TraversalStack.Empty() or

        not QueryQueue.Empty() )

{

    //--PART 1: process finished occlusion queries

    while ( not QueryQueue.Empty() and



         (ResultAvailable(QueryQueue.Front()) or

          TraversalStack.Empty()) )

    {

       node = QueryQueue.Dequeue();

       // wait if result not available

       visiblePixels = GetOcclusionQueryResult(node);

       if ( visiblePixels > VisibilityThreshold )

       {

           PullUpVisibility(node);

           TraverseNode(node);

       }

    }

    // onto part 2
    ...
The nature of hardware occlusion queries is apparently that you can issue one and possibly not get the result in the same frame. That said - the problem I have is understanding this line: //wait if result not available In essence, part 1 says that whilst there are occlusion queries in the queue and there is a result available _OR_ there is no traversal stack to recurse (part 2), check the next available query result against the threshold and process that node/patch accordingly. In my implementation, what happens is once the traversal stack is empty and the code hits the inner while loop, the occlusion query result is not available so my 'wait if result not available' code sits there waiting.. and waiting.. If some occlusion query results will not be available in the current frame (which is a point made in the aforementioned article), why would you wait until all of the results are available? This causes a CPU stall. In my case it causes a block which I think is because the GPU is not doing anything else. Do hardware occlusion queries a) always return if you give them long enough or b) are they dependent on the GPU having enough commands to process. If the answer is a), the // wait if result not available is incorrect. Thanks for any advice.

Share this post


Link to post
Share on other sites

This topic is 3320 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this