Scene Management --- Culling

来源:互联网 发布:2016陕西网络知识竞赛 编辑:程序博客网 时间:2024/04/30 21:32

Scene Management --- Culling

仅供个人学习使用,请勿转载,勿用于任何商业用途。 

 

   上次说到场景很大,物体很多时,每帧都把所有物体传递给渲染系统是不可能的。考虑到所见区域只是场景中的一小部分,因此,剔除视野之外的物体,就显得尤为重要,也就是常说的裁剪。本质上,裁剪算是碰撞检测的一部分,通过碰撞检测判断物体是否在视锥之内,但他和游戏里一般的碰撞检测还是有很大区别的,所以不能混为一谈。当然,上次一的引擎流程图也稍稍进化了一点:


    具体如何实现裁剪的过程呢?假设1w×1w米的区域内有1w个物体,最初级的算法就是遍历1w个物体,计算他们是否与视锥相交。非常不幸的是这个过程同样非常缓慢,也许只能让我们的程序从n spf(seconds per frame)提升到1或者2fps。于是有聪明人发现把整个区域细分为n个子区域,只要子区域在视锥之内,那么子区域内的物体也必然可见,这种分割方法通常称为均匀网格(uniform grid)。对均匀网格来说,决定网格的大小是个难题,如果把场景细分为1×1的区域,那么相比最初的方法,几乎没有改进。而如果子网格太大,当整个视锥都在某个网格内,或者与网格相交时,仍然必须计算子网格内的每个物体是否在视锥内,最不幸的情况下,也许恰好1w个物体都在这个子区域中,那么性能依然很糟。所幸这样的情况很少发生,所以总的来说,均匀网格在效率上有了很大提升。

    按照细分网格的思想,完全可以对子网格进一步进行细分,所以类似四叉树,八叉树等等的空间划分算法被引入了裁剪。为了简单,下面仅以四叉树为例。显然,四叉树解决了均匀网格划分粒度大小的问题,它的多级层次划分,既能保证让大量物体迅速被剔除,又能保证裁剪精度。

    四叉树非常适合户外场景(比如wow大部分主城以外的区域),但对于室内场景,地下城,或者物体相互遮挡非常严重的室外场景(比如城市),却有些力不从心。四叉树对空间所有方向进行划分,而室内场景/地下城通常只沿几个方向延伸(区域a---区域b---区域c),户外城市虽然方向均匀,但遮挡严重,处在视锥内的物体并不一定是可见的。
 
    Portal也许是室内场景最好的划分方法:把空间分为大量相连的区域,并且预计算出在某个区域内可以看到的其他区域,比如在A方间内只能看到走廊B,那么显然其他区域内的物体就不用渲染了。这种裁剪过程更像是数据库查询而不是碰撞检测,效率非常高。但预计算可见性的过程却非常麻烦,而且对关卡设计的要求也很较高,我们希望在某个区域内可看到的额外区域尽可能少(比如1个),同时又要保证关卡的合理性,艺术性。
 
    对城市来说,视锥内物体的可见性计算也非常重要,比如NFS这样的游戏,视锥内的物体也许非常之多,真正可见的却只有临街的那些。于是有了遮挡剔除(Occlusion cull)的概念,计算某个物体是否被其他物体挡住。概念虽然很简单,但相对前面几种裁剪方法,实现起来要复杂的多,超出了本文讨论范围。
 
    现在到了最有趣的部分,我们可以把上面几种算法组合起来!比如在最高层次,把世界划分为较大的匀网格(比如500×500),这样的分割除了能快速裁剪大部分区域外,还让我们获得了动态加载场景的功能,1w×1w的区域内,只加载潜在可视范围内的n*n个子网格,随着视点的移动,不停加载/卸载子区域。接下来,为了保证裁剪的高效,对每个子网格再进行四叉树细分。更进一步,如果是室内场景,四叉树节点内可以包含portal节点,最后,如果protal节点所占的空间区域很大,还能继续用四叉树或者Occlusion cull细分对protal节点细分!实现细节上,只要保证所有方法都继承于Culler,我们可以派生出任意多种可互相嵌套的裁剪算法。

     最后还要说一点,如果某个物体既在视锥之内,又没有被遮挡,那是否就一定要渲染它呢?考虑视锥内一把离观察者很远的杀猪刀:),也许投影光栅化之后,它只占屏幕中的几个像素,观察者完全无法分辨究竟是杀猪刀还是指甲剪。这种情况下,完全可以忽略这个物体。最简单的方法:用物体的包围盒面积与观察者之间距离的关系来作为参考。

 
      下一次,将是关于碰撞检测的内容,to be continue………………

 

 

原创粉丝点击