Re: PVS generation

Olivier Montanuy (montanuy@lsun80.lannion.cnet.fr)
Wed, 12 Jun 1996 17:48:50 +0200

Date: Wed, 12 Jun 1996 17:48:50 +0200
From: Olivier Montanuy <montanuy@lsun80.lannion.cnet.fr>
To: quake-dev@gamers.org
Subject: Re: PVS generation

> Another, even more important advantage lost is hierarchical
>clipping (entire subtrees) against the view frustrum,
I suppose portals can be checked against the view frustum, stopping the
rendering if they are outside.

>The world has to be static if a PVS is used.
Reasonably static, not totally static.
So long as all convex areas remain convex, and portals don't move...

> As for Descent and Duke Nukem, IIRC these are restricted geometry engines
Descent is restricted to cubes (but it can be generalised to any convex
blob). Duke is more restricted than Quake, but no normal gamer will ever
notice! Briges, slopes, superposed levels, ... of course water and lifts
are done with teleporters.

>As Michael Abrash quoted, "programming is an exercise in caching".

and "cashing". Or so they say in Redmond.


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

I wish I could! That idea raised almost 10 months ago when
hacking out the UQS 2.2. Never found enough time since!
That's why I lurk here, hoping someone will catch the bait.
Difference Engine is a good idea. Free time is a better one!

> If it happens to be too slow for actual gaming in the end,
Methink you'll soon call it Descent3 or Prey ;-)

Olivier