NV_OCCLUSION_QUERY for occlusion culling

NV_OCCLUSION_QUERY for occlusion culling

Post by Sigmun » Wed, 25 Dec 2002 22:00:42



Hi,

I want to use the NV_OCCLUSION_QUERY extention for occlusion culling in an
octree (with front to back rendering)
This is the source code for rendering the AABB containing the triangles, and
testing if they are visible.

glDisable(GL_CULL_FACE);
glColorMask(GL_FALSE, GL_FALSE, GL_FALSE, GL_FALSE);
glDepthMask(GL_FALSE);
glBeginOcclusionQueryNV(cull_box2);
glPushMatrix();
glTranslatef(bb.mid[0],bb.mid[1],bb.mid[2]);
glScalef(bb.len[0],bb.len[1],bb.len[2]);
glutSolidCube(1.0);
glPopMatrix();
glEndOcclusionQueryNV();
glColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_TRUE);
glDepthMask(GL_TRUE);
glEnable(GL_CULL_FACE);
GLuint pixelCount=0;
glGetOcclusionQueryuivNV( cull_box2 , GL_PIXEL_COUNT_NV, &pixelCount);

if (pixelCount>pixel_threshold)
render triangles of AABB with display list

Problem is, the code is slower with culling then without occlusion culling
(just rendering with display list), even though a lot less triangles are
rendered with occlusion culling. Especially when de depth of the octree is
getting bigger (>4) it slows very much (i guess because of the begin- and
end-occlusion query, i used some timing queries to find out where the
bottleneck was). Note that with depth 2 of 3 (not too many occlusion querys)
there is a significant win over non occlusion culling when e.g. inside a
certain model, but with larger octree depths the overhead of occlusion
queries and octree seem to win, and there are less fps.

In nvidia slides
(http://www.nvidia.com/dev_content/gdc2002/GDC2002_occlusion_files/fra...
) was a note : "Do other CPU computation while queries are being made "

Should i use a separate thread to perform the occlusion queries, or do the
occlusion queries already run in an seperate thread ?
Is it normal that the queries become a bottleneck when used frequently ?
With large octree depth, octree rendering without culling is even faster
then with culling (with queries). With depth 5 there are like 1000's /
10000's of occlusion queries. Can this be a bottleneck ?

How can i fix this problem ?

tia, and merry christmas ;)

Roel Martens

 
 
 

NV_OCCLUSION_QUERY for occlusion culling

Post by J anderso » Thu, 02 Jan 2003 22:59:44



Quote:

> Hi,

> I want to use the NV_OCCLUSION_QUERY extention for occlusion culling in an
> octree (with front to back rendering)
> This is the source code for rendering the AABB containing the triangles,
and
> testing if they are visible.

<SNIP>

> Problem is, the code is slower with culling then without occlusion culling
> (just rendering with display list), even though a lot less triangles are
> rendered with occlusion culling. Especially when de depth of the octree is
> getting bigger (>4) it slows very much (i guess because of the begin- and
> end-occlusion query, i used some timing queries to find out where the
> bottleneck was). Note that with depth 2 of 3 (not too many occlusion
querys)
> there is a significant win over non occlusion culling when e.g. inside a
> certain model, but with larger octree depths the overhead of occlusion
> queries and octree seem to win, and there are less fps.

> In nvidia slides

(http://www.nvidia.com/dev_content/gdc2002/GDC2002_occlusion_files/fra...

Quote:> ) was a note : "Do other CPU computation while queries are being made "

> Should i use a separate thread to perform the occlusion queries, or do the
> occlusion queries already run in an seperate thread ?
> Is it normal that the queries become a bottleneck when used frequently ?
> With large octree depth, octree rendering without culling is even faster
> then with culling (with queries). With depth 5 there are like 1000's /
> 10000's of occlusion queries. Can this be a bottleneck ?

> How can i fix this problem ?

> tia, and merry christmas ;)

> Roel Martens

Just my .02c.  I think that hardware occlusion culling is simply a new
technology that will get faster in the future.  Because of the bottleneck is
in the BUS, there is a is this delay factor.  Also there's a limit to the
amount of results that can be returned within a time period.  One possible
solution (depending on your situation) is to predict a few frames ahead of
time, what BB's can be seen.

Also are you exploiting frame to frame coherency? Octrees determined to be
out (in) in the last frame are likely to be out (in) in the next, so this
can be taken advantage by not retesting these.

I don't like the idea of a thread for this. If you send of data to be tested
it may return to you several frames to late, at the cost of extra
processing.  I'd suggest you try to do some other type of other important
processing while you are waiting for the results (ie game AI).  You could
even go off processing other branches of the tree, if the results don't get
back in time (or whichever gets back first).  Just testing to find out if
the results are in once in a while (per frame) hasn't seemed to be to
costly, for me at least.

 
 
 

NV_OCCLUSION_QUERY for occlusion culling

Post by Jeff Dunca » Sat, 04 Jan 2003 00:30:41


I don't have the original post handy, and have not worked with the occlusion
extension, but the way the past two posts read suggests that you are doing
something like:
   'render occlusion geometry'
   'test result'
   'render real geometry'

nVidia's occlusion query is an asynchronous process.  Waiting on the fence
eliminates the async nature of the feature, and makes your code less
efficient.  If you look at what you are doing, there is very likely
/something/ that could be done before you know if the test geometry is
visible - do that first.

The easiest way to do something like that is to have a set of geometry which
represents your occluders, then a set which represents geometry which may be
occluded - render the occluders, render the test geometry of all potentially
occluded objects, then test results & render real geometry as needed.

I'm pretty e*d about hardware occlusion checks, and hope nvidia and ATI
put their heads together on an ARB version in the near future.

Good luck,
-- Jeff

 
 
 

1. Hardware Support for Occlusion Culling?

Any idea when hardware support for occlusion culling will become
available on SGI platforms. Some other vendors are talking about
supporting this in thier hardware.

This could become a driving force in the area of Large Scale Database
visualization. (OpenGL-Optimizer)

--
Bill McGarry  SW-Engineer          Phone:(206)865-5064 FAX:(206)865-2628
Boeing Commercial Airplane Company Org: 6-6C13 , M/S 7J-79

2. JPEG -> MPEG2 application

3. Where to get Occlusion Culling Tutorials?

4. SUBSCRIBE to GNUPLOT mailing list

5. Occlusion culling source?

6. Bones Question

7. occlusion culling

8. CGA/EGA picture viewer?

9. Help w/ occlusion culling/portal algorithm

10. Visibility algorithms/Occlusion culling in dense polyhedral environments.

11. Occlusion Culling

12. Elision, Culling, Clipping, and Occlusion

13. occlusion culling using octrees