Re: [Algorithms] HOM vs. Hardware

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Oops. That was a mis-reply. I was intending to privately tease Bill.
Sorry about that.

On 6/22/05, Karl Hillesland <kar...@gm...> wrote:
>  < gasp >   are you diss'n dynamic occlusion culling? :)
>=20
> On 6/21/05, Bill Baxter <wb...@gm...> wrote:
> > The other problem with fusing small occluders is coherency of the rende=
ring
> > load.
> > Any tiny gap that opens up in the cloud of otherwise opaque occluders c=
an
> > cause you to render a bunch of geometry you were occluding in the previ=
ous
> > frame.  And then just as easily one frame later the gap can close and y=
ou
> > stop rendering the stuff.  So your frame rate can oscillate all over th=
e
> > place.  The bottom line is that even if there were a magic box that cou=
ld
> > give you 100% accurate culling instantly, in a game you still need to d=
esign
> > your scene carefully so that you can handle the worst case load.  And i=
f you
> > can handle the worst case, then is there really much benefit to be had =
in
> > performing a bunch of fancy dynamic occlusion calculations?  If you're =
using
> > just a few big chunky occluders then the coherence of the occlusion is
> > likely to be better.
> >
> > Now, if you're talking about static geometry, then the situation is
> > different.  There are some reasonable ways to use precomputed occlusion=
 info
> > for static geometry with "potentially visible set" (PVS) type approache=
s.
> > Basically decompose your scene into regions and record what can be seen=
 from
> > each region, or arrange it so that you can calculate the PVS quickly fr=
om
> > any region.  BSP visibility is just a variant of that idea, right?  But
> > other approaches to computing PVS and performing PVS queries are possib=
le
> > too.  There have been some papers on the subject by Fredo Durand and ot=
hers.
> >
> > Just out of curiosity is anyone using any such PVS culling techniques i=
n
> > real life?  Something besides Quake-style BSP, I mean.
> >
> > --bb
> >
> >
> > On 6/22/05, Jonathan Blow <jo...@nu...> wrote:
> > > Sure, occluders-too-small is an issue, but what that means is that yo=
u
> > > just don't catch some percentage of objects that are really occluded.
> > > For a wall with a window in it, perhaps you have 4 occluders (or perh=
aps
> > > you just have 1 for the biggest piece of the wall, and ignore the
> > > rest).  Suppose the CPU occlusion detector is simple, then it's not
> > > going to realize when you have some object that crosses the boundary
> > > between those occluders, that it is occluded.  So you draw it.  But y=
ou
> > > still catch the guys behind the big part of the wall, and the further
> > > they are, the more likely you are to catch them.
> > >
> > > Implementing this HOM stuff means that you catch a higher percentage =
of
> > > objects, but the question is, what does that really do for you, and i=
s
> > > it worth the software engineering issues you have to face.
> > >
> > > I'm not saying hierarchical z-buffers are inherently bad -- hardware
> > > uses them pretty effectively I am told -- it's just that in this case=
,
> > > with the hardware way over there and deeply pipelined, it isn't good =
in
> > > practice.
> > >
> > >
> > > Megan Fox wrote:
> > >
> > > >Well, here's the problem with that, at least in my case - my world
> > > >tends to feature a lot of small chunks that don't make good occluder=
s
> > > >in and of themselves.  A big two-story house COULD be a great
> > > >occluder, but when it's peppered with windows and doors in typical R=
PG
> > > >fashion, what was a great gigantic occluder becomes a lot of smaller
> > > >cubic occluders that each, separate, really can't do much good again=
st
> > > >another big thing (like another big house a street down the way).
> > > >Similar problems present with walls that have entry points, or eithe=
r
> > > >half of a town gate, and don't even THINK about trying to use those
> > > >trees or bushes as occluders... etc.
> > > >
> > > >The schmancy systems have the advantage of automatic occluder fusion=
,
> > > >meaning that in the house-with-windows case, that WOULD become a
> > > >single big occluder in many cases, and possibly net me some nice per=
f
> > > >gains.
> > > >
> > > >I'm not really sold on the idea of trying to generate occluders
> > > >run-time from mesh data, but the same system applied to a world wher=
e
> > > >you've got pre-nested occluders in place seems like a "Good Thing"
> > > >(tm), at least in outdoor worlds that tend to have piles of small
> > > >things instead of a few big things.
> > > >
> > > >
> > > >... of course, this is all elementary, since I don't have any time t=
o
> > > >invest in this sort of optimization, but eh, it's definately on my
> > > >wish list.
> > > >
> > > >-Megan Fox
> > > >
> > > >
> > > >
> > > >>Games that want to reduce geometry throughput can often place stati=
c
> > > >>occluders into the world and use them to reject things on the CPU.
> > > >>Sure, this doesn't work for all cases, but it is okay and the gap
> > > >>between "okay" and "a slightly better okay" is not worth the headac=
he of
> > > >>implementing one of these schmancy occlusion systems.
> > > >>
> > > >>
> > > >
> > > >
> > > >-------------------------------------------------------
> > > >SF.Net email is sponsored by: Discover Easy Linux Migration Strategi=
es
> > > >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&op=CCk
> > > >_______________________________________________
> > > >GDAlgorithms-list mailing list
> > > >GDA...@li...
> > > >
> > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> > > >Archives:
> > > >http://sourceforge.net/mailarchive/forum.php?forum_ida88
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > SF.Net email is sponsored by: Discover Easy Linux Migration Strategie=
s
> > > 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
> > >
> >
> >
> >
> > --
> > 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
>