场景管理：BVH （Bounding volume hierarchy） 相关内容

/

BVH全称：Bounding volume hierarchy。这是一种用来管理3D场景中物体的方法。

     我主要是在光线追踪算法中用这个方法来做加速，因为光线追踪算法的计算要求非常高，稍微好点的画质，至少要求每像素达到上千的采样数量。简单介绍下光线追踪算法：从相机发射射线到场景中与场景中物体进行相交检测，如果碰撞检测成功，则根据物体的材质计算颜色，然后计算反射或者折射光线的方向，继续跟踪这条新的光线，直到达到最大递归深度或者没有碰到任何物体。如果不采用BVH，那么每一条射线都需要和场景中的所有物体：球体、三角形等复杂物体进行相交检测，而这个检测时间是非常昂贵的，因为要计算直线和球体的相交，直线和三角形的相交等，这些计算都比较复杂，尤其是三角形这块。相交检测的时间是目前光线追踪算法从理论到大规模实际应用过渡的主要瓶颈。使用BVH呢，简单的来说就是通过一个简单的包围盒把物体包围起来，射线和场景中的物体求交之前，会先和这个包围盒进行求交，如果该射线没有碰到该包围盒，表明该直线一定不会和包围盒里的物体相交；如果该射线碰到该包围盒，那么再来计算射线是否和包围盒中的物体相交。

     最常用的一个bounding volumes 是 axis-aligned minimum bounding box，也就是通常说的AABB方法，就是用沿着坐标轴方向的能够刚好把物体包围起来的盒子（最小的盒子）来做bounding volumes。

     而场景中有很多物体，采用BVH其实是用二叉树的结构来管理场景。如下图：

     

    每一条射线来和场景中的所有物体检测是否相交的时候，其实就是在遍历这棵二叉树。

BVH和空间划分技术不同，它并不是通过切割空间来管理场景中的物件。它是通过将物体分堆，然后在其上面包裹一层BV，达到管理场景的目的。树的根节点是一个能够包裹全部物体的BV，而树的叶子节点可能只是一个物件的BV，如下图：

 BV可以选择AABB，OBB，包围球等等，往往包裹性越好的BV，相交测试越复杂，但是包裹性好可以减少相交测试的次数。这个世界有阴就有阳，计算机的二进制码也是0和1，我们生存的世界是不是也是一个虚拟的程序呢，哈哈跑题了。

父节点的包围体无需包裹子节点的包围体，但是需要包裹所有物体的BV。换句话说就是父节点无需包裹中间节点的BV，但要能包裹所有物体。

我们从树根节点开始遍历每个子节点，如果节点的BV不在视锥体中或者没有发生碰撞，那么这个节点下的所有物体都可以快速被剔除。

BVH和BSP有点像，太过灵活，虽然原理很简单，但是如何建树是一个比较头疼的问题。建树困难也就意味着这个技术不适合运行时期动态更新。BVH和BSP一样往往是在非运行时期对静态物体进行预计算。

我们不能盲目的构建一棵BVH，先把树的期望特征列出来，以这些特征为目标构建BVH。

子树中的节点应该彼此靠近，随着深度的增加节点间应该彼此更加紧凑。
层次结构中的节点应该是最小的包围体。
全部包围体体积之和应该保持最小。
应谨慎处理根节点附件的节点，与深层节点相比，删除根节点附近的节点往往意味着移除更多的物体对象。
兄弟节点间的相交体空间应该保持最小。
层次结构应该尽量保持平衡树
最坏情况下的查询时间不应超出评价查询时间太多(防止造成游戏帧数不平滑)
虽然是预计算，但也要考虑预计算的时间，每次更改场景都需要重新计算，计算时间太长很容易影响工作效率。
BVH应尽量控制内存的使用
有一个性能测试公式揭示了碰撞性能的消耗：

T = NvCv + NpCp + NuCu + Co

Nv是相交测试BV的数量，Cv是每次相交测试的消耗，Np是相交测试图元的数量，Cp是每次相交测试的消耗，Nu是需要更新节点的数量，Cu是更新节点的消耗，Co是一个常量消耗。

我们需要寻找一个折衷的方案来进行碰撞检测，写一个物理库不难，写一个高效的物理库很难。

树的构建策略

BVH可以自定向下构建，也可以自底向上构建，也可以插入的方式进行构建如下图：

自顶向下构建容易，但是通常不是最佳树。

自底向上构建复杂，但是可以获得最佳树。

插入构建，可以实现运行时更新。

/

//

/