RE: [Algorithms] Re: Portal VS BSP

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

> This is a matter of content turnover. In our team, we like to 
> optimize/eliminate preprocessing as much as possible, so that:
> a) artists can check the final results more often, improving 
> their overall productivity and
> b) in the final stages of production, when it matters the 
> most, new versions can be created more quickly. 
> 
> So if dynamic visibility buys you extra features (doors...) 
> _and_ removes preprocessing, it is very welcome. :) 
> 

Yes, but only if it gives you the runtime performance you require. Dynamic
visibility isn't much use if you can't realistically use it on, say, PS2.

Besides, you could vastly improve artist turnaround times by limiting the
level of optimisation in your PVS/portal builder, which would probably still
give you better performance than a dynamic visibility solution for viewing
and basic testing.

Also remember that dynamic visibility doesn't "buy" you doors, because you
can easily represent doors in a PVS/portal system.

> AFAIK, it is just what you do when you are calculating a PVS 
> from a BSP, isn't it? You build the portals first, by 
> subdividing bounding polygons lying on BSP split planes. It 
> is a very simple and fast method. 

If you are talking about building the PVS/portals directly from the tree's
topology, then yes. The question was about what current games were doing and
I only know of games using a sampling method to calculate the PVS or using
hand-built portals. There may be games which use the BSP's topology, but I
don't know of any. Perhaps someone else can think of some?

- Neil.