occlusion culling revisited

I''ve been putting in some research on the topic for quite some time, and thus far, youre technique is correct.

For an image space algorithm, this is how i''m planning to set things up:

1. Via Scene Subdivision, get a list of objects visible to the camera. Sort them (quicksort) based on z distance. (NOTE this could also be done by simply sorting the subdivision (octree) nodes)

2. render the polygons of your front objects. This can be an arbitrary number, or percent. (I usually do about 40% of the screen is covered)

3. Copy this image into an offscreen buffer for keeping

4. For every other object, Render it''s boundng box into the offscreen buffer. Then do a check to see if any pixels were modified

5. If they were, tag this item to "VISIBLE"

Am i missing anything?
~Main

==
Colt "MainRoach" McAnlis
Programmer
www.badheat.com/sinewave

OK, first of all, the occlusion culling extension is not very powerful. In principle, it is, but the way it is implemented, it will constantly stall and flush the pipeline. Don''t expect too much.

To get good performance, you should do as few occlusion tests as you can get away with. Also, you should use NV_occlusion_query instead of HP_occlusion_test, as it is more pipeline friendly (don''t worry, although it is an NV extension, it is also supported on ATI). The less checks you do, the less bubbles you will introduce into the rendering process.

duhroach: The general idea is correct. There are a couple of points that can be improved to get more efficient culling. You could, for example, designate a number of objects as ''good occluders'', those would be used with higher priority than normal objects. A big wall, for example, is almost always a good occluder, even if far away (it will cull even further away geometry, despite of having a small screen projection size). There are various heuristics besides distance selection that can be used to determine occluders. Things like angle to the camera, etc. Also, using time coherency can be beneficial: if an object was culled away in a frame, then it is highly unlikely that it suddendly becomes a good occluder itself in the next frame.

Another idea is to have your 3D artist add very low poly occlusion skins to your scene. That''s simply geometry which is only rendered into the occlusion map, but not onto the visible screen. Those skins can approximate the combined occlusion of several complex objects with a few faces. Just make sure they are conservative, otherwise you might get artifacts.

/ Yann

Yann, What method are you using to get your pixel information back?

I''m currently rendering the bounding boxes of objects, each with a seperate color, then using the GLHistogram function to retrieve information for the GPU. From there, I just step through the colors in the array that''s returned, if any element is >0 then i know that object is visible.

Are you using some sort of function to check the data? or just moving through each pixel, checking if it has been changed?

~Main

I didn''t know of any occlusion extension. Can someone tell me how it works internally? Does the card keep a list of every triangle rendered, and use that data (and the Z-depth-values of each triangle''s three vertices) to determine if a triangle should be drawn?

~CGameProgrammer( ) {delete Websites.DeveloperImageExchange;}

There''s some papers over at Nvidia that goes over the Hardware occlusion tests. here''s a good one.

~Main

==
Colt "MainRoach" McAnlis
Programmer
www.badheat.com/sinewave

I believe the extension has a number of stages; first you draw something that has been flagged as an occluder, say an inscribed bounding box (e.g. fully contained by the object around it). The driver then flags the pixels written to the depth buffer as being the ones to test against for following occlusion queries. Subsequent draw operations can then be flagged with an occlusion query that will eventually return the number of pixels of that object that have been drawn. Using this returned count allows you to decide whether or not to draw a more complex object, or you can use it as the parameter for a glow effect.

No, there is no special flagging of pixels. The extension works in a very simple way: occlusion is defined as not being visible, ie. if no pixel passed the z-test, then the rendered object is assumed invisible. The NV extension will also return the exact pixel count statistics.

The basic steps go like this: render all your objects that might be good occluders. Then enable occlusion mode. Render the bounding boxes of the objects you'd like to test, but disable colour and depth updates. Once you rendered the box, you can readback the occlusion result, ie. how many pixels from the bounding box passed the visibility test. If it's none, or just a very low amount, you don't need to render the object in the bounding box. As you can see, you have to interrupt the rendering at each node, to read back the occlusion result. That creates an enormeous amount of bubbles in the command stream, and will degrade performance. The NV version of the extension will allow you to queue up several queries, and read back their results at once. That alleviates the problem a little bit, but it's still not very good.

quote:

---

Yann, What method are you using to get your pixel information back?

---

Actually, I'm not using hardware occlusion culling anymore. Carefully profiling the engine showed that speedup was not worth it, and under certain circumstances, it would even slow the engine down.

I use a full software occlusion mapping system, based on a software HOM algorithm. Using GPU/CPU parallel execution, I use a highly optimized software renderer to render the depthbuffer of a special occlusion skin on the CPU, into a memory buffer. I do that overlapped with the GPU still rendering the previous frame (see that CPU/GPU concurency thread for more info). That way, I virtually get the occlusion map for free.

When I traverse the scene tree, I compare the node projection with the HOM in software. Actually, all the occlusion rendering and testing is done on the CPU. Which is, surprisingly, a lot faster than using hardware occlusion culling. It will not introduce any readbacks or pipeline stalls, and will run in parallel to the GPU doing something else.


[edited by - Yann L on February 12, 2003 7:12:07 PM]

Can you link to the thread you''re talking about, Yann?

~CGameProgrammer( ) {delete Websites.DeveloperImageExchange;}

Just a few lines down, this one.