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 < tom.forsyth@eelpi.gotdns.org> 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.

TomF.


> -----Original Message-----
> From: gdalgorithms-list-admin@lists.sourceforge.net
> [mailto: gdalgorithms-list-admin@lists.sourceforge.net] On
> Behalf Of Jonathan Blow
> Sent: 22 June 2005 11:37
> To: gdalgorithms-list@lists.sourceforge.net
> 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. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> GDAlgorithms-list mailing list
> GDAlgorithms-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=6188
>



-------------------------------------------------------
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. http://ads.osdn.com/?ad_idt77&alloc_id492&opclick
_______________________________________________
GDAlgorithms-list mailing list
GDAlgorithms-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_ida88



--
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