Re: [Algorithms] Re: Portal VS BSP

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

> The fact that it isn't generally suitable for PS2 suggest that it has a
> reasonable CPU overhead, which may also make it unsuitable for certain types
> of game on other platforms,

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.

> so the gain from using dynamic visibility has to
> be worth it in some way, and not just some academic exercise.

I already said that a PVS will always be faster (in visibility calculation)
than dynamic visibility at runtime. 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.

> What's wrong with this? Don't you optimise your strips, generate LODs, etc?
Yup we do. But to a certain level of payoff. In our book, 10% shaveoff in
runtime is not worth 2x slowdown in edit time. Again, a question of
standpoint.

> It depends what you mean by outperform. If you mean that a quickly generated
> PVS/portal scheme might draw more hidden stuff than some dynamic scheme,
> then this may be true, but this won't matter a jot if the dynamic scheme
> took over 50% of a frame to work out what to draw (which is why it is
> generally unusable on PS2 - so far).

I would need to try some on PS2 to be sure. For methods we used on PC and Xbox
were usually negligible or very small. While zone-based visibility for the
given scenes was perfect (no entirely occluded zone was rendered). However, it
is hard to argue since my data is a bit dated today, since geometry complexity
has changed drastically recently. I will be able to tell more once we have
some real data from our current project, which has more up to date triangle
counts.

> I think this is a pretty black and white way of looking at things. Any
> static visibility scheme can be embelished with certain dynamic
> capabilities. For example, opened/closed doors are very easy to simulate
> with both PVS and portal schemes. The same is true for occluder fusion, and
> it is almost certainly the case that you can reduce the runtime overhead of
> occluder fusion via preprocessing to determine potential fusions ahead of
> time (in a predominantly static world).

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

> > Hm... I don't have the source code of "vis" tool for Quake1
> > to check it out, but IIRC from some texts I read a long time
> > ago, it is just what it does. It makes a BSP, then portals
> > and then uses those portals to make the PVS. Maybe I confused
> > that with the old Seth Teller's PVS paper. Feel free to
> > correct me if I'm wrong.
>
> I'm not sure. I do know that plenty of people use sampling to generate the
> PVS, which does take ages and gives static visibility a bad name. :)

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

...has anything to do with actual code.

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

Cheers,
Alen