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.
glColorMask(GL_FALSE, GL_FALSE, GL_FALSE, GL_FALSE);
glColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_TRUE);
glGetOcclusionQueryuivNV( cull_box2 , GL_PIXEL_COUNT_NV, &pixelCount);
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
) 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 ;)