Its been awhile since I’ve done an update to my research into occluder generation. If you need a refresher, take a look at:
- Hierarchical Z-Buffer Occlusion Culling – Generating Occlusion Volumes
- Robust Inside and Outside Solid Voxelization
Lets start with the newest and most important information…
Update 4/13/2012
The project is now hosted on BitBucket,
Download
Requirements
Description
Oxel is a tool for generating occluders – primarily for use with the Hierarchical Z-Buffer method of occlusion culling. Open an .obj file then go to Build > Voxelize to generate the proxy. Try it out, let me know what you think.
There are some further improvements that have been made over the method that is laid out in the original Generating Occlusion Volumes post,
- Retriangulation
- Evaluating Occlusion-ness
- Filtering Polygons
Retriangulation
I went back to the CSG article Sander van Rossen and Matthew Baranowski wrote. I noticed near the end that they recommended retriangulating the final CSG mesh because their library doesn’t handle it.
The easiest method I found to do the retriangulation was to just use David Eberly’s Wild Magic math library which can do it, see here. Before you perform the retriangulation you need to collect all the external/internal edge loops on each surface and then merge collinear edges before performing the retriangulation.
It’s was definitely worth doing, performing the retriangulation saved about 30% of the triangles.
Evaluating Occlusion-ness
When you’re generating occluder geometry you need to ensure that the volumes you’re adding are useful enough to pay the additional polygon tax they will incur.
Oxel achieves this by measuring the number of pixels written to the color buffer by rendering the original visual mesh into the stencil buffer, and then using the stencil buffer to clip a full screen quad while a “samples passed” hardware query is performed to record the number of pixels written. This is performed from about 64 different camera angles – then when all the samples are summed together this defines the ground truth occlusion of the mesh.
Knowing that information we can evaluate every new box we plan to add to the final occlusion proxy geometry and ask – Does this increase the coverage enough to make it worth it?. The default threshold is set to 3%. If a new volume does not at least cover 3% of new silhouette pixels, we don’t include it in the final occluder mesh.
Filtering Polygons
Not every game needs the occluders to be visible from all angles. For example most racing games will never have the cars jumping so high they see on top of a building. In those circumstances you may not want to have the occluders bothering to have polygons on the top.
 |
 |
So the tool offers the ability to remove Top and Bottom polygons from the final occluder mesh after everything has finished being processed.
If you decide to filter out all top polygons they’re all removed. For bottom surfaces this has to be handled slightly differently, see below -
Imagine a bridge structure or a large over hang on a building. You wouldn’t want the bottom portion of the occluder to be removed from the overhang since it would allow seeing into and through the occluder – because presumably you wouldn’t have double sided rendering enabled. So to distinguish between bottom surfaces not meant to ever be seen by the player, and bottom surfaces that may be important to higher up potions of the structure, only bottom surfaces within 1 voxel’s height from the base of the mesh are removed. (See picture above)
Work Continues
I’ve got some more ideas I need to test out but I wanted to go ahead and cut a version of where I’m at and let others take a look and give me some feedback.
One area I need to investigate next is a better way to generate the boxes. Currently they are just expanded in all directions equally, but that’s not ideal. I’m thinking about trying a parallel brute force method that would test all possible boxes at a specific origin point to find the best shaped box to generate from that point.