PVS generation

Troy Stephens (tstephens@wesleyan.edu)
Tue, 11 Jun 1996 12:05:00 -0400

Date: Tue, 11 Jun 1996 12:05:00 -0400
From: Troy Stephens <tstephens@wesleyan.edu>
To: "Quake Developer's List" <quake-dev@gamers.org>
Subject: PVS generation

(Please forgive my ignorance if this topic has already been discussed; I'm
a newcomer to this list.)

I'm interested in sharing ideas and info regarding visible-surface
determination in general, and the techniques Quake uses in particular.

I just got through reading Mike Abrash's Jan/Feb '96 DDJ article "Inside
Quake: Visible Surface Determination", and I'm left with one big question
in particular: I understand how a BSP tree annotated with potentially
visible set (PVS) info can be used to speed culling and reduce overdraw.
But how exactly is the PVS precomputed?

I spent a little time thinking about it this morning, and it certainly
seems to me that the key lies in judiciously choosing a few sample points
within a convex subspace to serve as representative viewpoints. Once you
have a suitable set of sample viewpoints, you should be able to determine
which leaves are definitely not at all visible from ANY of the sample
points, and that presumably gives you the PVS for that convex subspace.
(I think of it as calculating a PVS for each sample viewpoint, then
merging the PVSs for all the sample viewpoints conservatively, so that a
leaf is only kicked out of the PVS for the subspace if it isn't visible
from ANY of the sample viewpoints.)

I suspect that maybe the corner vertices of a convex subspace might serve
as suitable representative viewpoints (i.e. that they can be used to
generate a correct PVS for the subspace in this way), but I haven't yet
thought about it enough to prove or disprove this to myself.

Anyone have any ideas, experience, insights (or inside info?) in this area?