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

前面一篇说了pvs数据的预处理，当时是用纯CPU来计算patch之间的可见性。后来听说有个IDirect3DQuery9接口可以判mesh的可见性，就试了一下，果然比用纯粹CPU计算快了很多。计算同样的512地图的pvs数据，原来的算法需要4.7小时，利用GPU之后缩短到了不到800秒，快了大约20倍。更重要的是从不同尺寸地图的pvs预处理得到的大致算法复杂度估计从原来的 n ^ log_2( 48 )，降低到 n ^ log_2( 16 )。另外，新的算法在误差上比原来要少很多，只发现几处距离较远的patch有几个象素的跳变，可能是因为预处理用的表面较小（640x480）并且视角较大（pi / 3，实际游戏使用 pi / 4）

具体算法：

对于每个pvs单元，就是单个patch的一层，我们称为一个unit。每个unit分别朝若干个（我取8个）方向渲染（因为无法一次在屏幕上渲染所有的patch），每个方向：

    在unit上平面去若干个摄像机位置采样点，这里仍然取4个角及中心一共5个

    使用中心摄像机位对所有patch进行视锥剪裁，只留下视锥内的patch，注意这里要考虑多个摄像机位的情况，所以边界需要留得大一些。另外对于完全落在视锥内，也就是包围球整体落在视锥内的patch打上标记，同样指的是对于多个摄像机位都能完全在视锥内，所以这个边界需要比单个摄像机更严格一些。

    全部渲染剪裁后留下的所有patch，得到一个最终的z-buffer

    对所有完全落在视锥内的patch挨个单独渲染，查询它的可见性。对于IDirect3DQuery9接口的使用网上很容易查到，就不赘述了。

    如果一个目标patch对于一个unit内的所有的摄像机采样点来说都不可见，那么就认为它对于该unit是不可见的。注意渲染单个patch时，如果该patch之前已经判为可见就不用再渲染了。

这个算法有个小缺陷，就是对于一个unit的某个方向上的渲染，只有那些能完全落入视锥的patch才有机会被判为不可见的（因为如果patch有一部分在屏幕外，你无法判定它是否被遮挡），所以不同的方向之间必须有部分重叠，比如我取每个方向 pi / 3 的fov，一圈共采样8个方向。但即便如此，仍然会有一些距离摄像机比较近的patch会没有机会进行可见性判定，也就是说它们是永远可见的。我粗略统计这个数字大约是30~50个patch，考虑到它们离摄像机很近，本来可见的几率就比较大，所以我认为可以接受。如果要减小这个数字，可以采用更大的fov角或更多的采样渲染角度。