RE: [Algorithms] Re: Portal VS BSP

[Neil S. <ne...@r0...>]

> Don't want to argue about this. You believe that last ounce 
> of runtime performance is worth all the trouble you can stand 
> in content development process. I think not. So it is more of 
> the question of viewpoint.

Well, not quite. What I was saying (in the triangle stripper example) is
that it is nice to have your preprocessing methods be capable of giving that
last ounce of performance if you let them spend more time preprocessing. You
don't have to use them on "mega-optimise" mode all the time. I believe you
can have fast turnaround times as well as a little bit extra performance up
your sleeve if you need it. Does that make me a bad person? ;)

> It is obvious. Another thing that is obvious is that a proper 
> dynamic visibility will always be less conservative than a 
> PVS (since PVS cannot take exact view coordinates in 
> account). Whether the overconservativeness is worth the 
> visibility performance depends on your actual content.

True for PVS, but not for portals, although portals do generally have a
higher runtime cost than PVS, but not as high as dynamic visibility.

> Do you have any references for this PVS with occluder fusion? 
> This sounds interesting.

I was actually thinking about portals with occluder fusion, but I suspect it
could be done with PVS as well. No references, just something I've been
thinking about for a while, although someone out there may have written a
paper on it for all I know.

> Turns out that Quake1 did use the BSP->portals->PVS flow. At 
> least if this comment from "vis" below...
> 
> >// create the new portal by taking the full plane winding for the 
> >cutting
> plane
> >// and clipping it by all of the planes from the other portals

Sounds like they did do it "properly", which leads me to wonder why some
other people are using sampling-based methods.

> And if I recall, it was awfully slow at that time. Does 
> anybody have some more recent timings of such a PVS 
> preprocessor? Perhaps the odds changed drastically. (Though 
> it didn't look like simply waiting for Moore's law to fix it 
> would help, the last time I checked. ;) )

Well, generating the BSP tree can be very quick, but the portals may take
longer if a brute-force method is used (which is what the above sounds
like), although not *that* long. Are you sure you weren't also seeing the
time spent lighting the world, which was very slow?

Cheers,

- Neil.