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 ?
create a bounding box per object, not one bounding box for all the objects.
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.
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 ?
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.
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.
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).]
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.
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.
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 )
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.
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).]