Very Computer

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

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

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

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.

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