It seems the Tamas Kenez hardware occlusion demo uses some strategies of the paper you mention. The OpenGL Interceptor log shows the interleaving of front to back drawing with up to 50 outstanding occlusion queries at a time. It renders 200k instances of 22 million triangles.
Erwin Coumans
"GL_NV_occlusion_query demo by Tamas Kenez, May 2002
Requires GeForce3 or better (no 4MX) and driver 27.xx or later
The purpose of this demo is to show the possibilities of the
GL_NV_occlusion_query extension. Using this extension it is possible to replace previous visibility solutions, like PVS or portals, with a transparent and generic occlusion culling subsystem.
Main features of such an occlusion culling subsystem:
- Fully automatic, no preprocessing needed, you don't even need to choose good occluders
- Fully dynamic, no difference between moving and static objects
- Transparent, can be plugged into any existing engine
- All types of scenes are supported, buildings, terrains, CAD models, etc.
- Scene size does not affect performance, only number of visible objects.
- Scene database doesn't need to be structured, even polygon soups are supported
The main point of this demo is to promote the GL_NV_occlusion_query extension. It should be included in the upcoming OpenGL2.0 as a standard feature. This extension is very simple to implement in hardware and provides us an elegant way to solve visibility problems. Replaces PVS, portals, etc. I think the role of this extension is the same for conservative visibility as the introduction of Z-buffer was for exact visibility.
I can't say much about the actual algorithm as it will be part of a commercial product and is yet to be sold. After that I'll post a detailed description.
Tamas Kenez
More info: knz _at
Legal stuff:
Use at your own risk, as usual.
This demo is very similar to the Scout Demo found of Hybrid/Criterion's dPVS but no code or artwork were used from that product.
I'm not affiliated with Hybrid, Criterion or NVIDIA."
----- Original Message -----
From: Miles Macklin
Sent: Thursday, June 23, 2005 1:03 AM
Subject: Re: [Algorithms] HOM vs. Hardware

Hi all,

We are looking to implement the Coherent Hierarchical Culling algorithm using hardware occlusion queries as presented here:
Although it might be slightly 'squishy' it sounds promising, does anyone have an analysis to offer ?

----- Original Message -----
From: Bill Baxter
Sent: Thursday, June 23, 2005 11:43 AM
Subject: Re: [Algorithms] HOM vs. Hardware

Ok, for plain vanilla urban scenes with opaque boxes for buildings where you can get by with 1D occlusion maps then, yeh, I guess dynamic occlusion culling isn't so bad.  That's a pretty special case, but fairly common, I suppose.  I recall reading a papery by someone that also dealt with the problem varying building heights by creating a top-down occlusion map by rendering sight-line planes into a 2D buffer.

Still, I'm not totally convinced you couldn't do just as well with some sort of static PVS on those types of scenes.

On 6/23/05, Tom Forsyth <> wrote:
I'm not convinced that's true. The standard benchmark for occlusion is the
built-up urban scene. As long as you stay at ground level, there is a huge
amount of occlusion, but it's very hard for any non-dynamic occlusion
(portals, static PVS) to do anything useful. You can prtty much move
anywhere you like, you will always get lots and lots of occlusion. Sure, you
can look all the way down a street and see lots of houses, but it's very
rare that you can look straight down more than two streets at once (at a
crossroads). It reduces the problem from a 2D one ("how do I render every
building in the city out to the horizon") to a 1D one ("how do I render
every building on a few streets out to the horizon"). You can push the
horizon/LOD out a lot further with the second option.

Obviously as soon as you clamber onto a moderately high rooftop, it all
fails, but that's when you start having to get the LOD stuff going. C'est la
vie. But then, youre attention is probably on more distant objects, so the
LOD is not as noticeable.


> -----Original Message-----
> From:
> [mailto:] On
> Behalf Of Jonathan Blow
> Sent: 22 June 2005 11:37
> To:
> Subject: Re: [Algorithms] HOM vs. Hardware
> >I suspect there may be other factors, i.e. saving draw calls. Imagine
> >a scenario with nearly flat terrain and some opaque fences/buildings,
> >a huge draw distance and lots of units running around. Occuding some
> >of these can save potentially many draw calls.
> >
> >Saving them _might be_ cheaper, even if you do some occlusion culling
> >on the CPU.
> >
> >
> As a previous poster said ... and then you move the camera and your
> frame rate takes a nosedive.
> Relying on occlusion culling to save you for scenes like this
> is not a
> viable way of making a smoothly-running game -- unless you
> can guarantee
> that all your scenes are like this.  (Which is true for an extreme
> minority of games).
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast.
> _______________________________________________
> GDAlgorithms-list mailing list
> Archives:

SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast.
GDAlgorithms-list mailing list

William V. Baxter III,  Ph.D.
OLM Digital
Kono Dens Building Rm 302
1-8-8 Wakabayashi Setagaya-ku
Tokyo, Japan  154-0023
+81 (3) 5433-5588