深度测试
现在我们开始讨论深度测试， 深度测试丢弃隐藏的像素，过度绘制开始起作用。过度绘制非常简单 – 在一幀中，你数次绘制一个像素位置。它以3D场景中Z（深度）方向上存在的元素数量为基础，也被称为深度复杂度。如果你常常太多的过度绘制， -- 举例来说, 符咒的眩目视觉特效，就象Heretic II，能让你的幀速率变得很糟糕。当屏幕上的一些人们彼此施放符咒时，Heretic II设计的一些最初效果造成的情形是，他们在一幀中对屏幕上每个相同的像素画了40次! 不用说，这必须调整，尤其是软件渲染器，除了将游戏降低到象是滑雪表演外，它根本不能处理这样的负荷。深度测试是一种用来决定在相同的像素位置上哪些对象在其它对象前面的技术，这样我们就能够避免绘制那些隐藏的对象。
看着场景并想想你所看不见的。 换句话说，是什么在其他场景对象前面,或者隐藏了其他场景对象? 是深度测试作出的这个决定。
我将进一步解释深度深度如何帮助提高幀速率。想像一个很琐细的场景，大量的多边形 (或像素)位于彼此的后面，在渲染器获得他们之间没有一个快速的方法丢弃他们。对非Alpha混合的多边形分类排序( 在Z- 方向上)，首先渲染离你最近的那些多边形，优先使用距离最近的像素填充屏幕。所以当你要渲染它们后面的像素（由Z或者深度测试决定）时，这些像素很快被丢弃，从而避免了混合步骤并节省了时间。如果你从后到前绘制，所有隐藏的对象将被完全绘制，然后又被其他对象完全重写覆盖。场景越复杂，这种情况就越糟糕，所以深度测试是个好东西。
抗锯齿
让我们快速的看一下抗锯齿。当渲染单个多边形时，3D 显卡仔细检查已经渲染的，并对新的多边形的边缘进行柔化，这样你就不会得到明显可见的锯齿形的像素边缘。两种技术方法之一通常被用来处理。 第一种方法是单个多边形层次，需要你从视野后面到前面渲染多边形，这样每个多边形都能和它后面的进行适当的混合。如果不按序进行渲染，最后你会看见各种奇怪的效果。在第二种方法中，使用比实际显示更大的分辩率来渲染整幅幀画面，然后在你缩小图像时，尖锐的锯齿形边缘就混合消失了。这第二种方法的结果不错，但因为显卡需要渲染比实际结果幀更多的像素，所以需要大量的内存资源和很高的内存带宽。 多数新的显卡能很好地处理这些，但仍然有多种抗锯齿模式可以供你选择，因此你可以在性能和质量之间作出折衷。对於当今流行的各种不同抗锯齿技术的更详细讨论请参见Dave Salvator 的3D 流水线一文。
顶点与像素着色
在结束讨论渲染技术之前，我们快速的说一下顶点和像素着色，最近它们正引起很多关注。顶点着色是一种直接使用显卡硬件特征的方式，不使用API。举例来说，如果显卡支持硬件 T & L ，你可以用DirectX或OpenGL编程，并希望你的顶点通过 T & L 单元 (因为这完全由驱动程序处理，所以没有办法确信)，或者你直接利用显卡硬件使用顶点着色。它们允许你根据显卡自身特征进行特别编码，你自己特殊的编码使用T & L 引擎，以及为了发挥你的最大优势，显卡必须提供的其他别的特征。 事实上，现在nVidia 和ATI 在他们大量的显卡上都提供了这个特征。 不幸的是，显卡之间表示顶点着色的方法并不一致。你不能象使用DirectX或者OpenGL 那样，为顶点着色编写一次代码就可以在任何显卡上运行，这可是个坏消息。然而，因为你直接和显卡硬件交流，它为快速渲染顶点着色可能生成的效果提供最大的承诺。( 如同创造很不错的特效 -- 你能够使用顶点着色以API没有提供的方式影响事物)。事实上，顶点着色
正在真的将3D 图形显示卡带回到游戏机的编码方式，直接存取硬件，最大限度利用系统的必须知识，而不是依靠API来为你做一切。对一些程序员来说，会对这种编码方式感到吃惊，但这是进步代价。 进一步阐述，顶点着色是一些在顶点被送到显卡渲染之前计算和运行顶点效果程序或者例程。你可以在主CPU上面用软件来做这些事情，或者使用显卡上的顶点着色。 为动画模型变换网格是顶点程序的主选。
像素着色是那些你写的例程，当绘制纹理时，这些例程就逐个像素被执行。你有效地用这些新的例程推翻了显卡硬件正常情况做的混合模式运算。这允许你做一些很不错的像素效果， 比如，使远处的纹理模糊，添加炮火烟雾, 产生水中的反射效果等。一旦 ATI 和 nVidia 能实际上就像素着色版本达成一致( DX9's 新的高级阴影语言将会帮助促进这一目标), 我一点不惊讶DirectX 和OpenGL采用Glide的方式-- 有帮助开始, 但最终不是把任何显卡发挥到极限的最好方法。我认为我会有兴趣观望将来。
最后（In Closing...）
最终，渲染器是游戏程序员最受评判的地方。在这个行业，视觉上的华丽非常重要，因此它为知道你正在做的买单。对于渲染器程序员，最坏的因素之一就是3D 显卡工业界变化的速度。一天，你正在尝试使透明图像正确地工作；第二天 nVidia 正在做顶点着色编程的展示。而且发展非常快，大致上，四年以前为那个时代的 3D 显卡写的代码现在已经过时了，需要全部重写。 甚至John Carmack 这样描述过，他知道四年以前为充分发挥那个时期显卡的性能所写的不错的代码，如今很平凡 -- 因此他产生了为每个新的id项目完全重写渲染器的欲望。Epic 的Tim Sweeney赞同 -- 这里是去年他给我的评论:
我们已经足足花费了9个月时间来更换所有的渲染代码。最初的 Unreal 被设计为软件渲染和后来扩展为硬件渲染。下一代引擎被设计为 GeForce 及更好的图形显示卡，且多边形吞吐量是Unreal Tournament的100倍。
这需要全部替换渲染器。很幸运，该引擎模块化程度足够好，我们可以保持引擎的其余部分—编辑器，物理学，人工智能，网络--不改动，尽管我们一直在以许多方式改进这些部分。
搭配长篇文章的短篇报导（Sidebar）：API -- 祝福和诅咒
那么什么是API? 它是应用程序编程接口,将不一致的后端用一致的前端呈现出来。举例来说，很大程度上每种3D显示卡的3D实现方式都有所差别。然而，他们全部都呈现一个一致的前端给最终使用者或者程序员，所以他们知道他们为X 3D显示卡写的代码将会在Y 3D显示卡上面有相同的结果。好吧，不管怎样理论上是那样。 大约在三年以前这可能是相当真实的陈述，但自那以后，在nVidia 公司的引领下，3D显卡行业的事情发生了变化。 如今在PC领域，除非你正计划建造自己的软件光栅引擎，使用CPU来绘制你所有的精灵，多边形和粒子 -- 而且人们仍然在这样做。跟Unreal一样，Age of Empires II: Age of Kings有一个优秀的软件渲染器 – 否则你将使用两种可能的图形API，OpenGL或者 DirectX 之一。OpenGL是一种真正的跨平台API (使用这种API写的软件可以在Linux，Windows和MacOS上运行。)， 而且有多年的历史了，为人所熟知，但也开始慢慢地显示出它的古老。 大约在四年以前，定义OpenGL驱动特征集一直是所有显示卡厂商工作的方向。
然而，一旦在目标达成以后，没有预先制定特征工作方向的路线图，这时候，所有的显卡开发商开始在特征集上分道扬镳，使用OpenGL扩展。
3dfx 创造了T- 缓冲。 nVidia 努力寻求硬件变换和光照计算。Matrox努力获取凹凸贴图。等等。 我以前说过的一句话，\过去几年以来，3D显示卡领域的事情发生了变化。\委婉地说明了这一切。
无论如何，另一个可以选择的API是 DirectX。这受Microsoft公司控制，且在PC 和 Xbox 上被完美地支持。由于明显的原因，DirectX 没有Apple或者 Linux 版本。因为Microsoft控制着 DirectX，大体上它容易更好地集成在Windows里面。
OpenGL和DirectX之间的基本差别是前者由‘社区’拥有，而后者由Microsoft拥有。如果你想要 DirectX 为你的 3D 显示卡支持一个新的特征，那么你需要游说微软，希望采纳你的愿望，并等待新的 DirectX发行版本。对于OpenGL，由于显示卡制造商为3D显示卡提供驱动程序，你能够通过OpenGL扩展立即获得显示卡的新特征。这是好，但作为游戏开发者，当你为游戏编码的时候，你不能指望它们很普遍。它们可能让你的游戏速度提升50%，但你不能要求别人有一块GeForce 3 来跑你的游戏。好吧，你可以这么做，但如果你想来年还在这个行业的话，这是个相当愚蠢的主意。
这是对这个问题极大的简单化，对我所有描述的也有各种例外情况，但这里一般的思想是很确实的。对于DirectX ，在任何既定时间你容易确切地知道你能从显示卡获得的特征，如果一个特征不能获得，DirectX 将会用软件模拟它(也不总是一件好事情，因为这样有时侯非常的慢，但那是另外一回事)。对于OpenGL，你可以更加贴近显示卡的特征,但代价是不能确定将会获得的准确特征。 第4部份: 模型与动画，细节级别
角色建模与动画
你的角色模型在屏幕上看起来怎么样,怎样容易创建它们,纹理,以及动画对于现代游戏试图完成的`消除不可信`因素来说至关重要。角色模型系统逐渐变得复杂起来, 包括较高的多边形数量模型, 和让模型在屏幕上移动的更好方式。
如今你需要一个骨骼模型系统，有骨架和网格细节层次，单个顶点骨架的评估，骨架动画忽略，以及比赛中停留的角度忽略。而这些甚至还没有开始涉及一些你能做的很好的事情，像动画混合，骨架反向运动学（IK），和单个骨架限制，以及相片真实感的纹理。这个清单还能够继续列下去。但是真的，在用专业行话说了所有这些以后，我们在这里真正谈论的是什么呢？让我们看看。
让我们定义一个基于网格的系统和一个骨骼动画系统作为开始。在基于网格的系统，对于每一个动画幀，你要定义模型网格的每个点在世界中的位置。举例来说，你有一个包含200 个多边形的手的模型，有 300 个顶点(注意，在顶点和多边形之间通常并不是3个对1个的关系，因为大量多边形时常共享顶点 – 使用条形和扇形，你能大幅减少顶点数量)。如果动画有 10 幀，那么你就需要在内存中有300个顶点位置的数据。 总共有300 x 10 = 3000 顶点，每个顶点由x，y，z和颜色/alpha信息组成。你能看见这个增长起来是多么的快。Quake I，II和 III 都使用了这种系统，这种系统确实有动态变形网格的能力，比如使裙子摆动，或者让头发飘动。
相比之下，在骨骼动画系统，网格是由骨架组成的骨骼( 骨架是你运动的对象)。 网格顶点和骨架本身相关，所以它们在模型中的位置都是相对于骨架，而不是网格代表每个顶点在世界中的位置。因此，如果你移动骨架，组成多边形的顶点的位置也相应改变。这意谓着你只必须使骨骼运动，典型情况大约有 50 个左右的骨架—很明显极大地节省了内存。
骨骼动画附加的好处
骨骼动画的另一个优点是能够根据影响顶点的一些骨架来分别“估价” 每个顶点。例如，双臂的骨架运动，肩，脖子而且甚至躯干都能在肩中影响网格。当你移动躯干的时候，网格就活像一个角色一样移动。总的效果是3D角色能够实现的动画更加流畅和可信，且需要更少的内存。每个人都赢了。
当然这里的缺点是，如果你想要使有机的东西运动且很好，比如说头发，或者披肩，为了让它看起来自然，你最后不得不在里面放置数量惊人的骨架，这会抬高一些处理时间。 基于骨骼的系统能带给你的一些其他事情是‘忽略’特定层次骨架的能力 -- 说,\我不关心动画想要对这块骨架所做的事情，我想要让它指向世界中的一个特定点\。这很棒。你能让模型着眼于世界中的事件，或者使他们的脚在他们站着的地面保持水平。这一切非常微妙，但它可以帮助带给场景附加的真实感。
在骨骼系统，你甚至可以指定\我需要把这个特别的动画用於模型的腿，而一个不同的携枪或射击动画在模型躯干上播放，且那家伙（角色）叫喊的不同动画效果在模型的头部播放\。非常妙。Ghoul2 ( 在Soldier of Fortune II: Double Helix and Jedi Knight I: Outcast中使用了Raven的动画系统 ) 拥有所有这些好东西，且特别被设计为允许程序员使用所有这些忽略能力。这对动画的节省像你一样难以相信。像你一样的动画上的这次救援不相信. Raven有一个角色行走的动画和一个站立开火的动画，并在它同时行走和开火形下把这两个动画合并，而不是需要一个动画表示角色行走并开火。
More Skeletons in the Closet
先前描述的效果可以通过具有层次的骨骼系统来完成。这是什么意思呢？意思是每块骨架实际上的位置相对于它的父亲，而不是每个骨架直接位于空间中的地方。这意谓着如果你移动父亲骨架，那么它所有的子孙骨架也跟着移动，在代码上不需要任何额外的努力。这是让你能够在任何骨架层次改变动画，而且通过骨骼其余部分向下传递的东西。
创建一个没有层次的骨骼系统是可能的 -- 但那时你不能忽略一个骨架并且预期它工作。你所看到的只是身体上的一个骨架开始了新动画，除非你实现了某种‘向下传递信息’的系统，否则在该骨架下面的其它骨架保持原来的动画。首先由一个层次系统开始，你就自动地获得这些效果。
许多今天的动画系统中正开始出现一些比较新的特征，如动画混合，从一个正在播放的动画转变到另外一个动画需要经过一小段时间，而不是立即从一个动画突然转变到另外一个。举例来说，你有个角色在行走，然后他停了下来。你不是仅仅突然地转变动画，让他的腿和脚停在无效位置，而是一秒钟混合一半，这样脚似乎自然地移到了新的动画。不能够过高的评价这种效果 -- 混合是一个微妙的事情,但如果正确的运用，它真的有些差别。
反向运动学
反向运动学 (IK) 是被许多人们丢弃的一个专业术语，对它的真实含义没有多少概念。IK 是如今游戏里面一个相对比较新的系统。使用 IK ，程序员能够移动一只手，或一条腿, 模型的其余关节自动重新定位，因此模型被正确定向。而且有模型的关节新位置的其馀者他们自己，因此模型正确的被定向。比如，你将会说,\好，手 , 去拾起桌子上的那个杯子\并指出杯子在世界中的位置。手就会移动到那里，且它后面的身体会调节其自身以便双臂移动，身体适当弯曲，等等。
也有和IK相反的事情，叫做前向运动学,本质上与 IK 工作的次序相反。想像一只手，手附着在手臂上，手臂附着在身体上。现在想像你重重地击中了身体。通常手臂像连迦般抽动，且手臂末梢的手随之振动。 IK 能够移动身体，并让其余的四肢自己以真实的方式移动。基本上它需要动画师设定每种工作的大量信息 -- 像关节所能通过的运动范围，如果一块骨架前面的骨架移动，那么这块骨架将移动多少百分比，等等。
和它现在一样，尽管很好，它是一个很大的处理问题，不用它你可以有不同的动画组合而脱身。值得注意的是，真正的 IK 解决办法需要一个层次骨骼系统而不是一个模型空间系统 -- 否则它们都耗时太多以致无法恰当地计算每个骨架。
LOD几何系统
最后，我们应当快速讨论一下与缩放模型几何复杂度相关的细节级别（LOD）系统(与讨论MIP映射时使用的LOD相对照)。假定如今绝大多数PC游戏支持的处理器速度的巨大范围，以及你可能渲染的任何给定可视场景的动态性质(在屏幕上有一个角色还是12个？)， 你通常需要一些系统来处理这样的情况，比如，当系统接近极限试图同时在屏幕上绘制出12个角色，每个角色有3，000个多边形,并维持现实的幀速率。 LOD 被设计来协助这样的情景中。最基本的情况，它是在任何给定时间动态地改变你在屏幕上绘制的角色的多边形数量的能力。面对现实吧，当一个角色走远，也许只有十个屏幕像素高度，你真的不需要3000个多边形来渲染这个角色 -- 或许300个就够了，而且你很难分辨出差别。
一些 LOD 系统将会需要你建立模型的多个版本，而且他们将会依靠模型离观察者的接近程度来改变屏幕上的LOD级别， 以及多少个多边形正被同时显示。更加复杂的系统实际上将会动态地减少屏幕上的多边形数量，在任何给定时间，任何给定的角色，动态地 -- Messiah和Sacrifice包括了这种风格的技术，尽管在CPU方面并不便宜。你必须确信，与首先简单地渲染整个事物相比，你的 LOD 系统没有花较多的时间计算出要渲染那些多边形（或不渲染）。 任一方式都将会工作，由于如今我们试图要在屏幕上绘制的多边形数量，这是件非常必要的事情。注意， DX9 将会支持硬件执行的自适应几何缩放(tessellation)。 归结起来是，得到一个运动流畅，其表现和移动在视觉上可信，屏幕上看起来逼真的模型。流畅的动画时常是通过手工建造动画和运动捕捉动画的组合得到。有时你仅仅手工建立了一个给定的动画 -- 当你在为一个模型做一些你在现实生活中不能做到的事情的动画时， 你倾向于这样做 -- 举例来说，你确实不能向后弯腰，或像Mortal Kombat 4中的Lui Kang那样在行进的脚踏车上踢腿，通常运动捕捉这时候就出局了! 通常运动捕捉动画 -- 实际上视频捕捉活生生的演员贯穿于你想在屏幕上所看到的动画 -- 是得到逼真的东西的方式。真实感的东西能使一款普通游戏看起来很棒，而且能掩饰许多事情。比如 NFL Blitz，屏幕上的模型大约有 200 个多边形。它们在静止站立时看起来可怕的斑驳，一旦这些模型跑动起来它们就有快速流畅的动画，模型自身的许多丑陋消失了。眼睛容易看见的是 '逼真的' 动画而不是模型自身的结构。 一个不错的模型设计师能够掩饰大多数模型缺陷。
我希望这些带给你对模型和动画问题的洞察力。在第五部份中，我们将会更加深入3D世界的建造，讨论一些物理，运动和效果系统的东西。 第5部分: 物理，运动，效果
世界建造
常常在建立一个含有任何3D成分的游戏时，你最终要试图建立一个将会在里面产生游戏动作的3D环境。 不知怎么的游戏开发者提供了一个建立这种环境的方，它容易修改，有效率，有较低的多边形数量，对于游戏既容易渲染又容易运用物理学。很简单，对吗？当做这个的时候我用左手在做什么？当做这的时候 , 我对我的左手做什么? 是的。不错。 虽然那里有许多3D结构程序，从CAD/CAM程序到3D Studio Max，建造游戏世界是不同于建造内部或外部世界的模型的尴尬。你有三角形数量问题 -- 任何给定的渲染器一次只能渲染这么多的多边形，这对于天才的关卡设计师来说永远都不够。不知这些，你也只能每个关卡存储预定数量的多边形，所以即使你的渲染器能够在视野中处理250，000个多边形，即使你只能在合理数量的空间中存储500，000个多边形，那么取决于你怎么处理它，最后你的关卡价值像两个房间那么小。不好。
任何方法，开发者需要提出一个创作工具 -- 最好足够灵活，允许游戏引擎需要的各种事物 – 比如，在世界中放置对象，在进入游戏以前对关卡的适当预览，以及准确的光照预