基于patch的地形PVS数据预处理

PVS：Potentially Visible Set（潜在可见集）的缩写，方便起见以下可能会用小写

这里说的不是传统意义上的室内基于portal的pvs，而是存储室外地形块相互可见性的一张二维表，也许叫pvs不太准确但我不知道该叫什么。我们的地形目前是基于patch的，也就是如果1号patch看不到3号patch，那么pvsData[1][3] = false；反之就为true。当然这张表的每个元素只占用1个bit。

计算一下，数据量基本是可以接受的，例如内存中维护32 * 32 = 1024个patch，那么最终的数据量就是1024 * 1024 / 8 = 128k。如果每个patch要维护多个高度级别的pvs数据（也就是说摄像机处于不同高度时采用不同的pvs数据，这样更精确，效果更好），那么这个数字再乘以n，以当前pc的内存来说不会有什么问题。

但是预先生成这些数据却需要极大的计算量。粗略估计一下，这个问题的算法复杂度基本是O(n^6)！如果n代表地图的边长尺度的话。因为总共的patch数量是n^2的，而且要计算他们两两见的可见情况，n^4了，而计算是否可见时，又要考察其它所有patch是否成为中间的阻挡，于是就n^6了。当然，可以比较快的剔除不可能阻挡的patch，但至少也有n^5的复杂度。也就是说地图尺寸增大一倍，预处理pvs数据的开销就会是原来的32倍以上。

哦，好像还没有说为什么需要pvs剔除，这里插播一下。从两方面考虑：对于cpu来说，目前的地形是基于patch的LOD的，每帧需要动态生成vertex buffer和index buffer提交渲染（之前考虑过始终用一个静态VB࿰