I thought I try using this ext to speed things up but ran into a problem.
according to the example code
turn off color mask
turn on depth mask
set depth func to less
render query objects(using bounding box in my case)
wait for query to finish
turn on color mask
turn off depth mask
set depth func to equal ( I had set it to >= )
get result for query
render objects which queries have passed
the problem is “set depth func to equal (I had set it to >=)”. It tells you to just use equal but then I don’t get anything unless I use ( >= sign ). My objects are also flashing meaning there query will change between 0 and 1 within the same view.
If I want to fix this not according to example code, I would just clear the depth buffer when I’m ready to render the object according to the queried result. Is it a good way to deal with this?
Changing the depth func this way will only work in case you use the original mesh for the occlusion query as well. If you use bounding volumes then you should not mess with the depth func at all and definitely you shouldn’t set it to “equal”. Also, if you use bounding volumes you do not want to turn on depth mask in the occlusion culling phase.
To sum it up, this is how you should use occlusion queries with bounding volumes:
- turn off color mask
- turn off depth mask
- render query objects (bounding volumes)
- wait for query to finish
- turn on color mask
- turn on depth mask
- get result for query
- render objects which queries have passed
Of course, as because you turned off the depth mask in the first pass, occlusion culling won’t take into consideration the occlusion between the objects you query but this is the way how it can be done as writing depth for the bounding volumes will result in invalid data in the depth buffer.
Thanks! I had done it that way in the beginning but all my objects were always passing. I had a cluster of objects too close together and was using GL_ANY_SAMPLES_PASSED although I figured object that can’t be seen at all would not pass but that wasn’t the case. It seems that it would be better to use GL_SAMPLES_PASSED instead (which I’m using now and don’t have any problems).
Actually GL_ANY_SAMPLES_PASSED should work in the exact same way as GL_SAMPLES_PASSED so you should simply try changing the query type and changing the acceptance criteria to bool check rather than number check. Besides that, there is no any difference between the two, except that GL_ANY_SAMPLES_PASSED allows room to some optimizations as the driver/GPU does not have to rasterize the whole primitive if it finds out that a sample passes thus enabling taking full advantage of Hi-Z in cases the exact number of passed samples is not important.
If you are having problems with migrating to ARB_occlusion_query2 with the aforementioned method then it is possible that there is a bug in the driver.
Yeah it seems like it but it’s definitely doing it’s job. Thanks I tried GL_ANY_SAMPLES_PASSED and it seems to be doing okay. I had tried a test with objects closely packed to each other to test it and view them at a way that the very front objects could only be seen but it didn’t seem like there was much of an effect with the query at least not as good as coming up with my own threshold for some reason. I’m going to see if there’s an newer driver too. I could have been doing something weird before too since it seems to be doing better now.