Merge pull request #17 from kanition/develop

第一章完成

content/chap01.tex

@@ -1,6 +1,7 @@
 \chapterimage{Pictures/chap01/nightsnow-cut1368.png}
 
 \chapter{绪论}\label{chap:绪论}
+\setcounter{sidenote}{1}
 
 \keyindex{渲染}{rendering}{render渲染}是
 由3D\keyindex{场景}{scene}{}描述生成图像的过程。
@@ -33,5 +34,10 @@ \chapter{绪论}\label{chap:绪论}
 
 \input{content/chap0105.tex}
 
-\section{基于物理的渲染简史}\label{sec:基于物理的渲染简史}
+\input{content/chap0106.tex}
 
+\input{content/chap0107.tex}
+
+\input{content/chap0108.tex}
+
+\input{content/chap0109.tex}

content/chap0103.tex

@@ -17,7 +17,7 @@ \section{pbrt：系统概述}\label{sec:pbrt：系统概述}
 再编译和链接到可执行文件，
 并且必须修改附录第\refchap{场景描述接口}中的对象创建例程
 以创建解析场景描述文件所需要的对象。
-\refsec{添加新物体的实现}
+\refsec{添加新对象的实现}
 \sidenote{译者注：原书此处似乎链接错误，已纠正。}
 将讨论这种扩展系统的方法的更多细节。
 
@@ -56,7 +56,7 @@ \section{pbrt：系统概述}\label{sec:pbrt：系统概述}
 
 本节有许多pbrt扩展版本渲染的图像。
 其中从\reffig{1.11}到\reffig{1.14}
-\sidenote{译者注：原书\reffig{1.14}引用文献似乎遗漏了链接，推测是\citep{10.1145/74334.74361}。}
+\sidenote{译者注：原书\reffig{1.14}引用文献似乎遗漏了链接，推测是\citet{10.1145/74333.74361}。}
 都引人瞩目：
 它们不仅令人过目不忘，而且每张都是渲染课程的学生在
 最后的课程作业中为pbrt扩展新功能渲染得到的有趣图像。
@@ -129,16 +129,16 @@ \subsection{执行阶段}\label{sub:执行阶段}
 \begin{figure}[htbp]
     \centering\includegraphics[width=\linewidth]{chap01/furrydog.png}
     \caption{Jared Jacobs和Michael Turitzin为pbrt增加了
-        Kajiya和Kay基于纹素的毛发渲染算法\citep{10.1145/74334.74361}并渲染了该图像，
+        Kajiya和Kay基于纹素的毛发渲染算法\parencite*{10.1145/74333.74361}并渲染了该图像，
         狗毛和粗毛地毯都是用纹素毛发算法渲染的。}
     \label{fig:1.14}
 \end{figure}
 
-\reffig{1.15}和\reffig{1.16}由\emph{LuxRender}渲染，
+\reffig{1.15}和\reffig{1.16}由\emph{LuxCoreRender}渲染，
 它是最初基于本书第一版pbrt源码的GPL许可的基于物理的渲染系统
-（关于\emph{LuxRender}的更多信息详见\url{https://luxcorerender.org}
-\sidenote{译者注：\emph{LuxRender}已更名为\emph{LuxCoreRender}且
-    迁移到了新网址。此处已更正了网址。}）。
+（关于\emph{LuxCoreRender}的更多信息详见\url{https://luxcorerender.org}
+\sidenote{译者注：原文的LuxRender现已更名为LuxCoreRender且
+    迁移到了新网址，此处已更正。}）。
 
 \begin{figure}[htbp]
     \centering\includegraphics[width=\linewidth]{chap01/measure-one180-cut1260.png}

content/chap0106.tex

@@ -0,0 +1,100 @@
+\section{使用和理解代码}\label{sec:使用和理解代码}
+
+我们用C++写成pbrt但限制使用艰深的语言特性，让非C++专家也易读。
+紧贴核心语言特性还有利于系统的可移植性。
+特别地，我们避免了多重继承、运行时异常处理
+以及对C++11和C++14特性的过度使用。
+此外我们只用了C++扩展标准库的一小部分。
+
+\subsection{指针还是引用？}\label{sub:指针还是引用？}
+C++提供了两种不同的机制来向函数或方法传递
+数据结构的地址：\keyindex{指针}{pointer}{}和\keyindex{引用}{reference}{}。
+如果函数参数不会当做输出变量，
+则用任意一种都可以节约在堆栈上传递整个结构的开销。
+按惯例，pbrt在参数会被函数或方法完全改变时使用指针，
+在其一些内部状态会被改变但不会被完全重新初始化时使用引用，
+在根本不会被改变时使用{\ttfamily const}引用。
+这条规则的一个例外是当我们想传递{\ttfamily nullptr}来
+表示该参数不可用或不该用时我们总是使用指针。
+
+\subsection{抽象与效率}\label{sub:抽象与效率}
+设计软件系统接口的一大压力是在抽象与效率间作出合理的平衡。
+例如，许多程序员严谨地让类的所有数据都是{\ttfamily private}的
+并提供方法来获取或修改数据项的值。
+对于简单的类（例如\refvar{Vector3f}{}），我们认为
+这种方案不必要地隐藏了实现的基本属性——该类持有的三个浮点坐标——
+我们可以合理认为它们一直不变。
+当然，缺乏信息隐藏并暴露所有类内部全部细节的做法会导致代码维护的噩梦。
+但是我们认为在整个系统中审慎地暴露基本设计决策是没错的。
+例如事实是，由一个点、一个向量、赋予其范围、时间的值以及递归深度
+表示的\refvar{Ray}{}就不用隐藏在抽象层之后。
+当这些细节暴露时别处的代码会更简短易懂。
+
+当编写软件系统并做出此类时平衡时要时刻想到最终系统的预期大小。
+定义了全部基本接口、抽象和策略决策的pbrt核心
+（除了特定形状、光源等的实现外）代码不超过20,000行。
+向系统添加额外功能一般只需增加不同抽象基类实现的代码量。
+pbrt永远不会增长到百万行代码；
+用于系统中的信息隐藏量可以且应该反映出这一事实。
+设计接口来让系统适应那种程度的复杂度只会
+浪费程序员的时间（还可能降低运行时效率）。
+
+\subsection{代码优化}\label{sub:代码优化}
+通过使用优选的算法而不是局部的微小优化，
+我们尽量让pbrt足够高效，因此系统能更易懂。
+然而，我们将一些局部优化应用到了pbrt中
+占据大多数执行时间的某些部分，
+只要不会让代码太难懂即可。
+整个代码中主要用到了两条局部优化原则：
+\begin{itemize}
+    \item 在当下CPU架构上，最慢的数运算是除法、平方根和三角函数。
+          加法、减法和乘法一般比这些运算快10到50倍。
+          减少慢速数学运算的数量能大幅提高性能：
+          例如为了取代重复除以某值$v$，
+          我们常常预求倒数$\displaystyle\frac{1}{v}$再做乘法。
+    \item CPU的速度比数据从主内存加载到CPU的速度持续增长得更快。
+          这意味着等待从内存取出值会是主要的性能限制。
+          以从内存缓存获取高性能的方法组织算法和数据结构
+          比减少执行指令的总量更能极大加速程序的执行。
+          附录\refsec{内存管理}讨论了高效内存编程的一般原则；
+          这些思想大多数运用在了第\refchap{图元和交点加速}中的
+          光线交点加速结构和\refsub{MIP映射}，
+          尽管它们影响了整个系统中许多设计决策。
+\end{itemize}
+
+\subsection{本书网站}\label{sub:本书网站}
+我们在\href{https://pbrt.org/}{\ttfamily pbrt.org}上为本书创办了指南网站。
+网站包含了系统的源码、文档、pbrt渲染的图像、示例场景、勘误表
+以及bug报告系统的链接。
+我们欢迎你访问网站并订阅pbrt邮件列表。
+
+\subsection{扩展系统}\label{sub:扩展系统}
+我们编写本书和构建pbrt系统的目标之一是
+让开发者和研究者能用它更简单地在渲染中试验新（或旧！）的想法。
+计算机图形学的一大乐趣是编写新软件做出新图像；
+即便尝试对系统做出微小修改也是有趣的。
+全书的习题提出了许多修改系统的建议，
+从小的调整到大型开放式研究项目都有。
+附录\refsec{添加新对象的实现}有更多关于
+为列于\reftab{1.1}的抽象基类新增实现机制的信息。
+
+\subsection{反馈错误}\label{sub:反馈错误}
+尽管我们努力通过大量测试保证pbrt的正确性，
+但它必然还存在一些bug。
+
+如果你认为你在系统中找到了bug，请这样操作：
+\begin{itemize}
+    \item 用未经修改的pbrt最新版本复现bug。
+    \item 查询\href{https://pbrt.org/}{\ttfamily pbrt.org}上的在线论坛和bug追踪系统。
+          你的问题也许是已知的bug，或者是常被误解的特性。
+    \item 尽量找出最简单的测试样例来说明该bug。
+          许多bug可以用仅有几行长的场景文件揭示，用简单的场景比复杂的更容易调试。
+    \item 用我们的在线bug追踪系统提交详细的bug报告。
+          要确保包含了演示bug的场景文件和你为什么认为pbrt对该场景的处理不对的详细说明。
+          如果你能为代码提供补丁修复该bug就更好了！
+\end{itemize}
+我们会定期发布pbrt更新版本以修复bug和提供少量增强。
+（注意我们这样做之前经常会积攒几个月的bug；
+不要误以为我们不重视它！）
+然而，我们不会对pbrt源码做大的变动
+以致于和本书描述的系统不符。