I'm having trouble with visualizing this so I'm not sure if I'm completely off base any help would be greatly appreciated.

The idea is to do this in a compute shader using shared memory.

So lets say I create rectangular occlusion geometry for walls. Now I create a 5 plane frustums (no far plane) with the eye point as the apex for some of the visible occlusion geometry. Then I test bounding boxes of potential occludees against these frustums but instead of the basic frustum test I test for any section being in front of the near plane, completely out the frustum, partially in the frustum and completely in the frustum. If its completely in the frustum it doesn't get drawn. There is some more possibilities after that but thats just details. Logically am I right??? Will this work or am I picturing things wrong? Will the frustums generate proper occlusion? I know a zbuffer is easier more accurate and there are no corner cases with it but I am curious about this. So am I completely off base or is this feasible?

This is old school. Compute shaders, meet 1999 :)

http://www.gamasutra.com/view/feature/131388/rendering_the_great_outdoors_fast_.php?page=3

http://www.gamasutra.com/view/feature/131801/occlusion_culling_algorithms.php?page=4

Yep it works. As in that first article, you can have more than one "near plane" on your convex hulls (frustra) if you like.

Some engines will refer to these planes as anti-portals or simply, occluders.

The catch is that you need to find a reasonably small set of large occluders. If you have a large set of occluders, you've got to perform too many tests, and if your occluders only cover a small screen area, they're not likely to occlude anything.

The failure case is what you have an object which is actually hidden by many small occluders, but isn't completely hidden by any single occluder. This system cannot determine that such an object is occluded.

I know of some Xb360/PS3 games which actually used this as their main culling technique -- they got the level designers to place large quads inside walls/buildings/etc. The engine then frustrum culled these quads, selected five of them with the largest screen-space area, built the occlusion-frustrums from them, and then culled any objects that were entirely within these occlusion-frustra.

I know a zbuffer is easier more accurate and there are no corner cases with it but I am curious about this.

That is correct. When bounding box/sphere is fully inside of all those 5 planes then it's fully occluded.

Thank You.

The catch is that you need to find a reasonably small set of large occluders. If you have a large set of occluders, you've got to perform too many tests, and if your occluders only cover a small screen area, they're not likely to occlude anything.

I have something in mind, hopefully it works out.

zbuffer ist actually less accurate (if lower resolution, which is the common case) and has more corner cases (e.g. you need water tight rendering, deal with z-fighting issues etc.)

Hadn't thought about z-fighting, and I was thinking full size gpu occlusion so I hadn't thought of that. What do you by "mean water tight rendering", I've heard the term before but don't remember what it means?

What i do is: Use software rendering to render occluding polygons but mark only start and and points per scanline,
that way it's not necessary to check each pixel like with GPU occlusion culling.
Testing a bounding box just means testing all scanlines it touches.

I think thats referred to as a span buffer. Also 5ms wow thats alot.

zbuffer ist actually less accurate (if lower resolution, which is the common case) and has more corner cases (e.g. you need water tight rendering, deal with z-fighting issues etc.)

Hadn't thought about z-fighting, and I was thinking full size gpu occlusion so I hadn't thought of that. What do you by "mean water tight rendering", I've heard the term before but don't remember what it means?