nv_occlusion_query Sync Question

I am writting a little post-processor to display some of my Fluid Dynamics results. Results are usually a bunch of connected triangles with colored or textures nodes. It makes use of octree after subdivision of the mesh. The octree is used to perform frustum culling and also roughly order the groups of triangles to display. I have also partially implemented the nb_occlusion_query test to cull as much as invisible groups. I know that the GetQuery function will stall the pipeline if one tries to request the results right away and am trying to recode my octree display to perform other related stuff. Unfortunately there is not much to be done as I do not have physics, AI and/or other stuff. Now if I can keep on drawing while waiting for teh query, I see some avenues for improvement.
I therefore have 2 questions:
1- Can I draw at the same time than start a query (ie. not disabling the DepthMask). If I draw a complex object with textures, will the glBeginOcclusion/glEndOcclusion drop the performance of the drawing.
2- Once I close the query with the glEndOcclusionQueryNV(), is it possible to continue drawing without stalling the pipeline before querying the test with glGetOcclusionQueryNV()

Thanks for any feedback.

The occlusion query can be performed with a bounding box or a more complex object. Now if the time required to query on a box is more or less the same that the time required to draw the real object, I might as well draw the real object. Am I wrong?

Eric

PS:

You can do queries and draw other stuff directly after that, as much as you like, no problem.
You can also disable depth-mask, texturing, etc. then start a query, draw your object, finish the query, enable the depth-mask and texturing again and draw other stuff, without having to wait for the query-result first.
As everything else too, a query gets cached by the driver. It is not computed the moment you start/finish a query, but when the gfx card has done everything else, which should be done before the query.

Rendering a bounding box will certainly always be faster than rendering your real object. You don´t gain much from rendering the real object, but the gfx card will have to work a lot more.

To answer your questions:

  1. Yes, i am sure that an occlusion query will slow down the rendering, because now the card has to count the passing fragments.

  2. Yes, that´s possible. As i mentioned above, everything gets cached. This is the intention and the real advantage of the occlusion query extension.

Jan.

Rendering a bounding box will certainly always be faster than rendering your real object. You don´t gain much from rendering the real object, but the gfx card will have to work a lot more.

Using occlusion querries like this, all the objects that are visible take a bit longer, since you have to render a bounding box. But, the invisible ones take less time, because you’re only rendering bounding boxes for them.

As such, if you’re doing a lot of querries on visible objects, then you’re spending a lot of time drawing bounding boxes. If you only test visible objects every 5 frames or so (staggered appropriately so that one frame doesn’t render more querries than another), then you can get better performance. Even better, if you can establish a probability of an object being behind something, based on some other visibility data, then you can spend even less time doing querries.

Ideally, you should only do querries for objects that are in doubt; objects that you can clearly decide are visible or clearly not visible via CPU methods should not have querries associated with them.

Yes, i am sure that an occlusion query will slow down the rendering, because now the card has to count the passing fragments.

While it may indeed slow down rendering, the reasoning you use is not necessarily true. Indeed, it may count pixels freely already; all the occlusing querry is doing is resetting the count and giving it to you when it is done.

Thanks Jan2000 and Korval for your answer.

I apologize for not having been more prompt in getting back to you… and now we are on emergency power (guess where I leave!).

I am still trying to find a good way to hide the latency of the occlusion test whithin my octree framework. As I can continue drawing while queries are processed, I am thinking about waiting one frame for the query to be processed. The regular drawing would allow me to hide the latency, at least that is what I think. The obvious drawback is that I would be using the query result which is a frame-late. The octree is using frustum culling and usually displays a few thousand blocks of triangles (for a total mesh of 5 Millions triangles with various shading, textures. In most of the cases, out of those 5M, only 10% are visible. I did a perf analysis of the code and did not find places where intensive calculations could be performed in parallel to the query. Checking frustum and clipping planes, traversing the tree are very fast process.
In order to avoid too many queries, I am also testing visible blocks every other frames.

If I want to be able to process the query at the later frame, I will need to have, at most, as many queries as I have blocks of triangles and octre nodes as I can perform queries on the octree nodes as well as the blocks. I therefore have one question: How many occlusion queries have you been generating for a large model? Is there any overhead in generating about 4,000 queries even if only a few on them are used?

Has anyone a better and more sophisticated idea related to hidding the latency whithout having the frame-late problem?

Thanks

Eric