Merge pull request #50 from kanition/develop

fix 4.4-4.6

content/chap0404.tex

@@ -206,7 +206,7 @@ \subsection{树的构建}\label{sub:树的构建}
 如果没有为构造函数给定，则还有必要确定树的最大深度。
 尽管树的构建过程通常会自然地在合理的深度结束，
 但限制最大深度很重要，这样极端情况下树所用的内存数量才不会无限增长。
-我们已经发现值$8+1.3\log(N)$为大量场景给出了合理的最大深度\sidenote{译者注：对数以2为底。}。
+我们已经发现值$8+1.3\log_2N$为大量场景给出了合理的最大深度。
 
 \begin{lstlisting}
 `\initcode{Build kd-tree for accelerator}{=}`
@@ -233,7 +233,7 @@ \subsection{树的构建}\label{sub:树的构建}
 std::vector<`\refvar{Bounds3f}{}`> primBounds;
 for (const std::shared_ptr<`\refvar{Primitive}{}`> &prim : `\refvar[KdTreeAccel::primitives]{primitives}{}`) {
     `\refvar{Bounds3f}{}` b = prim->`\refvar[Primitive::WorldBound]{WorldBound}{}`();
-    `\refvar[KdTreeAccel::bounds]{bounds}{}` = `\refvar[Union2]{Union}{}`(bounds, b);
+    `\refvar[KdTreeAccel::bounds]{bounds}{}` = `\refvar[Union2]{Union}{}`(`\refvar[KdTreeAccel::bounds]{bounds}{}`, b);
     primBounds.push_back(b);
 }
 \end{lstlisting}
@@ -339,14 +339,14 @@ \subsection{树的构建}\label{sub:树的构建}
 访问kd树的节点比访问BVH节点的开销更少。
 
 针对用于BVH树的SAH的一点修改是，对于kd树值得稍微偏好选择
-其中一个孩子没有与之重合的图元的划分，
+使其中一个孩子没有与之重合的图元的划分，
 因为光线穿过这些区域可以立即进行到下一个kd树节点而无需任何光线-图元相交测试。
 因此，未划分和划分后区域的改进开销分别为
 \begin{align*}
     t_{\text{isect}}N \quad \text{和} \quad t_{\text{trav}}+(1-b_{\mathrm{e}})(p_BN_Bt_{\text{isect}}+p_AN_At_{\text{isect}})\, ,
 \end{align*}
 其中$b_{\mathrm{e}}$是为零的“补贴”\sidenote{译者注：原文bonus。}值，
-除非两个区域之一完全为空，此时取值0到1。
+除非两个区域之一完全为空时取值0到1。
 
 有了为开销模型计算概率的方法，唯一要解决的问题是
 怎么生成候选划分位置以及怎么为每个候选者高效计算开销。
@@ -574,7 +574,12 @@ \subsection{树的构建}\label{sub:树的构建}
 回想在kd树节点数组中该节点的“下方”孩子的节点序数是当前节点序数加一。
 在递归从树的这一侧返回后，偏移量\refvar{nextFreeNode}{}被用于“上方”孩子。
 这里唯一的重要细节是内存{\ttfamily prims0}被直接传入给两个孩子复用，
-而{\ttfamily prims1}指针则首先向前推进。
+而{\ttfamily prims1}指针则首先向前推进
+\sidenote{译者注：这段内容较难，笔者的理解是：由于\refvar{KdTreeAccel::buildTree}{()}在构建
+过程中会原位修改传入的{\ttfamily prims0}和{\ttfamily prims1}，所以需要保护现场。
+左子树构建完成后，{\ttfamily prims0}的内容就没有用处了，可在右子树构建时被覆盖；
+但构建左子树时不能变动还未构建的右子树所需的{\ttfamily prims1}，
+所以需要挪到新存储位置{\ttfamily prims1 + nPrimitives}。}。
 这是必要的，因为当前对\refvar{KdTreeAccel::buildTree}{()}的调用取决于
 下文中它首次递归调用\refvar{KdTreeAccel::buildTree}{()}时贮藏的{\ttfamily prims1}值，
 毕竟它必须作为参数传给第二次调用。
@@ -616,7 +621,7 @@ \subsection{遍历}\label{sub:遍历2}
     给出了要考虑的初始参数范围$[t_{\min},t_{\max}]$。
     (b)因为该范围非空，所以这里需要考虑根节点的两个孩子。
     光线首先进入左侧孩子，标记为“near”，有参数范围$[t_{\min},t_{\text{split}}]$。
-    如果近处节点是含有图元是叶子节点，则执行光线-图元相交测试；
+    如果近处节点是含有图元的叶子节点，则执行光线-图元相交测试；
     否则处理其孩子节点。(c)如果该节点内没有找到命中处，或者找到的命中处
     超出了$[t_{\min},t_{\text{split}}]$，则处理右边的远处节点。
     (d)继续该过程——按深度优先处理树节点，从前往后遍历——直到
@@ -709,8 +714,8 @@ \subsection{遍历}\label{sub:遍历2}
 现在需要确定光线遇到孩子节点的顺序使得是沿光线按从前往后的顺序遍历树的。
 \reffig{4.18}展示了该计算的几何结构。
 射线端点关于划分平面的位置足够区分两种情况，
-现在忽略光线实际上没有穿过两个节点之一的情况。
-射线端点位于划分平面上的罕见情况需要仔细处理，
+现在忽略光线实际上没有穿过两节点之一的情况。
+射线端点位于划分平面上的罕见情况需仔细处理，
 需要改用它的方向来区分两种情况。
 \begin{figure}[htbp]
     \centering\input{Pictures/chap04/Raybelowabove.tex}

content/chap0405.tex

@@ -37,7 +37,7 @@ \subsection{网格}\label{sub:网格}
 拥有对网格的单个索引，而且每个网格也只有单个图元索引。
 他们证明了该表示有很低的内存使用量且仍然非常高效。
 
-Hunt和Mark \parencite*{4634613}证明了在透视空间中构建网格，
+Hunt和Mark \parencite*{4634613}证明在透视空间中构建网格，
 即投影中心是相机或光源时，能让追踪相机或光源发出的光线高效得多。
 尽管该方法需要多种加速结构，但从为不同种类光线专门设计的多种结构中获得的性能提升可以很高。
 他们的方法也因在某种意义上是栅格化和光线追踪的中间地带而令人瞩目。
@@ -119,7 +119,7 @@ \subsection{包围盒层次}\label{sub:包围盒层次}
 Lauterbach等\parencite*{10.1111/j.1467-8659.2009.01377.x}引入了线性BVH。
 Pantaleoni和Luebke \parencite*{10.5555/1921479.1921493}在树的上层用SAH开发了HLBVH推广型。
 他们还注意到莫顿编码值的高位可用于高效寻找图元群集——两种思想都用于我们HLBVH的开发。
-Garanzha等\parencite*{10.1145/2018323.2018333}对HLBVH引入更多改进，
+Garanzha等\parencite*{10.1145/2018323.2018333}对HLBVH引入了更多改进，
 它们大多数都针对GPU实现。
 
 不像HLBVH路线，这里\refvar{BVHAccel}{}中的BVH构建实现没有并行化。
@@ -144,7 +144,7 @@ \subsection{kd树}\label{sub:kd树}
 我们的\refvar{KdTreeAccel}{}遍历代码一定程度上是基于它们的。
 
 pbrt中kd树构建算法的渐进复杂度是$O(n\log^2n)$。
-Wald和Havran \parencite*{4061547}证明了用一些额外实现的复杂度可以在$O(n\log n)$时间内构建kd-树；
+Wald和Havran \parencite*{4061547}证明了用一些额外繁琐的实现可以在$O(n\log n)$时间内构建kd-树；
 它们为典型场景报告了$2$到$3\times$的构建时间加速。
 
 光线追踪最好的kd树是用“完美划分”\sidenote{译者注：原文perfect splits。}构建的，
@@ -240,15 +240,15 @@ \subsection{加速结构的其他话题}\label{sub:加速结构的其他话题}
 然后光线逐步穿过四面体直到它们与来自场景描述的三角形相交。
 该方法仍慢于最新kd树和BVH数倍，却是思考该问题的一个新的有趣方式。
 
-在kd树和BVH直接有个有趣的中间地带，树节点为每个子节点持有划分平面而不是只有单个划分平面。
+在kd树和BVH之间有个有趣的中间地带，树节点为每个子节点持有划分平面而不是只有单个划分平面。
 例如，这一改进使得能在像kd树那样的加速结构中作物体划分，
 把每个图元放入仅一个子树并允许子树重合，
 但仍保留了kd树高效遍历的许多好处。
 \citet{10.1007/978-3-642-72617-0_17}\sidenote{译者注：未找到原文引用文献的信息，
 译文改用同年同名同第一作者但发表位置不同的文献。}首次
 将该改进引入到kd树中用于排序空间数据，命名为“空间kd树”
 \sidenote{译者注：原文spatial kd-tree。}（skd-tree）。
-skd树最近以及被许多研究者应用到光线追踪，包括
+skd树最近已经被许多研究者应用到光线追踪，包括
 \citet{10.1145/585740.585761}、Woop等\parencite*{10.1145/1283900.1283912}、
 W\"{a}chter和Keller \parencite*{10.5555/2383894.2383912}、
 Havran等\parencite*{4061548}以及Zuniga和Uhlmann \parencite*{2151237X.2006.10129224}。

content/chap0406.tex

@@ -2,14 +2,14 @@ \section{习题}\label{sec:习题04}
 
 \begin{enumerate}
     \item \circletwo pbrt中两种加速结构最坏情形下的场景是什么样的？
-          （考虑方法无法分别处理好的特殊的几何配置。）
-          构建具有这些特点的场景，度量pbrt随着你增加更多图元的性能。
+          （考虑方法无法分别处理好的特殊几何配置。）
+          构建具有这些特点的场景，度量pbrt随着你增加更多图元后的性能。
           其中一者的最坏情况用另一个渲染的表现如何？
     \item \circletwo 实现层次化网格加速器，改进与大量图元重合的格子
           而不是用更细的子网格存储其几何体。
           （例如见Jevans和Wyvill \parencite*{Jevans1989:23}解决
           该问题的一种方法以及Ize等\parencite*{4342587}决定何时细化是值得的高效方法。）
-          比较两个加速器以及本章的加速器对于非层次化网格的构建性能和渲染性能。
+          比较两个加速器以及本章的加速器针对非层次化网格的构建性能和渲染性能。
     \item \circletwo 为构建加速器实现更智能的重合测试。
           用物体的边界框确定它们重合于kd树划分的哪一侧可能因为造成不必要的相交测试而有损性能。
           因此向形状接口添加方法{\ttfamily bool \refvar{Shape}{}::Overlaps(const \refvar{Bounds3f}{} \&) const}，
@@ -33,15 +33,15 @@ \section{习题}\label{sec:习题04}
           一般许多原本是轴对齐的三角形旋转得多了就会有非常宽松的边界框，
           如果不用分割剪裁就会导致巨大的性能减退。
     \item \circletwo \refvar{BVHAccel}{}中HLBVH构建算法所用的30位莫顿码
-          对于大型场景就能不够（注意到它们每个维度只可表示$2^{10}=1024$步）。
+          对于大型场景可能不够（注意到它们每个维度只可表示$2^{10}=1024$步）。
           把\refvar{BVHAccel}{}改成用64位整数，其中63位莫顿码给HLBVH。
           用各种场景比较你的方法与原始方法的性能。
           有性能极大提升的场景吗？有性能下降的场景吗？
     \item \circletwo 为构建BVH或kd树研究替代的SAH开销函数。
           差的开销函数会多大损害其性能？比起当前的有多大提升？
           （见“扩展阅读”一节关于可以怎样改进SAH的讨论。）
     \item \circlethree \refvar{BVHAccel}{}尤其是\refvar{KdTreeAccel}{}的构建时间
-          会在整个渲染时间中占有重要分量，除了HLBVH外，本章的实现不会并行化构建加速结构。
+          会在整个渲染时间中占有重要比重，除了HLBVH外，本章的实现不会并行化构建加速结构。
           研究例如\citet{4342588}和Shevtsov等\parencite*{10.1111/j.1467-8659.2007.01062.x}
           描述的加速器并行化构建技术，并在pbrt中实现其中一个。
           在加速器构建中你取得了多少加速？用额外的处理器加速了多少？
@@ -78,5 +78,5 @@ \section{习题}\label{sec:习题04}
           Lacewell等\parencite*{4634616}建议为空间区域用预先筛选的方向多变的遮挡表示
           来增广加速结构。当阴影射线穿过这些区域时，会返回近似的可见性概率
           而不是二元结果，减少树的遍历以及物体相交测试的开销。
-          在pbrt中实现该方法，和当前实现比较其性能。在渲染的图像中你看到了什么变化吗？
+          在pbrt中实现该方法，比较其和当前实现的性能。在渲染的图像中你看到了什么变化吗？
 \end{enumerate}