书评：3D Game Engine Design - 完

可能有同名的书，我这里指的是David H. Eberly著的，第二版的具体小题目是“A Practical Approach to Real-Time Computer Graphics”。

 

首先可以很快就说明的是，如果你在寻找一本关于游戏引擎的书，那么这本书可能很大程度上不是你想找的。你要找的书名字更可能是“Game Engine Architecture”，作者Jason Gregory。David的这本书，着重点在它的小题目中，大多数是在讲游戏引擎中的实时图形引擎。作者原来的意思，可能觉得3D图形引擎在整个游戏引擎中算是重中之重，所以起名叫游戏引擎设计也无妨。但是，这点在书名的角度，有误导人之嫌。所以，如果你要找一本3D图像引擎的书，这本书就是你要的。如果你找一本涵盖游戏引擎的书，那么这本书不是你想要的。

 

在我写下这篇文章的时候，这本书在亚马逊上得到的分数是四星，那么可以算是一本大家都觉得有价值的书了。如果你上亚马逊搜索3D Game Engine Design的话，搜出的结果中应该包含David的同系列书的第一版，第一版在亚马逊上的分数高于第二版。但是，除非你是好书控（收藏控），那么不建议买入第一版。理由很简单，第一版的所有设计是基于固定流水线的（David本人在第二版中很多地方都提到这个），也就是说没有任何着色器（shader）的篇幅，所有的设计流程也是架构在固定流水线的基础上的。现实的硬体架构和开放给用户的API现在却是非shader不能成事（DX10已经取消了固定流水线）。所以，第一版只能做收藏，要拿出来实战，恐怕有问题。当然不是说现在那些程序跑不起来了，至少在DX9，固定流水线在API层级还是可以跑起来的。问题在于现在你看的新的技术中，有太多的东西都是基于着色器的。如果你固守在固定流水线上，岂不是丢了个很大的西瓜？

 

如我在这篇文章开始就讲到的，这本书不会如很多人看题目就期望到的，是一本完整介绍一个/类游戏引擎的书，但你也不必看到此就做下决断不买这本书，请听我慢慢道来。David在第二版的介绍中(1.2章节，第二段)，自己就提到第一版的名字误导了很多买书的人，因此收到了不少批评。大多批评的读者是因为本来以为一本书名为3D Game Engine Design的书，就是能完整介绍一个游戏引擎的大多数模块的书。呃，我想开始我也这么想。但是这本书在这方面没有那么完整，事实上，David的书重点介绍的是3D引擎，而不是3D Game引擎。简单来说，一个3D引擎只能是3D Game引擎的一个子集，而不是全部。但是，瑕不掩瑜。在3D引擎书来说，David的书可算是我看过的最好的书了（到写下这篇文章为止，排除非英语书籍。这里注意，我讲的是3D引擎，而不是3D图形，图形书好书就多了）。

 

介绍这本书，还有一个必然需要介绍的是书作者，David H. Eberly的背景。David本人是数学的学士、硕士、博士这么上来的（当然他同时也是计算机科学的博士），因此这本书，数学非常之多 (老外用词"heavy"），而且这些数学都不是用浅显的方式说出来的，跟作者本身的数学背景有关。如果要读，google加上其他的数学书放在手边做参考是必须的。当然，作者如果对数学模型不仅是提到，还做深入阐述的话，我相信这本书也不止这么点厚度，相应的，价格也就不止这么点了。

 

数学是一个特点。另外一个特点是，David组织章节的方式，如果从章节的题目来看，很多对3D引擎没有经验的读者相信开始都一头雾水，因为似乎毫无章法。我想事实上也如此，David虽然组织相关的章节介绍整个书本各章节的内容，但是却对引擎本身的目标没有介绍。所以整本书乍看之下凌乱，没有章法。因为David并没有告诉每个章节在引擎中的位置，如果你不知道这些章节在引擎中该在的位置，也就意味着你可能读着读着就只是在读书了。你会忘掉本来需要这本书帮助你做些什么。我相信古人说的“读书百遍，其义自现”的说法。但是我更深信当代人需要读的东西更多，不能把一本书真的读百遍，所以，如果你要把这本书读百遍才能知道这本书的好处，那么你还是赶紧找另外一本书吧。为了弥补这本书在这方面的缺陷，让更多的人知道这本书的好处，我这里对此书做一下提纲挈领的补充：全书的核心部分在第四章“Scene Graphs“，这一章开篇就讲到了Scene的作用。我相信这也是一个3D引擎围绕处理的问题。其他的章节，第四章前大多属于3D常识的叙述，给读者介绍一些相关的知识，可以看做是写一个3D engine必然会遇到的信息。第四章后面的很多章节，属于围绕核心的每个helper，这些东西很多都是一个常用的3D engine必备的。但是它们属于周边，跟核心一起组成一个引擎。就我看来，如果读第四章能读得懂David讲的东西的话，其实也就知道David对整本书的章节是怎么组织的了。你也就提到了那个所谓的纲领了。这个时候我相信你也能理解Dave（David的另外一个名字）为什么那样组织章节。不过话说回来，如果Dave能在书开头处着重写一下一个3D engine的重要任务，把这个概念理一下，会对很多的读者有帮助。

 

但是话说回来，Dave的文笔还是易读的。如Scene Graphs那章开头，几个逻辑图就把核心问题交代了出来。如果书本都这样，不遮遮掩掩而一针见血，人类社会是不是会更加的进步？ :)

 

我个人对一个渲染引擎，也就是中间件，该实现的目标看法是：用户界面的清晰和功能的完整；同时内部架构相当有弹性，能从容应付未来的改变。但我们无法拿这个目标来评测这本书，因为如Dave所说，他的目的还是写这本书来教学。我同意这一点，写书应该具备一定的通用性，前瞻性（这一点我想不应该苛求PC游戏界的作者，因为硬件实在是发展太快了，但是实际使用中的硬件水平千差万别、参差不齐）。就这点上，我想这本书的内容也是可以圈点的。一个3D引擎应该具备的功能，Dave大多都提到，如游戏中用到的CLOD、anmiation controller和常用shader等等。而且在说明这些功能的时候，David能根据自己在一线工作的经验来说明一些设计上的概念，显示了在实际运用中的取舍。我想这个是不同于学院派的在理想环境中做实验的方式，就更容易给一线的引擎程序员带来实际的指导意义。这些应该跟Dave本人曾经在Numerical Design Ltd. 做NetImmerse引擎的设计者经历有关，这个引擎也就是现在的商业引擎Gamebryo的前身。因此，如果你正在用Gamebryo，翻翻这本书，说不定能发现不少你感兴趣的地方。

 

另外一个可以说道的地方是，我对涉及程序的书，向来觉的如果没有相关代码实现，就无法说透细节。所谓差之毫厘、谬以千里，用在程序设计上再准确不过。在这个行内的人，都会有找到资料，初看惊喜；一旦着手工作，却总觉资料不足的经历。如果书作者有跑的起来的源代码，其实最好。一则说明作者验证过自己的想法，二则用侯捷的话说”源码之前，了无秘密“。我从来不赞成没有理论支撑下的源码阅读（如果你正在进行这类阅读，请注意你是否可以参考一些相关的理论，确认这是你唯一的方法）。如果用现在的标准来看，没有附带源码的书籍的确也是个麻烦，搞的不好就是个鸡肋（不是所有的书籍都是这样，原则上需要看它讲的内容是偏实战还是偏理论概述的）。在这点上， Dave的这本书恰恰也算是好书。随书赠送完全可以编译的代码，而且不仅是引擎代码，还有相关的示例代码。因此入手就可以耍完一番。如果对照书籍，就知道每个例子在书中的位置。更可贵的是，书本身有支持网站（糟糕的是，在国内你可能需要FQ）。网站上有大量的更新、修正，甚至是数学模型的pdf文件打包下载。OMG，慷慨的Dave。据我最近一次上该网站的经历来看，Dave还在不停的修改这个引擎的版本。不管他是不是为了第三版，我们都可以先睹为快。

 

结论是：在3D渲染引擎这个领域，该书应该是英语书籍中的佼佼者。

 

补充内容：

一、引擎相关的几个层次杂谈

DX和OpenGL封装了底层绘制primitive的细节，让3D程序员从实现线条怎么画、面怎么填充；实现点和矩阵、向量和向量等的计算细节（那可是光敲代码就累死人的事）；实现back-buffer、z-buffer、stencil buffer具体怎么样被管理的细节；实现Gauroud、Phone算法；实现剪切等等琐碎事情解脱出来。有了DX和OpenGL，这些事情，3D程序员只要通过相应API设置就可以了。DX和OpenGL是3D中很底层的一个层次。

 

3D引擎在这个层次上组建，根据对不同游戏类型的支持，可能会有不同的需求。如FPS引擎，可能就需要封装Portal、BSP等算法和提供相应工具，因为用户对室内环境的细节会很容易辨别，那么某种精度的bump mapping就少不了 （如Quake 4中用了Parallax Mapping） 。如果是RPG引擎，可能就需要封装terrain算法，因为用户会在大的场景内移动。MMORPG算是更复杂的一种，也许就需要现在能用到的大多数技术。跟上面的DX和OpenGL一样，这个模块同样完成很多细节的事情，而用给用户提供API的方式实现生产效率的提升。用户不用关心BSP的实现、LOD的实现，而只是根据引擎本身提供的API和工具，知道怎么跟引擎打交道就可以。

 

3D游戏引擎是更高的一个层次，也是更复杂的一个模块。如果不是刻意划分，加上引擎工具的话。用业内的话，我们更愿意把这个层次叫做解决方案（solution。当然上面的层次你也可以说是solution，看有做的多复杂）。这个层次的目的是最大程度的用工具整合所有相关的人员，然大家协同工作，把一个游戏从无到有”生产“出来。效率是主要评测标准。

二、我对“实时”概念的解释

首先，实时（real-time）表达的意思是需要在一段给定的很短的时间内给出结果。但是这个很短的时间是没有具体数值可以界定的。对于一般游戏来说，交互式标准是30帧每秒，也就是如果33ms内能完成用户交互画面的渲染就完全能流畅应付玩家需求。在这样一个应用中，33ms或者更小就是个实时的界限。再举游戏为例，对赛车游戏，可能需要60帧每秒，那么如果用33ms做界限，这个就不能满足实时要求。在工控、自动化应用系统中，操作系统（OS）都讲究实时性，也就是OS在多少时间界限内一定能处理完一个动作的基准。为了保证这种实时性，芯片上一般都会有看门狗之类的辅助设计，看门狗需要OS在每个界定的时间内去触发一下自己，否则就认为OS进入了失控状态。这种方式，用来严格的实现实时需求。

 

在图像渲染领域，有实时的方式和非实时的方式，后者被称为离线渲染。实时方式多应用在交互式运用中，因为时间的有限性，会追求速度和画面的平衡性。游戏是个例子，如我们上面举到的赛车游戏的例子；离线渲染注重画面效果的真实性或细节性，时间不是问题。影视制作是个例子，如在很多影视中，我们看到的一帧电影画面，可能是单台计算机或者一个计算机集群渲染数天的结果。