人力资源知识新算法框架

1、（人力资源知识）新算法框架20XX年XX月多年的企业咨询豉问经验.经过实战验证可以落地机行的卓越管理方案，值得您下载拥有elvishray 新算法框架Version2.0.0.0Len3dCopyright ? 2007 Len3d .Allrightsreserved.、户 、.前言本文描述了壹种渲染器的新算法框架，只是我个人对elvishray 的建议，仅供参考。需求分析mentalray 是壹个极其优秀的混合渲染器，尤其是它的光线追踪功能，做得非常好，非常智能，尽量用最少的光线取得最好的结果(很好的采样分布算法和自动减少无效采样) ，但它依然是基于传统的光线追踪算法框架发展而来的，按我的

2、使用经验，这带来很多问题。于 mentalray 中 ， 对 不 同 的 光 线 类 型 ， 如eyeray,shadowray,reflectedray,refractedray,finalgatherray等，均要分别做不同的优化，导致算法非常复杂，而各种光线的表现又不尽相同，导致使用时很难预测各种光线的行为，也就很难预测达到的效果和渲染时间，这对于产品级的制作是很大的麻烦，意味着开支预算变得困难。虽然mentalray尽量让参数的变化直接和渲染时间的变化呈线性关系，但对于reflectedray和 refractedray，众所周知，其递归光线追踪的过程构成壹颗二叉树形式，称为光线树，这

3、样对于K 次反射 /折射， R 个象素，总供需要计算的光线数目近似于(2 k+1 -2)R条， 这是呈指数增长的， 所以递归层数K 壹深， 整个渲染过程马上就慢下来了， 更糟糕的是，如果再开启阴影，每个交点处至少发射壹条阴影测试光线，更壹般的，开启区域阴影时，不妨设每个交点处平均发射m 条 shadowray ， 则所需的光线总数约为 (2k+1 -2+m(2 k-1)R 条，这种增长非常可怕，而且不同的特效同时开启时，速度的变慢不是简单的线性组合，而是会相互影响，这就是为什么单独打开mentalray 的某壹种特效，速度尚可接受，但同时打开几的平衡，需要大量的试验和人工参数调整，需要使用者有

4、非常丰富和老道的使用经验，即使如此，调整mentalray 诸多的复杂而神秘的参数，依然是壹种痛苦的折磨。总结起来，mentalray 于这方面的缺点主要有：基于传统的光线追踪算法框架， 各种特效增加的渲染时间和象素 （包括自适应采样产生的子象素）数目成正比。因此，假如你只想增加景物边缘的反走样，而不于乎反射 /折射的精细程度， mentalray 依然发射更多的反射/ 折射光线， 忠实的增加渲染时间。各种光线类型的优化方法不统壹， 算法复杂维护困难， 且对于产品级的应用， 难以预测渲染时间的开销，难以预测且保证最终效果，总是要求用户试了才知道。无论 mentalray 如何优化其算法，反射/

5、折射光线，依然和反射/ 折射层次数呈指数增长关系。同时开启多种效果时， 渲染时间不是单独开启各种效果时渲染时间简单的线性组合，而是会相互影响。例如，射/ 折射层次增加亦会使阴影光线数目呈指数增长。参数复杂而且神秘， 难于调整， 需要极为丰富的使用经验。 想要达到效果和渲染时间的平衡，需要大量反复的调整和试验，影响制作效率。针对这些问题，我设计了如下这种新算法框架，希望能有助于解决这些问题，其实该架构也非常简单，其核心思想依然是分而治之的思想，我借鉴了 Reyes 的思想，且对Reyes和光线追踪算法中各自的壹些概念进行了推广，提供了壹种统壹的架构。算法框架描述1. 光线类型的推广Reyes 算

6、法只处理壹种光线类型，就是mentalray 中称为 eyeray 的光线，它只渲染观察者直接可见的景物， Reyes 仍有壹个区别于mentalray 这类光线追踪渲染器的主要特点，就是将 HiddenSurfaceRemoval （简称 hiding ）和 shading 过程分开，这样的好处是，增 加物体边缘的反走样， 不会增加多少渲染时间， 因为更耗时的 shading 过程由另壹个和象素数目 （由采样数目控制） 无关的参数shadingrate 控制。 我将 shadingrate 的概念由 eyeray推广到各种光线类型， reflectedray,refractedray,sha

7、dowray,finalgatherray等均有各自的shadingrate ， 且规定它们的 shadingrate 均不小于 eyeray 的 shadingrate ， 这样我们为每块由细分和镶嵌生成的 microgrid ， 匹配壹系列分别对应于各种光线类型的 irradiancecache（这里借用且推广了 irradiancecache 的概念） ，每当壹块 microgrid 被某条光线击中时，便对整张 microgrid 上的每个顶点进行针对视点的 shading （这虽然可能导致浪费壹部分shading 结果，可是能够充分利用 SIMD 且行计算加速，甚至能够利用 GPU ）

8、 ，这就涉及到如何执行用户编写的 shader 程序的问题了。因为我们规定其余各种光线的 shadingrate 总不小于 eyeray 的 shadingrate ，所以于 Reyes 针对视点细分生成的 microgrid 上的每个顶点进行 shading 总是正确的。然而，以 reflectedray 为例，对 microgrid 上的每个顶点均计算反射往往是不必要的， 所以我们能够根据reflectedray 的 shadingrate ， 只对 microgrid上的壹部分顶点计算反射， 这部分顶点通过于 microgrid 上按相应间隔取隔行和隔列的顶点获得。 若要利用 SIMD

9、且行 shading ， 我们需要有RenderMan 壹样的编译器和 SIMD 虚拟机， shader 代码执行到调用 trace_reflect 函数的时候，便收集 microgrid 上需要计算反射的 点 （ 这 些 点 被 称 为 reflectedpoints ， 相 应 的 有refractedpoints,shadowpoints,finalgatherpoints等） ，利用基于SIMD 的且行光线追踪壹次性得到计算结果， 而对于 microgrid 上剩余的未计算反射的点， 则由 microgrid 良好的性质能够简单的通过插值相邻的 reflectedpoints 获得，同

10、样由 trace_reflect 函数返回插值结果，这样，我们不必为 finalgatherrays 构建特别的基于八叉树或其它特殊数据结构的irradiancecache ， 而将 irradiancecache 的概念推广到所有光线类型， 统壹了它们的处理方irradiancecache 的值，对不同法，这同时也是对Reyes 算法的壹种扩展。值得注意的是，的 光线类 型，可能 是 view-dependent 的，也可 能是 view-independent 的 。对于 view-dependent 的那些，比如 reflectedirradiancecache,refractedirr

11、adiancecache ，它 们均仅是针对场景中唯壹的视点( eyerays )有效，而对于从其它点发射出的光线则是不正 确的， 因此对于 secondaryrays 和景物相交时的 shading ， 我们则按传统的方法单独为该点 计算反射 / 折射等效果，且不使用 irradiancecache 中的值，当然，参考Razor 架构的做法，对于 shadinglanguage 的 predefinedvariables 中那些 view-independent 的变量，如 N,dPdu,dPdv 等(如果我们假设shading 总发生于 cameraspace 中的话) ，我们能够像irr

12、adiancecache 壹样壹次计算好且储存下来反复使用，而对于其中那些view-dependent的变量，如 P,I 等，则每次均重新计算。对于那些 view-independent 的 irradiancecache ， 如 shadowirradiancecache,finalgatherirradiancecache， 无论光线从哪个视点发出， 均能够使用 cache 中的值，这样避免了重复计算，同时由于我们只于有光线击中某块microgrid时，才对该microgrid计算光线所需的 irradiancecache 值，这是 lazyevaluation 或说deferredsha

13、ding 的思想。 2. RussianRoulette 方法的推广前述对光线类型的推广，有望于我们前面对mentalray 的算法复杂度的分析中，以壹定比例减小R这个因子，设有 n种光线类型，则相当于将 R分解为Ri,R2,Rn的线性组合，且各种光线的Ri 因子中， 由各自的 shadingrate 决定， 但这依然只是降低了复杂度中的线性因子，而复杂度中更主要也更可怕的真正反映光线追踪特性的递归光线追踪部分的因子，却没 有 降 下 来 ， 即 2k+1 -2+m(2 k-1) 这 部 分 。 回 顾 PhotonMapping 算 法 中 很 重 要 的RussianRoulette 方法

14、，每次获得壹个交点时，只是随机的根据光照模型中各项系数因子的大小选择壹种光线类型，且只发射壹条光线，如果我们借用这种方法(允许类似mentalray通过 shader 实现） ，那么递归光线追踪部分的因子就会降为K ，整体的复杂度能够近似表示成K（Ri+R 2+Rn）。然而应注意到，RussianRoulette方法虽然能够通过理论证明是正确的，但当 R 不够大（超采样不足）时，产生的图像会有很多噪点。为了解决这个问题，回顾PhotonMapping 中使用 RussianRoulette 为什么会正确，因为最终渲染时，需要使用densityestimation 或 finalgather 等

15、技术来估计表面上各点的间接照明值， 这实际上能够理解 成 壹 种 filtering 过 程 ， 考 虑 microgrid 本 身 的 结 构 ， 很 容 易 进 行 相 邻 顶 点 的irradiancecache 中的值的 filtering ，这能够理解为推广的 irradiancefiltering 技术，这种技术有壹个缺陷， 由于壹个物体很可能会被分割成多个相对独立的 microgrid ， 对 microgrid边界处的顶点进行irradiancefiltering会造成瑕疵， 当然这能够通过保持 microgrid 分割边界之间的连接关系来解决， 但这样使得各个microgri

16、d 不能独立处理， 注意到 Reyes 中计算microgrid边界处的 dPdu,dPdv 等值时，也会遇到类似的困难，我们能够借用类似的解决方法，比如让每块microgrid 稍微比实际的大壹些即可。另外，对于finalgather ，由于microgrid 本身的良好结构，很容易实现相邻顶点间的 neighborclamping 算法，以消除景物边角处的光亮度瑕疵，而不用设计特别的数据结构。Multi-resolutionGeometryCaching和 RayDifferentials基于观察，我认为能够得到这样壹个事实：近处较大（近大远小的道理）的景物，其被反射的影像于渲染图像中壹般

17、也较大，远处较小的景物，其被反射的影像于图像中壹般也较小。或者能够阐述成景物的照明属性通常对其周围的景物影响最大，而对距之较远的景物影响较小，即具有照明属性的局部性，允许粗糙的近似甚至忽略不计。除了壹些特殊的情况，比如拿壹个放大倍率很高的放大镜， 见极远处的壹个小景物。 因此我们壹般能够按Reyes 算法对场景中所有景物进行细分（或镶嵌，下同） ，而对于反射/ 折射等光线，能够直接使用同壹份细分几何数据，而不需要另外细分，这通常不会因细分不足而于图像上产生瑕疵，而且仅使用壹份细分几何数据(称为 singlegeometrycache ) ，同时节省了计算量和内存用量， 且且不会产生由于相邻多条

18、光线各自对应的细分层次不壹致而于图像上造成裂痕的问题，对内存的使用量及细分所需时间的预测也变得容易了壹些。注意到 Reyes 只处理位于视棱域( frustum )内的景物，而光线追踪算法需要处理所有景物，且 Reyes 的细分是通过将景物透视投影到屏幕空间， 根据其包围盒大小和shadingrate 控制的， 而位于投影平面前的景物，不能很好的透视投影到该平面上，但又注意到这部分景物往往亦具有前述的照明属性的局部性，其可见部分只能通过影响和之相靠近的位于视棱域内的景物而表当下最终渲染图像上，所以我们对其进行到投影平面的平行投影(而非透视投影) ，以此决定其细分精度，而对位于 Z 轴另壹侧的不

19、直接可见的景物，我们利用镜像性质，应用和上述相应的法则进行细分，同样使离视点较近的景物细分得较精细，离视点较远的景物细分得较粗糙，这称为对称细分法。虽然使用 singlegeometrycache 壹般能够得到较理想的结果，但也存于如前面举例的放大镜问题，对于该类问题， RenderMan 中光线追踪的解决方法是类似MIP-MAP 算法，构建同壹 microgrid 的多分辨率细分拷贝 (即 Multi-resolutionGeometryCaching ) ， 于渲染时动态的计算raydifferentials ， 按其大小选择合适的 geometrycache 拷贝， Razor 的方法也

20、很类似，但它会对相邻的拷贝按raydifferentials 大小进行插值。无论如何俩种方法均十分复杂，同时需要特别处理麻烦的裂缝问题，而放大镜这种情况且不常见，我认为更简单更容易控制的方法是像Reyes 壹样，允许单独调整某个景物的 shadingrate ，比如于放大镜问题中，我们只需适当减小放大镜中能够见到的细分不足的景物的 shadingrate 即可，然而于放大镜的放大倍率非常大时，该景物可能会被分割得非常精细，但实际上它于渲染图像中直 接 可 见 的 部 分 却 非 常 小 ， 于 是 这 对 Reyes 算 法 是 壹 种 伤 害 ， 所 以 我 引 入 了Multi-typeG

21、eometryCaching 的概念，即对每个物体，均对应每种光线类型持有壹份细分拷贝，这样相同类型的光线总和同壹份拷贝求交，因此不会产生裂缝。于壹般情况下，每个物体只持有壹份针对eyeray 的 eyegeometrycache ，其它光线类型的 geometrycache 简单的指向它，而只有于用户手动调整另壹种光线类型的 shadingrate 时，才针对该光线类型生成相应的 geometrycache (例如针对reflectedray 就生成 reflectedgeometrycache ) ，这有利于用户直接控制且预测细分数量，简单而不失灵活性。因此，于渲染中能够不需要计算rayd

22、ifferentials ，或者能够考虑利用 raydifferentials的估计，使不同类型的 shadingrate 的值的选择自动化，不必人工干预。Multi-resolutionkd-tree使用 Multi-resolutionGeometryCaching 的壹个好处是，对于大的 raydifferentials ，cache 中包含更多的景物，但景物能够分割的更粗糙些，对于小的 raydifferentials ， cache中包含更少的景物， 但景物应分割的更精细些。 这个性质使得 cache 能够保持相对固定的大小。为了于基于kd-tree加速的光线追踪算法中利用这个性质，

23、我们需要稍微改进壹下kd-tree 的结构，如图：通常于 kd-tree 中追踪每条光线的复杂度为 O(logN) ， N 为景物数目， 为了保持 kd-tree的加速性质，而不因为使用了 Multi-resolutionGeometryCaching 而改变，我们必需能够动态改变 kd-tree 的结构，但改变之后所得的形态应该和按传统的 kd-tree 方法构造的形态相似 (如果采用按物体分组的方式， 每个物体均构建自己单独的 kd-tree ， 假设有 M 个物体，则算法复杂度变为 O(Mlog(N/M) ，且 O(Mlog(N/M)=O(logN) ，即使使用了层次包围盒算法， 复杂度

24、也是O(Mlog(N/M)=O(logN) ， 且增加了算法盒储存结构的复杂度， 故不采用该方法) ，考虑几何体分组的方式，若按物体分组，则不能很好的反映景物于空间中的分布，故不合理。因此我们不必按照物体分组，而直接按kd-tree 的结点分组，将位于同壹个结点中的所有景物当作壹个处理单元，由此得到如图所示的 kd-tree 结构，它保持了kd-tree 方法构造的形态kd-tree 的加速性质，即改变细分层次之后所得的形态和按传统的的性质,相似， 且以结点作为基本处理单元。 为了保持 Multi-resolutionGeometryCaching我们于实现中采用延迟载入的思想，且依然动态构建

25、kd-tree ，算法步骤如下：当光线进入某个node 时， 检查是否已分割过 （分割指将node 中景物按分割平面分类，建 立 childrennodes 的 过 程 ） ， 若 未 分 割 过 ， 则 按 照 未 经 细 分 的 几 何 体 （ 称 为top-levelgeometry ， 如 NURBS ， SubdivisionSurfaces 等， 这种几何表示方式的好处是非常节省储存空间）的包围盒分割，直至满足分割终止条件，建立leafnode ，若 leafnode 中只有能够直接快速光线追踪的基本图元，比如 polygons 或 triangles 等，则光线直接和这些图元求交

26、，若leafnode 中包含更复杂的 top-levelgeometry ，则需要进壹步细分为基本图元，比如 microgrid 等，然后再光线追踪（因为大量研究指出细分后再追踪依然优于直接光线追踪，不只是速度上，仍有对于软件体系结构的设计和维护等方面更有利） ，这种leafnode 称为 expandingleafnode 。这时，我们根据光线的 raydifferentials ，决定所需的细分层次 leveln ，且依次生成壹系列从level0 到 leveln 的细分拷贝，我们能够用增量法避免重复计算， 这要求细分和分割交替进行， 比如对于 level0 我们直接用 expanding

27、leafnode中的景物对应的 microgrid 拷贝 （因为已满足分割终止条件） ， 对于 level1 ， 我们先细分level0中的景物， 再进壹步按终止条件分割， 同样， 我们生成所有不同精度的 expandingleafnode ，且将它们储存再磁盘文件中，而只将风格平面的信息放于内存中（增量法仍使高层次结点的分割平面的选择更快，因为此时只按细分较粗糙的 microgrid 选择分割平面，而不用于大量完 全 细 分 后 的 microgrid 中 选 择 ） ， 当 光 线 进 入 expandingleafnode 时 ， 先 按raydifferentials 选择壹个细分层次

28、， 当光线进入某个sub-leafnode 时，才载入相应的细分拷贝，且求交， expandingleafnode 及其子结点均有壹标记标明它们各自由哪个细分层次生成，若细分层次对于当前raydifferentials 不够精细，则同样用增量法补充生成细分层次，且追加到磁盘文件中，这种改进后的 kd-tree 称为 Multi-resolutionkd-tree 。GeometryInstancingGeometryInstancing 使得我们于渲染成千上万个相同物体的实例时只需要大约壹个该物体的内存用量，我们依然获取每个物体的包围盒，按照包围盒分割且构造kd-tree （因为壹个包围盒的数

29、据量几乎和壹个三角形的数据量壹样多，所以，为每个三角形储存其包围盒且不能减少多少内存用量，但总比没节省的好） ，因为于不同方位的实例，其shading 结果也不相同，所以应于top-levelgeometry 中储存和实例数目相同的多份irradiancecache拷贝，分别对应于不同实例，但这样又会导致irradiancecache 所需的内存量过大。该方法的主要创新之处有：不使用紧缩的 BoundingBox ， 而直接于建立leaf 时利用结点的包围盒对三角形进行裁剪（虽然更复杂，可是毕竟只进行壹次） 。运用了俩遍法使得GPIT（GeometricPrimitiveIndexingTab

30、le） 连续顺序储存的实现成为可能。使 用 GPIT ， 且将 光线变 换回 景物局 部空 间求交 。 对 MotionBlur ， 先按 shutteropen 和 shutterclose 的矩阵变换光线，再对所得光线本身插值。Ray-tracingOfArbitraryGeometry为了光线追踪任意的几何体（假设是该几何体总能转换为 micropolygon ，最终转换为triangles 或 motiontriangles ， 因为我们选择kd-tree 作为光线追踪核心的加速结构， 因此这里的讨论均是针对kd-tree 的） ，我们不可能预先细分生成足够精度的三角形逼近，随后再建立

31、 kd-tree ，且进行光线追踪，因为于高质量渲染中，完全细分产生的三角形数量往往过于巨大而难以直接处理，所以我们需要壹个动态的光线追踪框架，它能够根据当前光线指定的精度要求（通过raydifferentials 计算） ，动态的改变几何体的细节等级，即动态的改变所生成的三角形的数量和形状，而这又导致kd-tree 的结构必须做出相应的调整，且且我们应当适当的控制内存使用量，既不能使用过分多的内存，也不能每次均重新细分(Retessellation) 几何体， 导致大量的计算， 这就要求我们有适当的 caching 策略。 最好的情况就是能够将内存用量限制于壹定的范围，而于此范围中，能够渲染

32、无限制大小的场景，且且将渲染时间最大化，为了实现这壹点，我们有壹个全局的 geometrycache ，当渲染中需要申请新的内存块，而内存用量又超出用户预设的限制时，我们则通过LeastRecentlyUsed(LRU)算法，踢掉旧的内存块，而让新的几何体使用这块内存。很明显，这要求我们将算法中动态生成的几何体，作为 cache 的壹部分，能够按需求删除和重建，假设我们已经有了这样壹套cache 系统(我们的确有) ，当下来考虑要对系统做什么改变，且引入了什么新算法。我们将首先描述 GPIT 算法时如何实现GeometryInstancing 的，随后针对动态光线追踪对其进行扩展。GPIT 是

33、 GeometricPrimitiveIndexingTable 的缩写，作为壹张表，其最显著的特点就是它于内存中确实是壹张连续存放的表，即它是壹块连续的内存块，这样很明显的好处就是访问起来更加高效，而且只需要为每个带有GPIT 的结点分配壹次内存，而不像很多实现中壹样，需要多次分配，这明显提高了光线追踪的效率。 GPIT 中且不储存真正的几何数据，而是连续储存表示几何数据相对于基地址的索引值，和基地址本身。这样虽然增加了壹次间接寻址，比直接储存几何数据访问起来慢壹些，可是因为 GPIT 本身比较小，很可能完全位于 CPU 的高速缓存中，而且其中储存了下壹个几何体的位置，所以总能通过CPU 的

34、预取指令提前预取下壹个几何数据，提高缓存命中率，进而提高几何数据的访问速度。 GPIT 正是通过储存几何数据的索引值来轻松的实现GeometryInstancing ，于光线追踪过程中，我们遍历GPIT ，通过间接寻址访问几何数据，每次遇到壹个新的物体实例( ObjectInstance ) ，我们均将光线按照物体实例的 cameratoobject 矩阵变换到物体的局部坐标系，如果物体实例有 transformmotionblur即有通过对物体实例的空间变换产生的运动模糊，则我们能够先对 cameratoobject 矩阵和 motioncameratoobject 矩阵按照光线所对应的时间

35、进行插值，然后再变换光线。但由于对矩阵本身进行插值比较复杂，需要分解矩阵为不同的变换部分，按各自的特点分别进行不同类型的插值，再组合起来，而对矩阵做简单的线性插值又会产生扭曲的结果，所以我们能够先分别按照这俩个矩阵对光线进行变换，再对得到的俩条光线按照时间插值，获得局部坐标系中的光线后，即可和GPIT 中索引值所指的几何数据进行求交，这样，无论壹个物体有多少个物体实例，只需要储存多个GPIT ，而不需要储存多个真实的几何数据，而GPIT 本身相对较小，所以这极大的节省了内存。下面我们讨论如何扩展GPIT (eXtendedGPIT ，简称XGPIT ) ，使之能够处理动态光线追踪。 XGPIT

36、 及关联数据结构如图所示：MTGP 是 MultiresolutionT essellatedGeometricPrimitives 的缩写，每个primitive对应壹个 MTGP ， 其中包含了该primitive 各个细节层次的镶嵌表示。需要保证MTGP 中每次 Retessellation 后生成的三角形顺序均和之前的顺序相同。能够考虑增量式细分，即后壹层次的细分表示于前壹层次的细分表示的基础上生成，只计算且储存那些新加入的顶点。生成于相应结点包围盒内的 sub-GPIT 。为了加速，能够将静态的 triangles 和 motiontriangles 合且到 sub-GPIT 中。将

37、 sub-GPIT 放入对应的 kd-tree 结点中分割，建立sub-tree 。各个 primitive 相互独立的细分，生成各自对应的 MTGP 。RT 时，对动态部分进行俩步查找，先按patchID 找到 patch ，然后于 patch 中按当前光线的 raydifferentials 决定的细分层次寻找相应的 sub-triangleID 指示的三角， 和之求交，这里去掉了指针的概念， 因为 flushable 几何体均能够重建， 所以先按 ID 查找， 若不存于则重建(通过Retessellation ) 。XGPIT 将几何体分为俩部分储存，静态和动态部分。这样的好处是改变动态

38、部分时，静态部分不受影响，因为只有动态部分需要重建，这允许我们单独处理动态部分，而且能够很方便的将静态部分合且到动态部分中去统壹处理。静态部分即不会再改变的 triangles 和motiontriangles 部分， 而动态部分是我们讨论的重点， 这里面能够包括任意的高级几何体，这是壹个指向高级几何体指针的列表，为了增强系统的灵活性，能够泛化对高级几何体的操作，这样我们便拥有了壹个能够任意添加新的几何体类型的开放系统（类似REYES） ，我们再 这 里 将 所 有 高 级 的 GeometricPrimitives 统 称 为 primitive ， 这 能 够 包 括ParametricSurfaces,NURBSSurfaces 和 SubdivisionMeshes 等。 首先， 我们见见 kd-tree当下的基本结构如图：因为我们只是扩展了 GPIT ，所以不必改变kd-tree 结点的结构，而且对于XGPIT 所指的 sub-tree ，能够重用同样的原先为 kd-tree 写的建立和遍历代码。当下的光线追踪过程为，首先， primitives 得到其包围盒，因此primitive 需要壹个抽象的 Bound 操作，随后按照 pr