Re: PVS generation

Bernd Kreimeier (Bernd.Kreimeier@NeRo.Uni-Bonn.DE)
Wed, 12 Jun 1996 16:04:13 +0200 (MET DST)

From: Bernd Kreimeier <Bernd.Kreimeier@NeRo.Uni-Bonn.DE>
Date: Wed, 12 Jun 1996 16:04:13 +0200 (MET DST)
Message-Id: <199606121404.QAA07166@colossus.nero.uni-bonn.de>
To: quake-dev@gamers.org
Subject: Re: PVS generation

From: Olivier Montanuy <montanuy@lsun80.lannion.cnet.fr>

>but wonder why the heck they need a BSP tree.

The advantage of a BSP is that there is an overall order
of polygons. If you can afford sorting, or have a fast
hardware z-buffer, and if there is no way to avoid
overdraw, or terminate a front-to-back traversal as soon
as the frame is complete, you do not need a BSP. Another,
even more important advantage lost is hierarchical
clipping (entire subtrees) against the view frustrum,
in object space.

The world has to be static if a PVS is used.

Btw., IBM's DOOM clone WebView3D switched from 2D BSP to
sector map usage. As for Descent and Duke Nukem, IIRC
these are restricted geometry engines (distorted cubes,
and DOOM-style), right? Of course one might get away with
less lookups in these cases.

As Michael Abrash quoted, "programming is an exercise in
caching". Necessary, of course, because of limited resources.

There is no way around hierarchical spatial subdivision.
Whether you use BSP, Octree, or something else is up to
you...

> Anyone who played Duke Nukem knows that a portal-based scheme
> is more flexible than a BSP based scheme.
> ...
> Calculate PVS on the fly, like every serious game does ;-)

You know, an interactive preview with a Quake editor could
actually put this to good use. This is what I had in mind with
the Difference Engine renderer: write your own. If it happens
to be too slow for actual gaming in the end, use it as a good
preview with an editor :-). You will learn a lot, one way or
the other.

b.