RE: [Algorithms] portal engines in outdoor environments

[Matthew M. <ma...@me...>]

My current plantasy for outdoor occluding of finite terrains and villages is
a sloppy-fitting "internal octree." We create an occlusion octree by filling
the relevant mountains/buildings with the biggest possible collection of the
largest possible AA cubes. Imagine taking a hollow shell of the building and
filling it with the largest (cubic) lego model you can fit inside it. This
is done with a pathetically simple in/out octree test with an arbitrary
depth limit. We completely ignore building interiors; all windows and doors
kick off a portal system for rendering their interiors. Our traverser
switches back and forth between portals and ...this..other..thing... as it
moves through doors and windows.

We then get lots of simple fast math to clip the frustrum against these
occluder cubes. We then test the bounding box of occludEEs against this
limited frustum when deciding what to render.

What we're mainly looking for is the cheap wins. We're absolutely allergic
to any polygon specific algorithms, because we want BIG FAT FILL RATES from
our HYPERPOLYGONATED geometry. ;^)

- no view space anything
- no touching the polygons
- when in doubt, throw it at the hardware
- VIPM is assumed

There are all kinds of cheap wins that you get with this. You mainly want to
catch the big, fat, stupid occlusion cases like when you're standing right
next to a wall and half the city is just plain invisible. That's the most
common, and it's damn cheap with this approach. The sloppy fitting is also
good because it works as VIPM does its thing.

You really don't want to bother with trimming the little occlusion portals,
because they change so fast as you move around that if your frame rate is
depending on them you'll lose anyway. Big buildings that are far enough away
to be occluded by little tiny polygons are also far enough away to be taken
out by VIPM, anyway.

I think this is basically anti-portals, but I haven't seen that paper.

There's some neat stuff with projected sillhouettes happending at MIT and
one of those French research consortia. It looks really cool but more
complicated. I try to avoid research wherever possible...

-- Matt




basic bounding-box versus frustum


You know if you can describe it in 200 words it must be right...




 in which solid cubes are entirely inside geometry. You then cull the
frustrum against the

<ascii art>
   ***
  *   ****
 *	    *
 *	    *
*

> -----Original Message-----
> From: gda...@li...
> [mailto:gda...@li...]On Behalf Of Tom
> Forsyth
> Sent: Friday, August 18, 2000 10:45 AM
> To: gda...@li...
> Subject: RE: [Algorithms] portal engines in outdoor environments
>
>
> I agree - it's a nightmare case for geometric occlusion. Delayed
> Z-visiblity
> is our only hope. A shame we've been waiting two DX versions for it, and
> it's going to miss this one as well.  Grrrrrrr. So while we have fancy
> vertex shaders that nothing on Earth supports, we don't have API
> support for
> something that even crusty old hardware like Permedia2 and
> Voodoo1 supports.
> Life... don't talk to me about life. :-)
>
> Tom Forsyth - Muckyfoot bloke.
> Whizzing and pasting and pooting through the day.
>
> > -----Original Message-----
> > From: Charles Bloom [mailto:cb...@cb...]
> > Sent: 18 August 2000 18:26
> > To: gda...@li...
> > Subject: [Algorithms] portal engines in outdoor environments
> >
> >
> >
> > .. is a hopeless proposition, I think.  I'd just like you
> > guys to check my reasoning before I give up.  Consider,
> > for example, a building placed on a landscape.  The goal
> > is to construct portals so that when you stand on one
> > side of the building, you can't see the other.  If the
> > player is constrained to stay on the ground, this is
> > easy enough, it's really a 2d occlusion problem, and you
> > need 8 portals (two * 4 faces of a square in 2d; two portals
> > cuz you need one on each side of a face of the square,
> > parrallel to that face) which splits the universe into 9
> > zones (8 outside and one inside the occluding cube).
> >
> > However, if we have a plain cube in 3d and the player can
> > go anywhere around it, we need 48 portals !! (8 for each of
> > the 6 faces on the cube).  Now if you have two cubes near
> > eachother, you need massive numbers of portals, and they
> > must all not intersect with eachother or other geometry.
> > This quickly becomes unworkable.
> >
> > I think something like a "real-time" occcluder (shadow volumes,
> > etc.) is the only hope for outdoors.
> >
> > --------------------------------------
> > Charles Bloom           www.cbloom.com
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>