Not diss'n it in general.  Just for games.  :-)  In a CAD or visualization setting, on the other hand, you can't choose what your "scene" is.  The data is what it is.  So in that setting I think dynamic occlusion culling can be a big win.  It can help make it possible to interact with a model that you otherwise wouldn't be able to.   But in a game, you _do_ have some control over the environment and even the movement of the avatar, and in a game fun is more important than accurate visualization.

--bb

On 6/23/05, Karl Hillesland <karl.hillesland@gmail.com> wrote:
< gasp >   are you diss'n dynamic occlusion culling? :)

On 6/21/05, Bill Baxter <wbaxter@gmail.com> wrote:
> The other problem with fusing small occluders is coherency of the rendering
> load.
> Any tiny gap that opens up in the cloud of otherwise opaque occluders can
> cause you to render a bunch of geometry you were occluding in the previous
> frame.  And then just as easily one frame later the gap can close and you
> stop rendering the stuff.  So your frame rate can oscillate all over the
> place.  The bottom line is that even if there were a magic box that could
> give you 100% accurate culling instantly, in a game you still need to design
> your scene carefully so that you can handle the worst case load.  And if 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 approaches.
> 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 from
> any region.  BSP visibility is just a variant of that idea, right?  But
> other approaches to computing PVS and performing PVS queries are possible
> too.  There have been some papers on the subject by Fredo Durand and others.
>
> Just out of curiosity is anyone using any such PVS culling techniques in
> real life?  Something besides Quake-style BSP, I mean.
>
> --bb
>
>
> On 6/22/05, Jonathan Blow < jon@number-none.com> wrote:
> > Sure, occluders-too-small is an issue, but what that means is that you
> > 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 perhaps
> > 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 you
> > 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 is
> > 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 occluders
> > >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 RPG
> > >fashion, what was a great gigantic occluder becomes a lot of smaller
> > >cubic occluders that each, separate, really can't do much good against
> > >another big thing (like another big house a street down the way).
> > >Similar problems present with walls that have entry points, or either
> > >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 perf
> > >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 where
> > >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 to
> > >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 static
> > >>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 headache of
> > >>implementing one of these schmancy occlusion systems.
> > >>
> > >>
> > >
> > >
> > >-------------------------------------------------------
> > >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&opĚk
> > >_______________________________________________
> > >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
> > >
> > >
> > >
> >
> >
> >
> > -------------------------------------------------------
> > 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


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