《Fundamentals of Computer Graphics》5th（计算机图形学基础/虎书），中文翻译。

第 22 章 Computer Graphics in Games 游戏中的图形学

在所有计算机图形学应用中，计算机和视频游戏可能是最引人注目的。选定给定游戏的图形方法不仅对游戏引擎代码产生深远影响，还会影响艺术资源的创建，有时甚至会影响游戏玩法或核心游戏机制。

虽然游戏图形依赖于前面所有章节的内容，但其中两章尤为相关。游戏需要高效地利用图形硬件，因此理解第 17 章的材料很重要。

在本章中，我将详细介绍适用于游戏开发的图形特定考虑因素，从游戏运行的平台到游戏制作流程。

22.1 平台

在这里，我使用“平台”一词来指代为某个游戏设计的特定硬件、操作系统和 API（应用程序编程接口）的组合。游戏可以在多种平台上运行，从用于基于浏览器的游戏的虚拟机到使用专用硬件和 API 的专业游戏控制台。

过去，游戏常常只针对单个平台进行设计。游戏开发成本的增加使得这种情况变得罕见；跨平台游戏开发现在已成为常态。支持多个平台的开发成本的增量回报远超过潜在的客户基数的翻倍或三倍。

一些平台的定义相当宽松。例如，当为 Windows PC 平台开发游戏时，开发人员必须考虑非常多种可能的硬件配置。游戏甚至被期望在游戏开发时不存在的 PC 配置上运行（并且运行良好）！这仅仅是由于定义 Windows 平台的 API 所提供的抽象化而变得可能。

开发者为了适应图形性能的广泛变化，其中一种方式是通过缩放来调整图形质量以响应系统能力。这可以确保在低端系统上有合理的性能，同时在高性能系统上实现竞争性的视觉效果。这种调整有时会通过分析系统性能自动完成，但更常见的是将控制权留在用户手中，用户最能够权衡质量与速度方面的个人偏好。显示分辨率最容易调整，其次是抗锯齿质量。对于诸如阴影和运动模糊等视觉效果，提供几个质量级别是相当普遍的，包括完全关闭效果的选项。

图形性能的差异可能非常大，以至于一些机器甚至在最低质量设置下也无法以可玩的帧率运行游戏。出于这个原因，PC 游戏开发者会为每个游戏发布最低和推荐的机器规格要求。

作为平台，游戏控制台是严格定义的。例如，在为任天堂 Wii 控制台开发游戏时，开发者知道游戏将在哪些硬件上运行。如果平台的硬件实现发生了改变（通常是为了降低制造成本），控制台制造商必须确保新的实现与旧的实现完全相同，包括时间和性能。这并不是说控制台开发人员的任务容易；控制台 API 倾向于更少的抽象程度，并且更接近底层硬件。这使得控制台开发具有自己的一套困难。在某种意义上，跨平台开发（通常至少包括两种不同的控制台平台，经常也包括 Windows）是最难的，因为跨平台游戏开发者既没有固定平台的保证，也没有单一高级别 API 的便利。

Adobe Flash 等基于浏览器的虚拟机是一个有趣的游戏平台类别。虽然此类虚拟机可以在从个人计算机到手机等各种硬件上运行，但虚拟机提供的高度抽象化结果是一个稳定而统一的开发平台。为这些平台开发的相对轻松和潜在客户群构成的巨大市场使它们越来越受到游戏开发者的青睐。然而，这些平台是由支持的硬件的最低公共分母所定义的，并且虚拟机的性能比任何给定平台上的本机代码都要低。出于这些原因，此类平台最适合具有适度图形要求的游戏。

平台也可以根据其对开发的开放程度进行分类，这是一个业务或法律界限，而不是技术界限。例如，Windows 在开发工具广泛可用的意义上是开放的，并且没有控制访问 Windows 游戏市场的门卫。苹果的 iPhone 在某种程度上是一种更受限制的平台，因为所有应用程序都需要通过认证过程，并且某些类别的应用程序完全被禁止。控制台是最受限制的游戏平台，其中对开发工具的访问受到严格控制。随着在线控制台游戏市场的推出，情况有所改善，这些市场往往更加开放。一个特别有趣的例子是微软的 Xbox LIVE 社区游戏服务，其中开发工具是免费提供的，“门卫”主要通过同行评审来执行。通过该服务分发的游戏必须使用由微软提供的虚拟机平台出于安全原因。

游戏平台决定了游戏体验的许多元素。例如，PC 游戏玩家使用键盘和鼠标，而控制台游戏玩家使用专用游戏控制器。许多控制台游戏支持在同一控制台上多个玩家，可以共享屏幕或为每个玩家提供一个窗口。由于共享键盘和鼠标的困难性，在 PC 上找不到这种类型的游戏。手持游戏系统将具有不同的控制方案，而触摸屏电话等则是另一种不同的控制方式。

虽然游戏平台差异很大，但一些常见趋势可以看出。大多数平台有多个处理核心，分为通用（CPU）和图形专用（GPU）。随着时间的推移，性能提升主要是由于核心数量的增加；单个核心性能的提高是逐渐变得有限。随着 GPU 核心的通用化越来越广泛，GPU 核心和 CPU 核心之间的界限也越来越模糊。存储容量倾向于以比处理能力更慢的速度增长，并且通信带宽（包括核心之间以及每个核心与存储之间的通信带宽）增长的速度仍然相对较慢。

22.2 有限资源

游戏图形的主要挑战之一是需要管理多个有限资源池。每个平台都对硬件资源（如处理时间、存储和内存带宽）施加其自己的限制。在更高的层面上，开发资源也需要被管理；有一个固定大小的程序员、艺术家和游戏设计师团队，他们有限的时间来完成游戏，希望不要过度加班！这在决定采用哪些图形技术时需要考虑到。

22.2.1 处理时间

早期游戏开发者只需要考虑预算单个处理器。目前的游戏平台包含多个 CPU 和 GPU 核心。这些处理器需要仔细同步以避免死锁或过度停顿。

由于单个渲染命令的消耗时间高度可变，图形处理器通过命令缓冲区与系统的其他部分分离。该缓冲区充当队列；命令被放置在一端，GPU 从另一端读取渲染命令。增加此缓冲区的大小可以减少 GPU 饥饿的机会。通常，在将整个帧的渲染命令发送到 GPU 之前，游戏会缓冲整个帧的渲染命令；这保证 GPU 不会饥饿。然而，这种方法需要保留足够的存储空间以容纳两个完整帧的命令（GPU 在一个帧上工作，而 CPU 在另一个帧上放置命令）。它还增加了用户输入和显示之间的延迟，这对于快节奏的游戏可能有问题。

处理预算由帧率确定，即帧缓冲区以新场景渲染更新的频率。在固定平台上（如控制台），用户体验的帧率基本上与游戏开发者看到的帧率相同，因此可以强制实施相当严格的帧率限制。大多数游戏目标帧率为 30 帧每秒（fps）；在响应延迟特别重要的游戏中，目标通常是 60 fps。在高度可变的平台上（如 PC），帧率预算（必然）定义得更松散。

所需的帧率给图形程序员提供了每帧固定的预算。在 30 fps 目标的情况下，CPU 核心有 33 毫秒的时间来收集输入、处理游戏逻辑、执行任何物理模拟、遍历场景描述并将渲染命令发送到图形硬件。同时，必须处理其他任务，例如音频和网络处理，它们具有自己所需的响应时间。这时，GPU 通常正在执行提交的上一帧的图形命令。

在大多数情况下，CPU 核心是同质资源；所有核心都是相同的，并且其中任何一个对于给定的工作负载都同样合适（也有一些例外，例如 Sony PLAYSTATION 3 控制台中使用的 Cell 处理器）。

相比之下，GPU 包含各种不同的资源，每个资源都专门用于某个任务集。其中一些资源由固定功能硬件组成（用于三角形栅格化、Alpha 混合和纹理采样），而一些是可编程核心。在旧的 GPU 上，可编程核心进一步区分为顶点和像素处理核心；新的 GPU 设计具有统一着色器核心，可以执行任何可编程着色器类型。

这样的异构资源单独预算。通常，在任何时候，只有一种资源类型将是瓶颈，而其他资源将具有多余的容量。一方面，这很好，因为可以利用这种容量来提高视觉质量而不降低性能。另一方面，它使改善性能变得更难，因为减少任何非瓶颈资源的使用将没有效果。甚至减少瓶颈资源的使用量也可能仅略微提高性能，这取决于“下一个瓶颈”的利用程度。

22.2.2 存储

游戏平台像任何现代计算系统一样，拥有多级存储层次结构，顶部是较小、较快的内存类型，底部是更大、更慢的存储。尽管这种安排是出于工程必要性，但它确实为开发人员增加了复杂性。大多数平台都包括光盘存储，它非常慢，主要用于传递。在诸如 Windows 之类的平台上，需要执行漫长的安装过程，将所有数据从光盘移动到硬盘驱动器上，后者速度显着提高。光盘不会再次使用（除了作为防盗版措施）。在控制台平台上，这种情况较少见，尽管它有时会发生，当硬盘驱动器保证存在时，例如 Sony PLAYSTATION 3 控制台。更经常地，硬盘驱动器（如果存在）仅用作光盘的缓存。

记忆体层次结构的下一步是 RAM，在许多平台上，RAM 分为通用系统 RAM 和 VRAM（视频 RAM），它具有与图形硬件相连的高速接口。游戏关卡可能太大而无法放入 RAM 中，在这种情况下，游戏开发人员需要根据需要管理将数据移进和移出 RAM。在诸如 Windows 之类的平台上，通常使用虚拟内存来实现这一点。在控制台平台上，通常采用自定义数据流和缓存系统。

最后，CPU 和 GPU 都拥有各种芯片内存和缓存。这些非常小而快速，通常由图形 API 管理。

图形资源占用大量内存，因此它们是游戏开发中存储预算的主要关注点。纹理通常是最大的内存消耗者，其次是几何（顶点数据），最后是其他类型的图形数据，例如动画。并非所有内存都可以用于图形——音频也需要相当数量的内存，并且游戏逻辑可能使用大型数据结构。与处理时间的情况类似，在 Windows 上，预算往往要松散一些，因为用户系统上存在的确切内存量是未知的，并且虚拟内存可以犯多种错误。相比之下，控制台平台上的内存预算非常严格——通常，首席程序员会在电子表格上跟踪内存，需要更多内存的程序员需要向其他人借、抢或偷取它。

存储层次结构的各个级别不仅在大小上有所不同，而且在访问速度上也有所不同。这有两个单独的维度：延迟和带宽。

延迟是存储访问请求和其最终实现之间经过的时间。这个时间从几个时钟周期（对于芯片缓存）到数百万个时钟周期（对于位于光盘上的数据）不等。延迟通常是读取访问的问题（尽管写入延迟也可能是一个问题，如果结果需要很快从内存中读回）。在某些情况下，读取请求是阻塞的，这意味着提交读取请求的处理器核心在请求得到满足之前不能做任何其他事情。在其他情况下，读取是非阻塞的；处理核心可以提交读取请求，执行其他类型的处理，然后在读取到达后使用读取结果。GPU 的纹理访问就是非阻塞读取的一个例子；GPU 设计的一个重要方面是找到方法来“隐藏”纹理读取延迟，通过在纹理读取被满足时执行无关的计算。

为了使这种延迟隐藏工作，必须相对于纹理访问有足够的计算量。这是着色器编写者要考虑的一个重要因素；随着内存无法跟上处理能力的增加，计算与纹理访问的最佳比例不断变化（倾向于更多的计算）。

带宽指存储和从存储中传输的最大速率。通常以每秒几 GB 为单位衡量。

22.2.3 开发资源

除了硬件资源，如处理能力和存储空间，游戏图形程序员还必须应对另一种有限资源——团队成员的时间！在选择图形技术时，必须考虑实现每种技术所需的工程资源，以及计算输入数据所需的任何工具（在许多情况下，工具可能需要的时间远远超过实现技术本身所需的时间）。也许最重要的是，必须考虑到对艺术家生产力的影响。大多数图形技术使用由游戏艺术家创建的资产，他们在现代游戏团队中占据绝大部分。图形程序员必须促进艺术家的生产力和创造力，这将最终决定游戏的视觉质量。

22.3 优化技术

游戏图形程序员的主要挑战是明智地利用这些有限资源。为此，通常采用各种优化技术。

在许多游戏中，像素着色器处理是一个主要瓶颈。大多数 GPU 都包含分层深度剔除硬件，可以避免在被遮挡表面上执行像素着色器。为了很好地利用这个硬件，不透明对象可以按从后往前的顺序渲染。或者，可以通过执行深度预先传递（即在正常渲染场景之前将所有不透明对象渲染到深度缓冲区中（没有任何颜色输出或像素着色器）来实现最佳深度剔除使用）。这确实会产生一些开销（由于需要两次渲染每个对象而导致），但在许多情况下，性能提升是值得的。

渲染物体的最快方法是根本不渲染它；因此，任何一种早期判定物体是否被遮挡的方法都可能是有用的。这不仅节省像素处理，还节省了顶点处理甚至提交对象到图形 API 所需的 CPU 时间。视锥体剔除（见第 8.4.1 节）是普遍采用的方法，但在许多游戏中它是不够的。通常使用高级遮挡剔除算法，利用数据结构如 PVS（潜在可见集）或 BSP（二叉空间分区）树来快速缩小可能可见对象的池。

即使一个对象可见，它也可能距离太远，大部分细节可以被移除而没有明显的影响。LOD（细节级别）算法根据距离（或其他因素，例如屏幕覆盖范围或重要性）渲染对象的不同表示。这可以节省大量的处理，特别是顶点处理。Figure 22.1 中可以看到一些例子。

图 22.1。两个游戏对象在不同细节级别上的两个示例。小插图显示了可能使用简化模型的相对大小。上面一排照片由 Crytek 提供； 下面一排照片由 Valve Corp 提供。

在许多情况下，可以在游戏开始之前进行处理。这种预处理的结果可以存储，并在每个帧中使用，从而加快游戏速度。这最常用于光照，其中全局照明算法用于计算场景中的照明，并将其存储在光照贴图和其他数据结构中以供以后使用。

22.4 游戏类型

由于游戏要求各不相同，因此选择图形技术是由正在开发的确切游戏类型驱动的。

处理时间的分配强烈依赖于帧速率。目前，大多数主机游戏往往以 30 帧每秒为目标，因为这可以实现更高的图形质量。但是，某些具有快速游戏玩法的游戏需要非常低的延迟，这些游戏通常以 60 帧每秒渲染。这包括音乐游戏（如吉他英雄）和第一人称射击游戏（如使命召唤）。

帧速率确定了呈现场景的可用时间。场景本身的组成在游戏之间也有很大的差异。大多数游戏都分为背景几何（风景，主要静态）和前景几何（角色和动态对象）。这些由渲染引擎处理方式不同。例如，背景几何通常会有包含预计算光照的光照贴图，而对于前景对象来说则是不可行的。预计算的光照通常通过某种体积表示方式应用到前景对象上，可以考虑每个对象随时间变化的位置。

一些游戏具有相对封闭的环境，摄像机基本保持不动。最纯粹的例子是《街头霸王》系列等格斗游戏，但这在某种程度上也适用于《鬼泣》和《战神》等游戏。这些游戏的摄像机不受玩家直接控制，游戏玩法往往从一个封闭的环境移动到另一个，每个环境都会花费大量的游戏时间。这使得游戏开发者可以在每个房间或封闭环境上投入大量资源（处理、存储和艺术家时间），从而实现非常高水平的图形保真度。

其他游戏具有非常大的世界，玩家可以自由地移动。这对于“沙盒游戏”如《侠盗猎车手》系列和在线角色扮演游戏如《魔兽世界》来说是最为真实的。这样的游戏对图形开发者提出了很大的挑战，因为当玩家每帧都能看到广阔的世界时，资源分配变得非常困难。进一步复杂化的是，玩家可以自由地去到过去遥远的世界的一些部分，并从近处观察它。这些游戏通常有变化的白天和黑夜，这使得光照的预计算变得非常困难，如果不是不可能的话。

大多数游戏，例如第一人称射击游戏，介于两个极端之间。玩家每帧可以看到相当数量的风景，但是在游戏世界中移动受到某些限制。许多游戏的每个游戏关卡也有固定的时间，以方便进行光照的预计算。

渲染的前景对象数量也因游戏类型而异。例如《命令与征服》系列等实时战略游戏经常在屏幕上显示许多几十甚至数百个单位。其他类型的游戏的可见角色数量较少，而格斗游戏则正好相反，只有两个角色可见，每个角色都以极高的细节呈现。必须区分任何时间可见的角色数量（影响处理时间的预算）和可能在短时间内出现的唯一角色数量（影响存储预算）。

游戏类型或流派也决定了玩家对图形的期望。例如，第一人称射击游戏历来具有非常高的图形保真度，这种期望驱动了在该流派中开发新游戏时的图形设计；见 Figure 22.2。另一方面，谜题游戏通常具有相对简单的图形，因此大多数游戏开发者不会投入大量编程或艺术资源来开发逼真的图形。

图 22.2。《孤岛危机》展示了第一人称射击游戏期望的逼真和详细图形。图像提供者：Crytek。

尽管大多数游戏都力求实现逼真的外观，但有些游戏确实尝试更具风格化的渲染。其中一个有趣的例子是《大神》，可以在图 22.3 中看到。

图 22.3。《大神》中高度风格化、非逼真渲染的例子。图像提供者：Capcom Entertainment, Inc。

开发资源的管理也因游戏类型而异。大多数游戏的闭合开发周期为一到两年，在游戏发布后结束。最近流行的下载内容（DLC）在游戏发布后可以购买，因此需要保留一些开发资源。持续世界在线游戏具有永无止境的开发过程，其中不断生成新内容，至少在游戏经济上是可行的情况下（可能是几十年的时间）。

巧妙利用特定游戏的特定要求和限制是熟练的游戏图形程序员的标志。一个很好的例子是游戏《小小的大星球》，它拥有一个“二又半维度”的游戏世界，包括少量的二维层和一个非交互式背景。这个游戏的图形质量非常好，使用了专门针对这种环境的不寻常渲染技术来驱动；见图 22.4。

图 22.4。《小小的大星球》开发者精心选择适合游戏限制的技术，并以不寻常的方式将它们组合起来，以达到惊人的效果。 《小小的大星球》（LittleBigPlanet）©2007 Sony Computer Entertainment Europe。由 Media Molecule 开发。《小小的大星球》是 Sony Computer Entertainment Europe 的商标。

22.5 游戏的制作过程

游戏的制作过程始于基本的游戏设计或概念。在某些情况下（如续集），基本的游戏玩法和视觉设计是清晰的，只作出渐进式的改变。对于新游戏类型，需要进行广泛的原型制作以确定游戏玩法和设计。大多数情况处于中间阶段，在这个阶段有一些新的游戏玩法元素，而视觉设计有些开放。在此步骤之后，可能会有一个绿灯阶段，展示一些早期的演示或概念，以获得游戏发行商的批准（和资金！）。

接下来通常是预制作阶段。当其他团队正在完成上一个游戏时，一个小核心团队致力于对游戏引擎和生产工具链进行任何必要的更改，并解决任何新的游戏玩法元素的粗略细节。这个核心团队在严格的最后期限下工作。在现有游戏发布之后，当整个团队从应得的假期回来时，整个工具链和引擎必须为他们准备好。如果核心团队错过了这个最后期限，可能会有几十名开发人员被闲置 - 这是一个非常昂贵的提案！

全面制作是下一步，全团队创建艺术资源，设计关卡，调整游戏玩法，并对游戏引擎进行进一步的更改。在理想情况下，在此过程中完成的所有内容都将用于最终游戏中，但实际上，游戏开发具有迭代性质，会导致某些工作被扔掉并重新完成。通过仔细的规划和原型制作，目标是将其最小化。

当游戏功能完成时，最终阶段开始。Alpha 版本通常指的是开始大量内部测试的版本，Beta 版本指的是开始大量外部测试的版本，Gold 版本则是提交给主机制造商的最终版本，但不同的公司对这些术语有略微不同的定义。无论如何，测试或质量保证（QA）是这个阶段的重要组成部分，它涉及游戏开发工作室、出版商、主机制造商以及可能的外部 QA 承包商的测试人员。这些各种各样的测试结果会产生错误报告，这些报告被提交回游戏开发人员，并在下一个发布版本中进行处理。

游戏发布后，大多数开发人员会休息一段时间，但是一小部分团队可能必须留下来处理补丁或可下载内容。与此同时，一个小核心团队一直在为下一个游戏的预制作工作。

艺术资源创建是游戏制作的一个方面，特别与图形开发相关，因此我将详细介绍它。

22.5.1 资源创建

尽管不同游戏的艺术资源创建过程有所不同，但我在这里提供的概述相当具有代表性。过去，单个艺术家会从头到尾创建整个资源，但现在这个过程更加专业化，涉及到具有不同技能的人员在各个时间点上处理每个资源。其中一些阶段具有明确的依赖关系（例如，角色必须进行绑定动画，而模型必须先被制作才能进行绑定）。大多数游戏开发商都有明确定义的批准流程，在艺术总监或主管艺术家在将资产发送到下一个阶段之前签署每个阶段。理想情况下，每个资产应该只通过每个阶段一次，但实际上可能会进行更改，需要重新提交。

初始建模

通常，艺术资源创建过程从建模对象几何形状开始。这一步骤是在通用建模软件（如 Maya、MAX 或 Softimage）中完成的。建模出的几何形状将直接传递给游戏引擎，因此需要尽量减少顶点数量，同时保持良好的轮廓线。角色网格还必须构建得易于动画处理。

在这个阶段，通常会创建一个二维表面参数化的纹理。这种参数化需要高度连续，因为不连续会导致顶点重复并可能导致滤波伪影。图 22.5 展示了带有相关纹理参数化的网格的例子。

图 22.5。在 Maya 中建模的网格，带有相关纹理参数化。图像由 Keith Bruns 提供。

纹理贴图

过去，贴图是在 Photoshop 等软件中简单绘制颜色纹理的过程。现在，专门的细节建模软件（如 ZBrush 或 Mudbox）通常用于雕刻细微表面细节。图 22.6 和 22.7 展示了这个过程的一个例子。

图 22.6。图 22.5 中的网格已经被带入 ZBrush 进行细节建模。图像由 Keith Bruns 提供。

图 22.7。在 ZBrush 中为图 22.6 中的网格添加了细节。图像由 Keith Bruns 提供。

如果这些额外的细节要用实际几何形状表示，需要数百万个三角形。相反，这些细节通常会“烘焙”到法线贴图中，然后应用到原始的、粗略的网格上，如图 22.8 和 22.9 所示。

图 22.8。从图 22.6 中派生出的法线贴图渲染出来的图 22.6 中的网格的可视化效果（在 ZBrush 中）。底部显示的是 ZBrush 的“Zmapper”工具的界面，该工具被用于派生法线贴图。图像由 Keith Bruns 提供。

图 22.9。图 22.8 中使用的法线贴图。在这张图片中，纹理的红色、绿色和蓝色通道包含表面法线的 X、Y 和 Z 坐标。图像由 Keith Bruns 提供。

除了法线贴图之外，还创建了包含表面属性（如漫反射颜色、高光颜色和平滑度（高光功率））的多个纹理。它们要么直接在细节建模应用程序中绘制在表面上，要么在二维应用程序（如 Photoshop）中进行绘制。所有这些纹理图都使用了初始建模阶段定义的表面参数化。当在二维绘画应用程序中绘制纹理时，艺术家必须频繁地在绘画应用程序和能够显示带有纹理应用的三维渲染的其他应用程序之间切换。这个迭代过程在图 22.10、22.11、22.12 和 22.13 中说明。

图 22.10。从图 22.8 中得到的网格的漫反射颜色纹理的早期版本，在 Photoshop 中显示。图像由 Keith Bruns 提供。

图 22.11。具有法线贴图和早期漫反射颜色贴图（来自图 22.10）的网格的渲染效果（在 ZBrush 中）。图像由 Keith Bruns 提供。

图 22.12。从图 22.10 中得到的颜色纹理的最终版本。图像由 Keith Bruns 提供。

图 22.13。具有法线贴图和最终颜色纹理（来自图 22.12）的网格的渲染效果。图像由 Keith Bruns 提供。

着色

着色器通常在用于初始建模的同一应用程序中应用。在这个过程中，一个着色器（从为该游戏定义的着色器集合中选择）被应用到网格上。细节建模阶段产生的各种纹理被作为输入应用到该着色器上，使用在初始建模期间定义的表面参数化。各种其他着色器输入是通过视觉实验（“调整”）设置的；参见图 22.14。

图 22.14。在 Maya 中的着色器配置。右侧界面用于选择着色器、将纹理分配给着色器输入，并设置非纹理着色器输入的值（如“高光颜色”和“高光功率”滑块）。左侧的渲染效果会在修改这些属性时动态更新，提供即时的视觉反馈。图像由 Keith Bruns 提供。

照明

对于背景场景，照明艺术家通常会在建模、纹理和着色完成后开始工作。光源被放置并在预处理步骤中计算其影响。该过程的结果以灯光贴图的形式存储，供渲染引擎稍后使用。

动画

角色网格需要经历几个与动画相关的附加步骤。用于动画游戏角色的主要方法是蒙皮。这需要一个骨骼系统，它由一系列连接到角色的变换节点层次结构组成，这个过程称为绑定。每个变换节点的影响区域被涂在网格的一部分顶点上。最后，动画师创建动画，移动、旋转和缩放这些变换节点，把网格“拖”在它们后面。

一个典型的游戏角色将有很多个动画，对应不同的运动模式（行走、奔跑、转弯）以及攻击等不同的动作。在主要角色的情况下，动画数量可能达到数百个。还需要定义不同动画之间的过渡。

对于面部动画，有时会使用另一种技术称为变形目标。在这种技术中，网格顶点被直接操纵以形成网格变形。不同的变形网格副本被存储（例如，用于表示不同的面部表情），并在运行时由游戏引擎进行组合。图 22.15 展示了变形目标的创建过程。

图 22.15。Maya 中的变形目标界面。底部一行显示了四个不同的变形目标，而顶部的模型显示了将多个变形目标组合在一起的效果。左上角的界面用于控制应用每个变形目标的程度。图像由 Keith Bruns 提供。

注释

关于实时渲染和游戏编程的信息非常丰富，可以在书籍和在线资源中找到。以下是一些我个人熟悉并可推荐的资源。

《Game Developer Magazine》是游戏开发信息的好来源，年度游戏开发者大会（GDC）和微软的 Gamefest 会议的演讲幻灯片也是同样好的资源。GPU Gems 和 ShaderX 书系列也包含了很好的信息，前者全都可以在线获取，而后者的前两本也可以在线获取。

Eric Lengyel 的《Mathematics for 3D Game Programming & Computer Graphics》现在已经出到第二版，是关于图形和游戏中使用的各种数学类型的良好参考。与图形密切相关的游戏编程特定领域是碰撞检测，Christer Ericson 的《Real-Time Collision Detection》是该领域的权威资源。

自 1999 年首次出版以来，Eric Haines 和 Tomas Akenine-Möller 的《Real-Time Rendering》一直致力于以全面的方式覆盖这个快速发展的领域。作为这本书的长期粉丝，我很高兴有机会成为第三版的合著者，该版于 2008 年中期出版。

仅阅读是不够的——一定要经常玩各种游戏，以了解不同游戏类型的要求以及当前技术水平。

练习

1. 比较两个不同游戏的视觉效果。你能从中推断出这两个游戏的图形需求之间的差异吗？分析这对渲染时间、存储预算等方面有什么影响。