Re: [Algorithms] HOM vs. Hardware
Brought to you by:
vexxed72
From: Bill B. <wb...@gm...> - 2005-06-22 23:43:45
|
Ok, for plain vanilla urban scenes with opaque boxes for buildings where yo= u=20 can get by with 1D occlusion maps then, yeh, I guess dynamic occlusion=20 culling isn't so bad. That's a pretty special case, but fairly common, I=20 suppose. I recall reading a papery by someone that also dealt with the=20 problem varying building heights by creating a top-down occlusion map by=20 rendering sight-line planes into a 2D buffer.=20 Still, I'm not totally convinced you couldn't do just as well with some sor= t=20 of static PVS on those types of scenes. On 6/23/05, Tom Forsyth <tom...@ee...> wrote: >=20 > I'm not convinced that's true. The standard benchmark for occlusion is th= e > built-up urban scene. As long as you stay at ground level, there is a hug= e > 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,= =20 > 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. >=20 > 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= =20 > la > vie. But then, youre attention is probably on more distant objects, so th= e > LOD is not as noticeable. >=20 > TomF. >=20 >=20 > > -----Original Message----- > > From: gda...@li... > > [mailto:gda...@li...] On > > Behalf Of Jonathan Blow > > Sent: 22 June 2005 11:37 > > To: gda...@li... > > 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 <http://SF.Net> email is sponsored by: Discover Easy Linux=20 > 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=3D7477&alloc_id=3D16492&op=3Dcl= ick > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > > >=20 >=20 >=20 > ------------------------------------------------------- > SF.Net <http://SF.Net> email is sponsored by: Discover Easy Linux=20 > 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_id=16492&opclick > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 >=20 --=20 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 |