第22章：游戏中的计算机图形学

学习目标

1. 理解不同游戏平台（PC、主机、移动、Web）对图形系统的核心约束与设计取舍，掌握各平台GPU架构差异。
2. 掌握游戏图形中的三大有限资源——处理时间（帧预算按毫秒分配）、存储空间（VRAM/统一内存的分级管理）和带宽（量化瓶颈分析）——及其预算管理策略。
3. 学会常见的实时渲染优化技术：视锥剔除的数学模型、硬件遮挡查询流程、LOD距离阈值公式、纹理压缩格式选型、以及着色器级别的微优化（MAD融合、分支扁平化、纹理采样策略）。
4. 能根据游戏类型（FPS、RPG、RTS、赛车等）分析其对图形技术的差异化需求：延迟要求、流式加载、实例化渲染和反射技术。
5. 了解游戏制作的完整流程（概念→预生产→生产→测试→发布→运维）中，每个阶段的图形技术决策点和管线设计考量。

在过去，游戏通常只为一个平台设计。跨平台游戏开发（Multiplatform Game Development）随着开发成本的上升已成为常态。支持多个平台带来的开发成本增量，远不及潜在用户基数翻倍甚至三倍所带来的收益。

有些平台的定义相当松散。例如，为 Windows PC 平台开发游戏时，开发者必须考虑极其多样化的硬件配置。游戏甚至被期望能在开发时还不存在的 PC 配置上良好运行——这之所以可能，完全归功于 Windows 平台 API 所提供的抽象层。

开发者应对图形性能差异的一种方法是缩放（Scaling）——根据系统能力调整图形质量。这可以确保低端系统上的可玩性，同时在高性能系统上实现有竞争力的视觉效果。这种调整有时通过自动性能分析完成，但更常见的是将控制权交给用户，让他们根据自己对质量与速度的偏好做出判断。显示分辨率最容易调整，其次是抗锯齿质量。此外，为阴影、运动模糊等视觉效果提供多个质量档位（包括完全关闭）也相当普遍。

22.1 平台（PC / 主机 / 移动 / Web）

图形性能差异可能大到某些机器即使在最低画质设置下也无法以可玩帧率运行游戏；因此，PC 游戏开发者会为每款游戏公布最低和推荐配置。

与 PC 相反，游戏主机（Game Console）是严格定义的平台。当为任天堂 Wii 等主机开发游戏时，开发者确切地知道游戏将在什么硬件上运行。如果主机的硬件实现发生变化（通常是为了降低制造成本），主机制造商必须确保新实现与旧实现行为完全一致，包括时序和性能。这并不意味着主机开发者的工作轻松——主机 API 往往更接近底层硬件，抽象程度较低，这带来了独特的困难。从某种意义上说，跨平台开发（通常至少包含两种不同的主机平台，往往还有 Windows）是其中最难的，因为跨平台开发者既没有固定平台的保障，也没有单一高级 API 的便利。

生活类比：主机平台好比赛车——每辆赛车规格完全一致，工程师可以针对固定参数做极端优化。PC平台则像越野拉力赛——车子可能从家庭轿车到改装越野车不等，必须设计自适应系统来应对千差万别的路况。

22.1.1 GPU 架构与平台能力对比

现代游戏平台可粗略分为四类，每类GPU架构有着根本性的设计差异。理解这些差异是跨平台图形开发的基础。

Tile-Based Deferred Rendering（TBDR）— 移动GPU的核心秘密

移动GPU（如ARM Mali、Qualcomm Adreno、Apple GPU、Imagination PowerVR）广泛采用分块延迟渲染（Tile-Based Deferred Rendering, TBDR）架构。与PC GPU的"立即模式"（Immediate Mode）将整个帧缓冲视为一个整体不同，TBDR将屏幕划分为多个小方块（tile，通常16×16或32×32像素），每个tile独立完成全部渲染管线段后再输出到帧缓冲：

1. 顶点处理阶段：所有几何体的顶点着色器先执行，生成每个三角形对应的tile列表（"binning"）。
2. 分块阶段：硬件确定每个三角形覆盖哪些tile，将三角形分配到对应的tile列表中。
3. 逐Tile渲染：对每个tile，在其对应的极小的片上SRAM中完成光栅化→深度测试→像素着色→混合，全程不触及外部DRAM。
4. 写出阶段：tile渲染完成后，将最终颜色值从片上内存一次性写入外部帧缓冲。

22.1.2 平台专用图形 API

选择正确的图形API是跨平台开发的核心技术决策。下表总结了当前主流API的适用场景和关键特性：

22.1.3 主机统一内存架构 —— 双刃剑

现代游戏主机（PlayStation 5、Xbox Series X|S、Nintendo Switch）全部采用统一内存架构（Unified Memory Architecture, UMA）：CPU和GPU共享同一块物理内存。

这种设计的优势在于：

• 零拷贝数据传输：CPU生成的顶点数据、纹理更新不需要通过PCIe总线复制到GPU显存——GPU可以直接读取CPU写入的内存地址。
• 降低延迟：CPU-GPU数据共享延迟从PC上的数十微秒降至亚微秒级。
• 灵活分配：不需要预先在系统RAM和VRAM之间划清界限，可以在游戏运行时根据需求动态调整CPU/GPU内存分区。

但统一内存也带来特有的挑战：

• 带宽竞争：CPU和GPU同时访问内存时，带宽被两者共享。如果GPU正在全速扫描帧缓冲而CPU正在遍历场景图，两者的内存请求会在总线仲裁器处排队。
• 缓存一致性开销：当CPU写入数据后GPU需要读取时（反之亦然），缓存必须刷新，否则GPU可能读到过时数据。这种"缓存刷新风暴"是主机优化的常见难点。
• 内存容量固定：8GB或16GB统一内存在2020年代中期已显捉襟见肘——这包括游戏逻辑、音频、物理、图形和操作系统保留空间。

基于浏览器的虚拟机平台（Browser-based Virtual Machine），如 Adobe Flash，是一类有趣的游戏平台。尽管这类虚拟机运行在从个人电脑到手机的广泛硬件上，虚拟机提供的高度抽象带来了稳定且统一的开发平台。相对容易的开发门槛和庞大的潜在用户群，使它们对游戏开发者越来越有吸引力。然而，这些平台受限于所支持硬件的最低共同标准，且虚拟机在任何给定平台上的性能都低于原生代码。因此，这类平台最适合图形需求适中的游戏。

平台还可以按开发开放程度来划分，这是一个商业或法律上的区分，而非技术上的。例如，Windows 在开发工具广泛可用且没有看门人控制游戏市场的意义上是"开放"的。苹果 iPhone 是一个相对受限的平台——所有应用需要通过认证流程，某些类别的应用被直接禁止。游戏主机是最受限制的游戏平台，开发工具的获取受到严格控制。不过，随着在线主机游戏市场的引入（通常更开放），这一情况有所松动。一个特别有趣的例子是微软的 Xbox LIVE 社区游戏服务，开发工具可免费获取，而"看门"功能主要由同行评审完成。通过该服务分发的游戏出于安全原因必须使用微软提供的虚拟机平台。

游戏平台决定了游戏体验的许多元素。例如，PC 游戏玩家使用键盘和鼠标，而主机游戏玩家使用专用游戏手柄。许多主机游戏支持同一台主机上的多人游戏，要么共享屏幕，要么为每个玩家提供窗口。由于共享键盘和鼠标的困难，这种玩法在 PC 上不存在。手持游戏系统与触摸屏手机又各有不同的操控方案。

尽管游戏平台差异很大，一些共同趋势仍然可以识别。大多数平台拥有多个处理核心，分为通用核心（CPU）和图形专用核心（GPU）。性能的增长主要来自核心数量的增加，单核心性能的提升相对有限。随着 GPU 核心通用性的增强，GPU 与 CPU 核心之间的界限越来越模糊。存储容量的增速通常低于处理能力，而通信带宽（核心之间以及核心与存储之间）的增长速度更慢。

22.2 有限资源（内存 / 带宽 / 功耗）

游戏图形的主要挑战之一是管理多个有限资源池。每个平台对处理时间、存储空间和内存带宽等硬件资源施加各自的约束。在更高层面，开发资源（Development Resources）也需要管理——有一个固定规模的程序员、美术师和游戏设计师团队，在有限的期限内完成游戏（希望不用加太多班！）。在决定采用哪些图形技术时，必须考虑这一点。

22.2.0 游戏图形的四大约束维度

在深入每个资源类型之前，先从鸟瞰视角理解游戏图形面临的四大约束：

22.2.1 处理时间

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

帧预算的毫秒级分解

游戏图形程序员的日常工作中，最核心的数字就是帧预算（Frame Budget）。不同的帧率目标对应的每帧可用时间天差地别：

一个典型的 60fps 帧内，CPU端的16.67ms预算需要完成以下全部任务：

GPU端在CPU准备下一帧的命令时并行处理当前帧的渲染。GPU的典型管道分解（60fps下约13ms可用）：

由于单条渲染命令消耗的时间变化很大，图形处理器通过命令缓冲区（Command Buffer）与系统其他部分解耦。该缓冲区充当队列：命令从一端存入，GPU 从另一端读取渲染命令。增大此缓冲区可降低 GPU 饥饿（starvation）的概率。游戏通常会缓冲整整一帧的渲染命令再发送给 GPU，这保证了 GPU 不会饥饿。然而，这种方法需要为两帧命令保留足够的存储空间（GPU 处理一帧，CPU 将命令存入另一帧），同时增加了用户输入到显示之间的延迟，这对快节奏游戏而言可能是个问题。

生活类比：命令缓冲区就像餐厅厨房的订单队列——服务员不断往队列里加新订单（CPU），厨师从队列另一端取单做菜（GPU）。如果队列太短，厨师可能空等；如果队列太长，顾客等待时间增加（输入延迟）。好的设计需要在吞吐量和响应速度之间找到平衡。

处理预算由帧率（Frame Rate）决定，即帧缓冲区用场景新渲染结果刷新的频率。在固定平台（如主机）上，用户体验到的帧率与开发者看到的基本一致，因此可以实施相当严格的帧率限制。大多数游戏目标为每秒 30 帧（30 fps）；在响应延迟特别重要的游戏中，目标通常是 60 fps。在高度可变的平台（如 PC）上，帧率预算只能定义得比较宽松。

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

在大多数情况下，CPU 核心是同构资源——所有核心相同，任何一个都同样适合给定的工作负载（存在一些例外，如索尼 PLAYSTATION 3 使用的 Cell 处理器）。相比之下，GPU 包含异构的资源混合体，各自专用于特定任务集。其中一些资源是固定功能硬件（Fixed-function Hardware），用于三角形光栅化、Alpha 混合和纹理采样；另一些是可编程核心。在较老的 GPU 上，可编程核心进一步分化为顶点处理和像素处理核心；较新的 GPU 设计具有统一着色器核心（Unified Shader Cores），可以执行任何类型的可编程着色器。

这些异构资源分别做预算。通常在任何时刻，只有一种资源类型是瓶颈，其他资源则有过剩产能。好的一面是，这些过剩产能可用来提升画质而不降低性能。不好的一面是，这使性能优化更加困难——减少任何非瓶颈资源的使用量都不会有效果。甚至，减少瓶颈资源的使用量也可能只是轻微改善性能，取决于"下一个瓶颈"的利用率程度。

22.2.2 存储

游戏平台和任何现代计算系统一样，拥有多级存储层次（Storage Hierarchy），顶部是更小更快的内存类型，底部是更大更慢的存储。这种安排出于工程必然性，尽管确实使开发者的生活复杂化。大多数平台包含光盘存储（Optical Disc Storage），速度极慢，主要用于交付。在 Windows 等平台上，首次执行一次漫长的安装过程，将所有数据从光盘移动到明显更快的硬盘。此后光盘再也不会被使用（除了作为反盗版措施）。在主机平台上，这种做法不太常见，尽管当硬盘确定存在时（如索尼 PLAYSTATION 3）有时也会使用。更常见的是，硬盘（如果存在）仅用作光盘的缓存。

生活类比：多级存储就像你书桌上的工作区——手边是常用的笔和便签（L1缓存），抽屉里是本周要用的文件（RAM），书架上是不常用的参考书（硬盘），地下室箱子里是陈年旧物（光盘）。东西放得越远，取用就越慢。

向上一层是RAM（随机存取存储器），在许多平台上分为通用系统 RAM 和VRAM（显存，受益于与图形硬件的高速接口）。一个游戏关卡可能大到无法全部装入 RAM，此时游戏开发者需要按需管理数据进出 RAM。在 Windows 等平台上，常使用虚拟内存来实现。在主机平台上，通常采用定制的数据流式传输和缓存系统。

最后，CPU 和 GPU 各自拥有各种类的片上内存（On-chip Memory）和缓存。这些极其微小且极快，通常由图形 API 管理。

图形内存的精细分类与预算

不同平台的可用图形内存差异悬殊。下面给出各平台典型游戏的图形内存占用分解：

带宽瓶颈的量化分析

带宽不足是游戏图形中最隐蔽的性能杀手——它不像ALU（算术逻辑单元）瓶颈那样出现在profiler的最显眼位置，而是表现为GPU整体利用率低下（"GPU在等待数据"）。

GPU带宽的主要消费者：

单帧就需要约1.7GB的显存传输——在60fps下约等于102 GB/s的持续带宽需求。这在高端PC GPU（500+ GB/s）上尚有大量余量，但在移动端GPU（30-80 GB/s）上就是严重的带宽瓶颈。这就是为什么移动端游戏大量使用Tile-based缓存的片上内存（见§22.1.1）和低分辨率渲染目标。

22.2.2b 功耗与热管理 —— 移动和笔记本的隐形杀手

在移动端和笔记本平台上，功耗与热管理是比内存带宽更紧迫的限制。移动设备的SoC通常有严格的热设计功耗（Thermal Design Power, TDP）上限（3-8W），一旦芯片温度超过阈值（通常是85-95°C），系统会启动热降频（Thermal Throttling）——强制降低GPU/CPU时钟频率以散热。

热降频的后果是灾难性的性能断崖：

• GPU频率从峰值800MHz骤降至300MHz时，帧率可能从60fps跌至20fps
• 降频一旦触发，通常持续数十秒直到温度回落
• 用户体感是"玩了几分钟后突然变卡"——这是移动游戏最糟糕的体验

移动游戏图形程序员的应对策略包括：

• 动态分辨率缩放：根据GPU负载实时调整渲染分辨率（如1080p→720p），降低像素处理压力从而降低功耗。
• 帧率封顶：将帧率锁定在30fps而非60fps，GPU工作负载直接减半。
• 避免"热点效应"：连续的GPU瓶颈可能导致芯片局部温度远高于平均温度——在CPU-GPU任务之间交替可以给芯片不同区域轮流"降温"。
• 使用固定功能硬件：尽可能利用硬件纹理采样器、硬件混合单元而非在着色器中软件实现——固定功能硬件功耗远低于可编程着色器。

22.2.3 开发资源

除了处理能力和存储空间等硬件资源外，游戏图形程序员还必须应对另一种有限资源——团队同事的时间！在选择图形技术时，必须考虑实现每种技术所需的工程资源，以及计算输入数据所需的任何工具（在很多情况下，制作工具所需的时间可能远超实现技术本身）。

也许最重要的是，必须考虑对美术师生产力（Artist Productivity）的影响。大多数图形技术使用游戏美术师创建的资产，而美术师是大多数现代游戏团队中规模最大的部分。图形程序员必须滋养美术师的生产力和创造力，这最终将决定游戏的视觉质量。

22.3 优化技术（剔除 / LOD / 遮挡查询 / 纹理压缩 / 着色器优化）

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

22.3.0 优化漏斗：从粗粒度到细粒度

游戏图形优化遵循一个漏斗模型（Optimization Funnel），每一级过滤掉大量无效工作：

1. 场景级剔除（最粗粒度）：视锥剔除 → 遮挡剔除 → PVS/BSP空间划分。这一步决定"哪些物体根本不值得画"。
2. 几何级优化（中等粒度）：LOD层次细节 → 几何着色器简化。这一步决定"可见的物体该用多少三角形"。
3. 像素级优化（最细粒度）：Early-Z/Hi-Z剔除 → 纹理压缩 → 着色器优化。这一步决定"每个像素算多少东西"。

在许多游戏中，像素着色器（Pixel Shader）处理是首要瓶颈。大多数 GPU 包含层次深度剔除（Hierarchical Depth-Culling）硬件，可以避免对被遮挡表面执行像素着色器。为了善用此硬件，不透明物体可以按照从后到前的顺序渲染。或者，可以通过执行深度预通道（Depth Prepass）来实现最优的深度剔除利用——即先将所有不透明物体渲染到深度缓冲区（不输出颜色、不使用像素着色器），然后再正常渲染场景。这确实会带来一些开销（因为每个物体需要渲染两次），但在许多情况下性能增益是值得的。

生活类比：深度预通道就像是画家先勾勒一幅草稿来确定哪些区域最终会被前景覆盖，然后再正式上色。花一点时间画草稿，避免了在那些注定被遮住的区域浪费颜料和时间。

Early-Z 与 Hi-Z：在像素着色器运行前剔除

现代GPU实现的Early-Z（Early Depth Test）是游戏图形最重要的硬件优化之一。在传统管线中，深度测试发生在像素着色器执行之后——这意味着每个像素都先执行了昂贵的着色计算（即使最终被深度测试拒绝）。Early-Z将深度测试提前到像素着色器之前：

// 传统管线（Late-Z）：
顶点着色 → 光栅化 → 像素着色（昂贵！）→ 深度测试 → 写帧缓冲

// Early-Z管线：
顶点着色 → 光栅化 → 深度测试 → [通过] → 像素着色 → 写帧缓冲
                                → [失败] → 丢弃（像素着色器不执行！）

Hi-Z（Hierarchical Z-Buffer）是Early-Z的进一步增强。Hi-Z构建一个深度缓冲的mipmap金字塔，每一级存储对应区域的最小深度值（对Greater-Equal深度测试）或最大深度值（对Less-Equal）。光栅化产生一个像素块时，硬件先用最粗糙的Hi-Z层级快速测试整个块——如果整个32×32像素块都被遮挡，则跳过全部1024个像素的着色，节省量巨大。

最快渲染物体的方法就是不渲染它；因此，任何能尽早判断物体被遮挡的方法都是有用的。这不仅节省像素处理，也节省顶点处理，甚至节省本应用于将物体提交给图形 API 的 CPU 时间。视锥剔除（View Frustum Culling，见第 8.4.1 节）是普遍使用的，但在许多游戏中还不够。经常使用高级遮挡剔除（Occlusion Culling）算法，利用PVS（Potentially Visible Sets，潜在可见集）或BSP（Binary Spatial Partitioning，二叉空间分割）树等数据结构来快速缩小潜在可见物体的范围。

视锥剔除：六平面测试AABB

视锥剔除是每个游戏引擎的第一道过滤。视锥体由六个平面定义（近、远、左、右、上、下），每个平面可以由法向量 n 和距原点的有符号距离 d 表示：

对于一个轴对齐包围盒（AABB），定义其最小顶点 p_min 和最大顶点 p_max。测试AABB相对于一个平面的可见性时，只需检查AABB的"最不利点"——即在该平面法向量方向上离平面最远的那个角点：

六个面依次测试。一旦AABB完全位于任何一个平面的外侧，物体即可被安全剔除——不需要继续测试剩下的平面。

硬件遮挡查询（Hardware Occlusion Query）

视锥剔除能去掉相机视野外的物体，但对于室内场景中"被墙壁遮挡的大厅另一侧"的物体无能为力——这些物体在视锥体内，但被前景遮挡。硬件遮挡查询利用GPU的深度缓冲来解决这个问题：

// 伪代码：硬件遮挡查询流程
// 前提：深度缓冲已经包含所有前景遮挡物的深度值

// 第1步：发起查询
BeginOcclusionQuery(queryID);
  // 用一个极简的包围盒（或上一帧的低LOD）"试探性"渲染
  DrawBoundingBox(occludeeBoundingBox);
EndOcclusionQuery(queryID);

// 第2步：等待查询结果（通常延迟1-2帧以避免GPU停滞）
int visiblePixels = GetOcclusionQueryResult(queryID);
if (visiblePixels > threshold) {
  // 该物体有像素通过深度测试 → 可见
  DrawFullObject(object);
}
// 第3步：查询结果只有二进制意义
// ——"有像素通过"≠"物体显著可见"
// 现代引擎常用上一帧的查询结果来预测当前帧

即使物体可见，它可能处于足够远的距离，使得其大部分细节可以在无明显效果损失的情况下被移除。LOD（Level-of-Detail，层次细节）算法根据距离（或其他因素，如屏幕覆盖率或重要性）渲染物体的不同表示。这可以显著节省处理量，特别是顶点处理。如图 22.1 所示，同一物体的不同 LOD 等级的三角形数量可以相差数十倍。

生活类比：LOD就像从高楼窗户看街上的行人——远处的人只是一个模糊的轮廓，不需要看清他们的五官和衣服纹理；而当他们走近时，细节会逐渐丰富起来。同样，远处的3D模型可以用很少的三角形"草草勾勒"，近处的模型则需要精细到每一根手指。

LOD切换的距离阈值公式

LOD等级的选择通常基于物体在屏幕上的投影面积（Projected Area）或简单的距离阈值。给定物体包围球半径 r 和距离 d，其在屏幕上的近似投影高度（像素）为：

其中 h_res 是屏幕垂直分辨率，fov 是垂直视场角（通常60-90度）。当 h_screen 低于预设阈值时切换LOD等级：

纹理压缩：格式选型与压缩比

在§22.2.2中我们看到纹理是最大的内存消耗者。硬件纹理压缩是解决这个问题的核心手段。不同平台支持的压缩格式不同，选型时必须考虑目标平台：

在很多情况下，处理可以在游戏开始之前完成。这种预处理（Preprocessing）的结果可以存储起来每帧使用，从而加速游戏。这最常用于光照，利用全局光照算法计算整个场景的光照并存储在光照贴图（Lightmaps）和其他数据结构中供后续使用。

纹理压缩（Texture Compression）是另一项关键优化。现代 GPU 支持硬件加速的纹理压缩格式（如 DXT/BCn、ASTC 等），可以在几乎不影响视觉质量的前提下将纹理内存占用减少 4 到 8 倍。这对于显存有限的主机和移动平台尤为重要。类似地，着色器优化（Shader Optimization）通过精简数学运算、减少纹理采样次数、利用查找表替代复杂计算等手段，显著降低每个像素的计算成本。

生活类比：纹理压缩就像把照片从RAW格式转成JPG——肉眼几乎看不出区别，但文件大小从几十MB骤降到几MB甚至几百KB。着色器优化则像是在保证菜色的前提下简化烹饪步骤——能用一个锅炒的绝不洗两个锅。

22.3.x 着色器级别的微优化

着色器优化是游戏图形程序员日常工作的核心。以下优化技巧直接影响每帧几百万甚至几千万次像素着色器调用：

MAD融合（Multiply-Add Fusion）

现代GPU的ALU可以在单周期内完成一次乘加操作（a × b + c），其成本等同于单次乘法或加法。因此，将代码组织为MAD形式可以显著提升吞吐量：

// 差：2条指令
float result = a * b;
result = result + c;

// 好：1条指令（MAD融合）
float result = a * b + c;

// 更好：将多个运算表达为MAD链
float result = a * b + c * d + e;  // 2个MAD
// 编译器可自动识别MAD模式，但显式写出更可靠

分支扁平化（Branch Flattening）

GPU以Warp/Wavefront（通常32或64个线程）为单位执行。如果warp内的线程走向不同分支，两个分支都会被所有线程执行，然后通过掩码丢弃不相关的结果——这称为"分支发散"（Divergence），代价极高。

// 高发散风险：每个像素可能走不同分支
if (isInShadow) {
  color *= 0.5;
} else {
  color *= lighting;
}

// 扁平化方案：用数学替代分支
float shadowFactor = isInShadow ? 0.5 : lighting;
// 注意：?: 运算符在大多数现代编译器中也翻译为条件移动(cmov)，
// 但在不支持cmov的旧GPU上仍会产生分支。
// 更安全的写法：
float shadowFactor = lerp(lighting, 0.5, isInShadow);
color *= shadowFactor;

texture vs texelFetch

两者都是访问纹理数据的函数，但有本质区别：

寄存器压力与占用率

GPU的一个计算单元（SM/CU）可以同时驻留多个warp。当当前warp因纹理读取而等待时，硬件可以零开销切换到另一个warp执行计算——这种延迟隐藏是GPU高吞吐量的秘密。但如果着色器使用了过多寄存器，每个warp可驻留的数量就会下降，从而降低占用率（Occupancy）和延迟隐藏效率：

// 高寄存器压力：过多临时变量
float4 tmp1 = tex1 * factor1;
float4 tmp2 = tex2 * factor2;
float4 tmp3 = tex3 * factor3;
float4 tmp4 = tmp1 + tmp2 + tmp3;
// 每个tmp占用4个寄存器 → 16个寄存器仅用于中间值

// 低寄存器压力：尽早释放临时变量
float4 result = tex1 * factor1;
result += tex2 * factor2;
result += tex3 * factor3;
// 复用同一个寄存器 → 仅4个寄存器用于中间值

22.4 游戏类型（FPS / RPG / 策略 / 休闲）的技术重点

由于游戏需求差异很大，图形技术的选择取决于正在开发的游戏的确切类型。

处理时间的分配强烈依赖于帧率。目前，大多数主机游戏倾向于目标 30 fps，因为这可以实现更高的图形质量。然而，某些具有快节奏玩法的游戏类型要求极低延迟，这类游戏通常以 60 fps 渲染。这包括音乐游戏（如 Guitar Hero）和第一人称射击游戏（FPS，如 Call of Duty）。

22.4.1 第一人称射击游戏（FPS）—— 延迟即一切

FPS游戏对延迟的要求在所有游戏类型中最为苛刻。端到端的"从玩家扳动扳机到屏幕上出现枪口火光"的延迟如果超过50ms，玩家就能感知到"粘滞感"：

为降低延迟，竞技FPS通常采用以下图形策略：

• 关闭V-Sync：宁愿承受画面撕裂，也不增加一帧延迟。
• NVIDIA Reflex / AMD Anti-Lag：动态控制CPU提交节奏，避免渲染队列积压。
• 优先响应性：枪口火光、弹道轨迹、击中特效等战斗反馈效果使用最简化的着色器。
• 降低画质设置：竞技玩家往往将分辨率降到1080p、关闭阴影和后期效果，追求200+fps以最小化每帧延迟。

22.4.2 开放世界角色扮演游戏（RPG）—— 流式加载的艺术

开放世界RPG的地图可能达到数十甚至上百平方公里，包含海量资产。将所有数据装入内存是物理上不可能的——这就是流式加载（Streaming）发挥作用的地方。

流式加载的核心技术栈：

1. 世界分区：将世界划分为固定大小的网格或单元格（如100m×100m），每个单元格有独立的资产清单。
2. LOD系统 × 流式系统联动：远距离单元格只加载最低LOD的几何体和最低mip的纹理；随着玩家接近，渐进加载更高细节。
3. 优先级队列：玩家视锥体方向上的单元格获得最高加载优先级；身后区域可延迟甚至卸载。
4. 异步IO：资产加载在后台线程执行，不阻塞主线程。现代主机使用专用硬件解压块（如PS5的Kraken解压）以接近零CPU成本从SSD解压数据。

22.4.3 实时策略游戏（RTS）—— 实例化渲染的主场

RTS游戏（如《星际争霸》《帝国时代》）每帧可能有数百个完全相同的单位在屏幕上。如果用传统的逐物体渲染，几百个DrawCall将成为CPU瓶颈。GPU实例化（Instancing）将这个问题转化为GPU的拿手好戏：

// CPU端：提交一次DrawCall，指定实例数量
DrawIndexedInstanced(
  indexCountPerInstance,  // 一个单位的索引数
  instanceCount,           // "画300个！"
  0, 0, 0
);

// GPU端（顶点着色器）：
// SV_InstanceID 自动提供当前实例的编号（0到instanceCount-1）
struct VSInput {
  float3 position : POSITION;
  uint instanceID : SV_InstanceID;
};

// 用instanceID索引实例数据缓冲区
float4x4 worldMatrix = instanceDataBuffer[instanceID].worldMatrix;
float4 teamColor = instanceDataBuffer[instanceID].color;
// ... 每个实例有自己的位置、朝向、颜色等

对于RTS，实例化将CPU端的N次DrawCall合并为1次，而GPU端每个实例仍可独立变换——完美匹配"大量相似物体"的渲染需求。结合LOD系统，远距离的数百个单位可能总共只需几千个三角形。

22.4.4 赛车游戏 —— 反射的王国

赛车游戏是图形技术中反射（Reflection）需求最高的类型——车身的金属漆面、湿地面的倒影、车窗的环境映射，无处不反射。赛车游戏通常组合多种反射技术：

• 反射探针（Reflection Probes）：在赛道关键位置预置捕获点，运行时渲染或预处理周围环境的立方体贴图。车身着色器选取最近的反射探针进行采样。更新频率可以是每帧"重要探针"、每秒1次"普通探针"。
• 屏幕空间反射（SSR — Screen Space Reflections）：在屏幕空间中沿反射向量步进，采样深度缓冲寻找反射交点。优势是不需要额外的几何体或贴图；缺点是只能反射屏幕中已有的内容（屏幕外的物体无法反射），且步进开销随分辨率线性增长。
• 平面反射（Planar Reflections）：对于赛道上的水坑或湿地面，从水面以下的虚拟相机重新渲染场景到一张纹理——成本极高（相当于再渲染一遍场景），通常只在主机上使用且限定反射距离。
• 光线追踪反射（Ray-Traced Reflections）：新一代主机和高端PC利用硬件光追核心做真实反射。虽然计算成本高，但视觉质量远超传统方法——可以反射屏幕外的物体、产生正确的遮挡和多次反弹。

帧率决定了渲染场景的可用时间。场景本身的构成在不同游戏之间也差异很大。大多数游戏有背景几何体（Background Geometry，主要是静态场景）和前景几何体（Foreground Geometry，角色和动态物体）之分。它们由渲染引擎区别对待。例如，背景几何体通常带有包含预计算光照的光照贴图，这对前景物体不可行。预计算光照通常通过某种体积表示应用于前景物体，这种表示能够考虑每个物体随时间变化的位置。

有些游戏环境相对封闭，摄影机基本保持不动。最纯粹的例子是格斗游戏（如 Street Fighter 系列），但这在一定程度上也适用于 Devil May Cry 和 God of War 等游戏——这些游戏的摄影机不直接由玩家控制，游戏玩法倾向于从一个封闭环境移动到另一个，在每个环境中花费大量游玩时间。这使得游戏开发者可以为每个房间或封闭环境投入大量资源（处理、存储和美术时间），从而获得非常高的图形保真度。

22.4.5 格斗游戏与音乐游戏 —— 精确帧同步

格斗游戏和音乐游戏对帧率的稳定性有极端需求——不是"平均60fps"，而是"精确的每帧16.67ms"，因为游戏玩法的判定（格斗连招输入窗口、音乐节拍判定）与帧边界严格绑定。

格斗游戏的图形策略完全围绕"保证60fps不丢帧"这一原则：

• 只有两个高模角色在屏幕上，可以将大量GPU预算投入角色细节——高分辨率纹理、复杂的皮肤着色器（SSS）、发丝渲染。
• 背景是预烘焙的电影级场景，不需要动态光照，实质上是一张巨大的纹理映射在简单的几何体上。
• 所有视觉特效（粒子、冲击波）都在极其严格的三角形和填充率预算内。
• 帧同步要求意味着无法使用TAA（时间抗锯齿），因为TAA需要前一帧数据，可能在帧间引入轻微抖动。

音乐游戏的独有挑战是音频-视觉同步——画面提示符（如Note的移动轨迹）必须与音频节拍精确对齐到毫秒级。这要求图形管线的延迟是确定性的——任何可变的GPU负载（如动态阴影）都可能导致偏移。

其他游戏拥有极大的世界，玩家可以自由移动。这在沙盒游戏（Sandbox Games，如 Grand Theft Auto 系列）和在线角色扮演游戏（MMORPG，如 World of Warcraft）中最为突出。这类游戏对图形开发者构成巨大挑战，因为资源分配非常困难——每一帧玩家都可能看到世界的很大范围。进一步增加复杂性的是，玩家可以自由前往此前遥远的世界某处并从近处观察它。这类游戏通常有变化的昼夜时间，使得光照预计算即使不是不可能，也极其困难。

大多数游戏，如第一人称射击游戏，处于两个极端之间。玩家每帧可以看到相当范围的场景，但穿越游戏世界的移动在一定程度上受到约束。许多游戏还为每个关卡设定固定的昼夜时间，以简化光照预计算。

前景物体渲染的数量在不同游戏类型之间也差异很大。实时策略游戏（RTS，如 Command and Conquer 系列）在屏幕上通常有几十甚至上百个单位可见。其他类型的游戏可见角色数量更为有限，格斗游戏处于相反的极端——只有两个角色可见，每个都以极高的细节渲染。必须区分任何时刻可见的角色数量（影响处理时间预算）和可能在短时间内变为可见的独特角色数量（影响存储预算）。

游戏的类型或流派（Genre）也决定了观众对图形的期望。例如，第一人称射击游戏在历史上一直具有很高的图形保真度水平，这一期望驱动着该类型新游戏开发时的图形设计（见图 22.2）。另一方面，益智游戏（Puzzle Games）通常图形相对简洁，因此大多数游戏开发者不会投入大量编程或美术资源来为此类游戏开发照片级真实感图形。

尽管大多数游戏追求照片级真实感外观，一些游戏确实尝试更具风格化（Stylized）的渲染。一个有趣的例子是《大神》（Okami），可以在图 22.3 中看到其水墨画风格。对特定游戏的需求和限制进行创造性利用，是熟练游戏图形程序员的标志。一个很好的例子是《LittleBigPlanet》，它有一个"两个半维度"的游戏世界，由少量二维层次和一个非交互背景组成。该游戏的图形质量极佳，驱动因素是对这种环境类型专门定制的非传统渲染技术的使用；见图 22.4。

开发资源的管理也因游戏类型而异。大多数游戏有一到两年的封闭开发周期，在游戏发售后结束。最近，越来越多游戏提供可下载内容（DLC），可在游戏发售后购买，因此需要预留部分开发资源。持久世界在线游戏（Persistent-world Online Games）有一个永无止境的开发过程，只要游戏在经济上可行（可能是几十年的周期），就会持续生成新内容。

22.5 游戏制作流程（概念→预生产→生产→测试→发布→运维）

22.5.0 制作流程全景及各阶段的图形技术决策

游戏制作的每个阶段都有独特的图形技术决策和风险。下图为完整制作流程中各阶段对应的图形工作重心：

游戏制作流程从基本的游戏设计或概念（Game Design / Concept）开始。在某些情况下（如续作），基本的游戏玩法和视觉设计是明确的，只做增量修改。对于全新游戏类型，需要大量原型开发（Prototyping）来确定游戏玩法和设计。大多数情况处于中间——有一些新的玩法元素，视觉设计在某种程度上是开放的。此步骤之后可能有一个绿灯阶段（Greenlight Stage），向游戏发行商展示早期演示或概念以获得审批（和资金！）。

概念期的图形技术预研（Prototyping）

概念期虽然团队规模最小，但做出的图形决策对整个项目的技术方向有深远影响。图形程序员在此阶段的核心工作包括：

• 视觉风格验证：根据美术概念图制作小的技术Demo——"这个风格化卡通渲染方案在我们的预算内可行吗？""PBR管线的材质扫描流程需要什么设备？"
• 目标平台压力测试：用参考场景在最低配目标设备上运行，确定可行的三角形预算和纹理内存上限。例如，"在Switch上跑开放世界场景带100个角色——40 K triangles/frame的预算能否达到可接受的视觉效果？"
• 技术风险评估："我们需要大规模植被——现有的GPU实例化方案够用吗？""大范围动态破坏——物理+图形的联合预算是多少？"
• 渲染管线原型：用最小可运行的渲染器验证核心渲染方案（如延迟渲染的G-Buffer布局、阴影方案的基本可行性）。

下一步通常是预生产（Pre-production）。当其他团队在完成上一款游戏时，一个小的核心团队致力于对游戏引擎和制作工具链进行必要修改，以及打磨任何新玩法元素的粗略细节。这个核心团队在严格的截止日期下工作。在上款游戏发货后，团队其他成员从应得的假期归来时，整个工具链和引擎必须为他们准备就绪。如果核心团队错过这个截止日期，几十名开发者可能被迫闲置——这是极其昂贵的局面！

生活类比：预生产就像建筑工地的地基和脚手架搭建——大部队（施工队）还没进场前，核心工程团队必须确保所有基础设施到位。如果脚手架没搭好，上百号工人来了也只能干瞪眼。

预生产的图形管线选型

预生产阶段需要敲定的核心图形决策包括：

• 前向渲染 vs 延迟渲染：前向渲染的透明物体处理更自然、MSAA支持更好（抗锯齿质量高），但多光源性能差。延迟渲染的多光源性能优异、材质变化灵活，但MSAA困难、透明物体需要额外处理、G-Buffer带宽大。2020年代中期，许多引擎转向前向+（Forward+，即分簇前向着色）——结合了前向渲染的透明/Anti-Aliasing优势与延迟渲染的多光源效率。
• 阴影方案：标准阴影贴图 vs 级联阴影贴图（CSM）vs 虚拟阴影贴图（Virtual Shadow Maps）——级联数量、每级分辨率、投射距离的上限。
• 全局光照方案：预烘焙光照贴图（静态场景）vs 光照探针（动态物体）vs 实时GI（屏幕空间或探针光线追踪的）——取决于是否有动态昼夜和可破坏场景。
• 资产管线规范：纹理格式（BC7？ASTC？）、最大纹理分辨率、命名规范、材质参数范围限定、LOD生成标准。
• 工具链搭建：着色器编译器集成、资产导入器（FBX→引擎格式）、预览渲染器（美术师在DCC软件中看到的应等同于引擎中的效果）。

全面生产（Full Production）是下一步，整个团队创建美术资产、设计关卡、调整游戏玩法，以及实现对游戏引擎的进一步修改。在理想世界中，此过程中完成的一切都将用于最终游戏，但现实中游戏开发具有迭代特性，导致部分工作被丢弃和重做。目标是通过仔细规划和原型开发将这种浪费最小化。

生产期的图形资产标准制定

全面生产阶段，图形程序员的主要职责从"写代码"转向"建规范、做工具、管预算"：

• 资产预算执行：确保美术师不会不自觉地在单个物体上使用超出预算的三角形（"这个石像很漂亮，但350K tris对一个背景道具太奢侈了"）。这通常通过自动化检查工具在资产提交时强制执行。
• 材质与着色器管理：维护一个中心化的材质库，限制着色器变体数量（每个unique material × 每个quality level × 每个lighting scenario = 组合爆炸）。
• 光照烘焙管线：光照烘焙可能是整个生产流程中最耗时的离线处理——一个大型关卡的完整GI烘焙可能需要数小时甚至数天。图形程序员需要设计增量烘焙方案（只重新烘焙修改过的区域）和烘焙农场的分布式架构。
• 性能budget监控：建立自动化的每夜构建+性能回归测试——"今天的构建比昨天多花了2.3ms在阴影pass上，检出新提交的模型"。

当游戏功能完整时，最终阶段开始。Alpha 版本（Alpha Release）通常指开始大规模内部测试的版本，Beta 版本（Beta Release）指开始大规模外部测试的版本，黄金版本（Gold Release）指提交给主机制造商的最终版本——但不同公司对这些术语有略微不同的定义。无论如何，测试/质量保证（QA，Quality Assurance）是这一阶段的重要组成部分，涉及游戏开发工作室、发行商、主机制造商的测试人员，可能还有外部 QA 承包商。这些多轮测试产生的缺陷报告被提交回游戏开发者，持续修复直到下一个版本。

测试期的图形性能剖析（Profiling）

测试期是图形程序员最紧张的阶段——在有限的几周内将帧率从不稳定的40fps优化到稳定的60fps。主要工具和手段：

• GPU Profiler：RenderDoc（跨平台）、PIX（Xbox/Windows）、Radeon GPU Profiler、NVIDIA Nsight Graphics——逐DrawCall查看GPU耗时，定位最昂贵的绘制批次。
• 帧分析器：截取单帧的所有GPU事件并显示时间线——"阴影贴图pass为什么花了3.8ms？哦，因为场景中有47个投射阴影的光源！"
• CPU Profiler：定位CPU端的瓶颈——是DrawCall提交太多（>3000/帧）？场景遍历太慢？剔除算法不够激进？
• 画质档位调校：为每个画质档位（低/中/高/极高）定义具体的降级策略：降低阴影分辨率、减少光源数量、禁用特定后处理效果、降低LOD切换距离。
• 最低配置验证：在"最低配置"硬件上完整通关——确保所有可玩内容都在可接受的帧率范围内（通常>25fps）。

游戏发售后，大多数开发者去休假一段时间，但一小部分人可能需要留下来处理补丁或可下载内容。与此同时，另一个小型核心团队已经开始为下一款游戏进行预生产。

运维期的图形热修复与持续更新

游戏发布后，图形团队面临的工作可能包括：

• 首日补丁：Gold版本提交后到玩家拿到光盘/下载期间（通常2-4周），继续修复发行前未处理的紧急Bug——"NVIDIA最新驱动下HDR渲染发生条纹伪影"。
• 新GPU驱动适配：新上市的GPU或驱动更新可能导致渲染异常——需要在玩家大规模报告前发现并修复。
• DLC的图形集成：DLC通常引入新关卡、新角色、新效果——这些新资产必须适配现有的渲染管线和性能预算。
• 画质补丁：有时团队在发布后还有时间优化——"我们发布时的阴影过滤有瑕疵，1.2补丁改进了PCF采样模式，阴影更柔和了"。
• 技术债偿还：发布前为赶进度而遗留的hack和workaround，在运维期间逐步用正确的实现替代。

22.5.1 资产创建

美术资产创建是游戏生产中与图形开发特别相关的方面，因此我将详细展开。虽然美术资产创建的确切流程因游戏而异，但我这里给出的概述相当有代表性。过去，单个美术师会从头到尾创建整个资产，但现在这一流程已高度专业化，不同技能的人在各个阶段对每个资产进行工作。其中一些阶段有明确的依赖关系（例如，角色在绑定之前无法动画，在建模之前无法绑定）。大多数游戏开发者有明确的审批流程，美术总监或主美术师在每个阶段签字后资产才被送往下一阶段。理想情况下，资产经每个阶段恰好一次，但实践中可能发生需要重新提交的更改。

初始建模

通常，美术资产创建流程从建模（Modeling）物体几何体开始。此步骤在通用建模软件中完成，如 Maya、3ds MAX 或 Softimage。建模的几何体将直接传递给游戏引擎，因此关键是在保持良好轮廓的同时最小化顶点数量。角色网格还必须构建得适合动画。

在此阶段，通常会创建纹理的二维表面参数化（UV Parameterization / UV Unwrapping）。重要的是这种参数化高度连续，因为不连续性需要顶点复制并可能导致过滤伪影。带有相关纹理参数化的网格示例见图 22.5。

贴图/纹理制作

过去，纹理是在 Photoshop 中直接绘制颜色贴图的直接过程。现在，细节建模软件（Detail Modeling Packages）如 ZBrush 或 Mudbox 被普遍用于雕刻精细的表面细节。图 22.6 和图 22.7 展示了这一过程。如果这些额外细节要用实际几何体表示，将需要数百万个三角形。取而代之的是，细节通常"烘焙"为法线贴图（Normal Map），应用于原始粗糙网格，如图 22.8 和图 22.9 所示。

除非法线贴图外，还会创建包含表面属性的多种纹理：漫反射颜色（Diffuse Color）、高光颜色（Specular Color）和光滑度（Smoothness / Specular Power）。这些要么在细节建模应用中直接在表面上绘制，要么在二维应用如 Photoshop 中绘制。所有这些纹理贴图使用初始建模阶段定义的表面参数化。当纹理在二维绘画应用中绘制时，美术师必须频繁在绘画应用和另一个能显示应用纹理后物体三维渲染的应用之间切换。这个迭代过程见图 22.10 至图 22.13。

着色

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

光照

对于背景场景，光照美术师（Lighting Artists）通常在建模、纹理和着色完成后开始工作。放置光源，在预处理步骤中计算其效果。此过程的结果存储在光照贴图（Lightmaps）中供渲染引擎后续使用。

动画

角色网格经历几个与动画相关的额外步骤。游戏角色动画的主要方法是蒙皮（Skinning）。这需要一个骨骼（Rig），由附着在角色上的变换节点层次结构组成——这一过程称为绑定（Rigging）。每个变换节点的影响区域绘制到网格顶点的一个子集上。最后，动画师创建动画，移动、旋转和缩放这些变换节点，"拖动"网格跟随运动。

一个典型的游戏角色会有几十个动画，对应不同的运动模式（行走、跑步、转向）以及不同的动作如攻击。对于主角，动画数量可达数百个。不同动画之间的过渡（Transitions）也需要定义。

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

课后练习题（含答案）

QA 零基础问答区