Hardware Occlusion queries.

[revelator]

[Spike]

yeah... that's not how you're meant to do them.

firstly you're leaking occlusion query handles.
secondly, you're busylooping the cpu while the driver is busy feeding the gpu while the gpu is still idle (a general rule of thumb is that you should only check the result of occlusion queries on the _following_ frame - make it slightly larger/nearer so you won't get occasional flickering. at a minimum you should draw something else unrelated between the endquery and the getquery, to at least give the gpu/driver a chance to catch up with the cpu/app, yes this something else will not be detected by the occlusion query hence the whole next-frame thing).
drawing a fullscreen quad for your occlusion query is really quite pointless too of course...

GPUs are frikkin fast nowadays, so really think of occlusion queries as just an optimisation to reduce the cpu overhead sending lots of invisible drawcalls at the driver. if you're submitting one drawcall to avoid a single other (and probably needing to submit BOTH draw calls anyway), there had better be a GOOD reason for that...
They're useful for doorways so that you cull entire rooms, or for forward-rendered rtlights maybe, but totally pointless for your average quake mdl.
They may also be useful for cheat detection, but hey...

at least that's how I see them - as a cpu/gpu sync nightmare.

[revelator]

Refined it a bit in the meantime but the code itself seems to have originated from nvidias codesample.

this part glGetQueryObjectiv(occQuery, GL_QUERY_RESULT_AVAILABLE, &occAvailable);
is actually to avoid hogging the gpu as occAvaliable will only be true if the query was done, the way it was handled though is another matter the correct way according to all sources i can find is to just do it like this

glGetQueryObjectiv(occQuery, GL_QUERY_RESULT_AVAILABLE, &occAvailable);

if (occAvailable > 0)
glGetQueryObjectiv(occQuery, GL_QUERY_RESULT, &occSamples);

the last query wont run unless GL_QUERY_RESULT_AVAILABLE has spit out that the pipeline is ready to recieve data again.

And sure you dont have to use a fullscreen quad for testing on you can also use triangle mode or whatever

Im using it for bloom occlusion now and it seems to work rather well for that.

[Barnes]

try to use conditional render

(supported in gl 3.0+)

[revelator]

Allready did works ok now, not noticing any slowdowns.

But spike is correct it works better on complex stuff.

Also it was mostly an experiment to see how well or not it works.

[mh]

With occlusion queries you're meant to issue the query, then come back a frame or two later and fetch the results, otherwise you've just broken CPU/GPU pipelining and you've done the equivalent of a great big glFinish call in the middle of your code.

If fetching the results immediately doesn't reduce your framerate to at least half what it was (and it should, even for just one query, even for a simple single quad) then your CPU/GPU pipelining is probably already broken elsewhere.

[revelator]

First version did indeed cause some slowdowns, probably it was also a bad idea to try and use it as a hardware version of R_CullBox.

New version uses a low poly version of the bbox to fill the queries for 3 frames before drawing the real deal.

The fullscreen quad part in version one was just copied of quake royale,
at the time i was not sure precisely how the queries worked, seems the original author was not either.

Its an interresting technique but software occlusion does the job better still so a bit pointless.

[Barnes]

The occlusion quary is very strongly tied to rasterization. For this is what you want to cut out should be very heavy. Overhead at high resolutions of the screen is huge. It will save a bit the use GL_ARB_occlusion_query2 (ANY_SAMPLES_PASSED), but there will be a synchronization problem. We can solve it in two ways.
1 - use the result of visibility from the previous frame
2 - to get the result assynchronously through conditional rendering

[mh]

It also breaks your ability to do batching/instancing, so you really need to evaluate performance both with and without rather than just assume that it will be faster.

[revelator]

Aye its not exactly easy to get this one done right, and it comes with some downsides to.

One reason i was exploring it was because of particles such as rocket explosions bleeding through solids,
i tried various methods to get rid of them but even the best fixes still lets some of the explosion bleed through.

Still looking for a reliable way to do this.

[mh]

Soft particles is the term you're looking for: http://blog.wolfire.com/2010/04/Soft-Particles

[revelator]

Dooh ... your right i should have thought of that one since i helped get this working in the darkmod engine
Hrrr i guess getting to the depthbuffer will be just as fun in quake...

[Barnes]

[revelator]

That's a start thanks barnes.

[Barnes]