PDA

View Full Version : Occlusion Query



SeskaPeel
08-22-2003, 03:28 AM
I'm just wondering how this stuff works.

When you read Nvidia's samples, they propose to render bounding box of objects only, and then perform occlusion query. But if you render a big bounding box in front of the cam, there will be a lot of models that would not be occluded by the true object, but that will be by its bounding box ...

What didn't I understand ?

SeskaPeel.

errno
08-22-2003, 03:59 AM
create a bounding box per object, not one bounding box for all the objects.

Tom Nuydens
08-22-2003, 04:04 AM
The bounding box is not written to the Z-buffer, so it doesn't occlude anything. You do occlusion tests on the boxes, but it's still your actual geometry that acts as occluders.

-- Tom

SeskaPeel
08-22-2003, 04:36 AM
So you have to render whole scene a first time to set Z-Buffer ? So you have to render a first time (not lighting, no shading, ...), and at second pass you render only visible objects (with heavy lighting and shading computations) ?
Is this not slower this way ?

SeskaPeel.

Tom Nuydens
08-22-2003, 07:43 AM
The best way to go about it depends on where your bottlenecks are. If shading/rasterization is your main bottleneck then yes, a two-pass scenario like you described could work well.

If vertex processing is your problem, you need a different solution, of course. You could sort all objects front-to-back so that the frontmost objects can occlude the ones in the back. Alternatively, you could generate some occluders (simple polygons instead of actual scene objects), which you render to the Z-buffer before drawing the scene.

I'm sure you could dig up other approaches if you search the archives.

-- Tom

dorbie
08-22-2003, 09:44 PM
Two passes would be very inefficient but in general this works best for very dense geometry, especially when you consider how it must be used and that coarse z rejection saves you the hidden fill anyway.

You could draw front to back, and after you have what I like to call a few "conspicuous occluders" drawn in the framebuffer you could test the bounds of more distant objects. Obviously this requires some kind of sort, but there are other simpler strategies that depend on your scenario.

If I have a row of garages with an automobile in each, I might choose to draw the garages first then before each vehicle I test the car bounds for occlusion, giving the pipe time to produce my occlusion result of course because there's latency involved and I don't want to stall the pipe too much.

Another strategy is at the end of a frame to test the bounds for the next frames objects for an approximate but fast result against the whole scene with no sort required, maybe even after the swap but before the depth clear to avoid missing retrace. it would be possible to try drawing the sky to the color buffer with no depth test or write before the clear and occlusion tests in the hopes of some fill while the depth buffer hardware handles occlusion querries, (dunno if this would be a win) before occlusion culling the geometry (clearing depth later). This gives an approximate occlusion test result based on the previous frame's depth values and is generally pretty good even in animated scenes, for fast moving objects or objects near the eye you could expand the test volume to be a bit safer.

dorbie
08-22-2003, 09:46 PM
P.S. in a two pass scenario you'd do some kind of minimally enclosing volume for closed objects to minimize the geometry cost, otherwise it's not a good approach because coarse z buys you the pixel win on occluded stuff with a simple sort.

[This message has been edited by dorbie (edited 08-22-2003).]

Obli
08-23-2003, 08:29 AM
Probably off topic:

Originally posted by dorbie:
Two passes would be very inefficient

Some time ago I had a discussion with other people and they told me the z-only first two-pass algo looks interesting. Maybe "could be very inefficient" is a better statement.
I'll check to see if I can get the thread back from the archives.

dorbie
08-24-2003, 01:56 AM
You must focus on what you are trying to save in performance and why. Occlusion tests are designed for a specific purpose. They work best for saving geometry especially when you consider coarse z with a sort saves a lot of fragment overhead.

Some have said that to exploit coarse z it makes sense to do a scene pass to the depth buffer before you actually do your shaded pass. I suppose it depends on what you are drawing and how dumb your software is.

You can always contrive to justify silly suggestions.

Pentagram
08-24-2003, 11:19 AM
In my application occlusion queries made it actually slower than resending all the geometry for multipassing.
This was a zfill buffer followed by 2+ passes per light. (I.e. stencil shadows and bumpmapping http://www.opengl.org/discussion_boards/ubb/wink.gif )
There wasn't much to cull however since we have PVS culling and so only a few models could be extra culled based on the occlusion query.

Charles

dorbie
08-25-2003, 05:31 AM
Unless you can amortize the costs of the occlusion tests with your savings and then some then it isn't worth it. Your zfill pass means occlusion could not save you anything w.r.t. pixel fill thanks to coarse z, so you really have to look at the geometric complexity of the things you are trying to occlusion test.

I'd advise only occlusion testing models that have very dense geometry, and trying to avoid blocking on the test. Of course occluded objects may still cast shadows so you still have to render their shadow volumes. If the volumes are zpass tested you can occlusion test them, if they're zfail there is no test AFAIK. Most should be using a mix to save on the non clipped capping etc.


[This message has been edited by dorbie (edited 08-25-2003).]