Re: [Algorithms] Re: Portal VS BSP

[Alen L. <ale...@cr...>]

> 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? ;)

LOL. I didn't say that you are a bad person. Nor ment it. ;) Just said that we
have different opinions in a very subjective area.

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

Wait a minute... portals vs. PVS vs. dynamic visibility. When did they
multiply? I believe there were only two of those. :)
By dynamic visibility I ment using portals in runtime. I don't know of any
useable zone-based system with runtime visibility where you don't use portals.
What exactly are we talking about here?

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

What we were using was dynamic visibility based on portals and with occluders
put in the whole soup. So you get occluder fusion at run time, with little
extra costs. What you are talking about here is a dynamic visibility scheme
_without_ occluders, right? And, if I understand, when you say "dynamic
visibility" I have a feeling that you think of something else than what I do.

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

Generating BSP tree is fast. Making portals is fast. The brute force method
proposed here is actually quite simple and efficient. I got 2.5sec to build
BSP and 1.1sec to find portals for a 9000 polygon mesh - actually a
patological case with >2000 sectors - in my old test app, running it on 1.7GHz
Athlon. So I know for those two from personal experience. I don't know about
that lighting vs. vis part. Just know that by John Carmack's own words,
rebuilding a level for Q1 would take 2.5 hours on a 90MHz P1. So it might
take, roughly approximated, cca 7 minutes on a 1.8GHz processor. That's for a
Q1 level. If you have some numbers from your PVS preprocessor, I would be
interested to hear.

Alen