图形栈与渲染引擎架构

渲染问题的四种看法（卷 II 11.1.1）

• 数据转换：输入是三维空间中场景元素、光源和相机的数学模型，输出是 $W\times H$ 的二维数组，每个元素（像素）以适合显示设备的数字格式存颜色。
• 几何问题：物体表面被拆成三角形等简单图元，顶点变换到相机坐标系再投影到屏幕；在屏幕空间可以只连线画线框，也可以填充内部像素，颜色来自纹理和/或光照计算。
• 可见性判定与着色：相机有 $N$ 个传感器（像素），先解决可见性问题——找出每个传感器 $j$ 直接看到的表面点 $\mathbf{x}_j$；再解决光照问题——求每个 $\mathbf{x}_j$ 朝相机反射的光的强度和颜色。（MSAA 等技术会让一个像素混合多个表面点，二者并非严格一一对应。）
• 相机模拟：理解光的行为、光与物质的交互、数码相机怎样测量光子，需要几何光学、光传输物理、辐射度量学与光度学、色彩理论和数值积分。可以接受非真实感时，可做简化：光源当理想点、只算直接光照、把最贵的计算离线预计算；追求真实感时则用有面积的光源和间接光照。

"可见性"一词也指判断某个物体是否可能被相机看到，这是一种避免渲染无贡献物体的优化，即剔除（见 剔除技术）。

渲染引擎的类型（卷 II 11.1.2）

把图形计算从 CPU 移到 GPU 有双重好处：画面保真度远高于 CPU 能做到的，同时 CPU 腾出来做音频、物理、NPC 的 AI 和玩家操控。GEA 认为这也是实时三维渲染几乎一直用光栅化而非光线追踪的另一个原因。光传输理论见 渲染方程，PRT 见 预计算辐射传输，GPU 光追见 硬件光线追踪管线。

原书问题（11.1.2）：

• GEA 说光线投射"缓存不友好、难以并行"。缓存不友好成立（相邻光线，尤其是反弹后的次级光线，访问的几何和 BVH 节点很分散，在 SIMD 硬件上还会发散），但"难以并行"不准确：各像素的光线彼此独立，逐像素光线追踪是"易并行 (embarrassingly parallel)"问题的标准例子（Wikipedia "Embarrassingly parallel"，引 Chalmers 等《Practical Parallel Rendering》）。真正的难点是并行之后的访存一致性和每条光线遍历加速结构的代价，而不是能否并行。
• GEA 把 PRT 说成"实际上是辐射度方法的离线应用"，这是简化说法。Sloan、Kautz、Snyder 的原始 PRT（SIGGRAPH 2002，"Precomputed Radiance Transfer for Real-Time Rendering in Dynamic, Low-Frequency Lighting Environments"）用蒙特卡洛光线追踪离线算出物体的 SH 传输函数，运行时光照可以动态变化，也能处理光泽反射；只有 Enlighten 一类表面间传输的变体才接近辐射度（形状因子），且也不解辐射度的线性方程组。见 预计算辐射传输（RTR4 11.5.3）。

图形栈（卷 II 11.3.1）

渲染引擎由多层软硬件组成，称为图形栈 (graphics stack)。下图自下而上画出典型的管线式渲染引擎各层。

flowchart BT
    HW["硬件: CPU 与主内存, GPU 与显存"] --> DRV["操作系统与 GPU 驱动"]
    DRV --> API["底层图形 API: OpenGL, D3D, Vulkan, Metal"]
    API --> RE["渲染引擎"]
    RE --> GE["游戏引擎"]

• 硬件：主板、一个或多个 CPU 核心、多级 CPU 缓存、内存；几乎所有游戏 PC 和主机都有 GPU。GPU 在主机上位于主板，在 PC 上位于扩展卡，直接访问显存（见 GPU 内存、缓冲压缩与多重缓冲、计算机硬件与内存层次）。
• 操作系统与驱动：PC 上是 Windows、macOS 或 Linux，主机用定制系统（如通过 PS5 SDK 编程的 PS5 系统）。Steam Deck 底层运行 Linux，但通常通过 Windows 兼容层 Proton 运行 Windows 游戏，无需移植。（GEA 原文称 Proton 为"Windows 模拟层"，并说 Steam Deck"通过 Proton 编程"。原书问题：Proton 基于 Wine，是把 Windows API/Direct3D 调用翻译成 Linux/Vulkan 调用的兼容层，不模拟 CPU 或硬件（Wine 的名字本身就是 "Wine Is Not an Emulator"）；开发者照常面向 Windows（或原生 Linux）编程，Proton 是运行时层而非编程接口（Valve Proton GitHub 仓库 README；Wikipedia "Proton (software)"）。）
• 渲染引擎：游戏引擎众多子系统之一，内部通常也是分层的（见 运行时引擎分层架构）。

保留模式与立即模式（卷 II 11.3.1.3）

两种架构都用某种场景图在内存中表示场景内容、支持快速随机访问，都有一个或多个虚拟相机提供视图；区别在于场景图由谁管理：

立即模式的下层就是三维图形管线，结构由 API 固定，部分阶段可用着色器定制；上层应用层通常是 CPU 上的软件，设计因引擎而异（见 渲染管线 中关于"应用阶段还是应用层"的分歧）。

应用层的三项职责（卷 II 11.5）

1. 剔除与可见性判定：只把可见（至少可能可见）的物体交给 GPU，见 剔除技术、遮挡剔除，空间组织见 空间数据结构。
2. 提交几何：把子网格-材质对用 DrawIndexedPrimitive()（DirectX）、glDrawArrays()（OpenGL）之类的调用或直接构建 GPU 命令列表提交给 GPU；可为性能排序；场景需要多遍渲染时同一几何可能提交多次。
3. 控制着色器参数和渲染状态：按图元配置经常量寄存器传入的 uniform 参数，并设置不可编程阶段的所有可配置参数（见 绘制调用与状态切换优化、图形 API 设备、管线状态与资源）。

边界上移：走向 GPU 驱动与保留模式

• 应用与管线的边界一直在沿图形栈上移：最早整条管线是 CPU 软件；3Dfx Voodoo 把最贵的后段搬进硬件；GPU 又接管了更多原属应用层的工作。如今的渲染引擎负责配置和场景管理，大部分实际渲染交给 GPU（卷 II 11.3.1.5）。
• 新趋势是把应用层也以计算着色器的形式搬到 GPU，释放 CPU；加上网格着色器（见 网格着色器管线），GPU 上的管线本身也变得不那么"管线"、更随机访问。GEA 认为这实际上是在回归保留模式，代表是 UE5 的 Nanite（见 Nanite 虚拟化几何体），顽皮狗的引擎也在朝这个方向发展。UE5 的线程与渲染结构见 UE5 渲染架构。

取舍

• 保留模式把渲染细节对客户端隐藏，客户端只管填充和更新场景图；它适合需要随机访问整个场景的算法（光线追踪、辐射度）。
• 立即模式由应用层自己管理场景图、配置管线和提交元素，是光栅化引擎的常态；代价是剔除、排序、状态管理等工作都落在应用层（通常是 CPU）上，这正是 GEA 第 11.5 节要讨论的内容。
• 把应用层搬到 GPU 能释放 CPU 去做其他引擎工作，但会模糊应用与管线的界线，使引擎重新带上保留模式的特点（卷 II 11.3.1.5）。

PBRT 的视角：图形状态与扩展点（PBRT 4e C.2.3–C.4）

• 两个区块：WorldBegin 之前只能指定相机、胶片、采样器、积分器等全局选项，之后只能指定形状、光源、纹理、材质；变换和介质两边都可以。这样创建形状时相机和分辨率已经确定，例如曲面可以按屏幕覆盖面积立即细分。
• 图形状态：当前材质、当前变换矩阵 (CTM)、RGB 色彩空间、面光源设定、当前介质。CTM 实际上是两个矩阵（起止时刻），activeTransformBits 决定变换语句作用于哪一个，两者不同就构成动画变换（练习 C.2 建议推广到任意关键帧或时间函数）。Translate() 等把变换右乘到 CTM。AttributeBegin/AttributeEnd 压入、弹出整个 GraphicsState，用于层级建模（先放车身，再相对放车轮）。
• 变换的内存：单精度下每个 Transform（矩阵及其逆）占 128 字节，用 InternCache 驻留后，形状只存 const Transform *。形状最终使用的是"渲染空间 ← 物体"的变换，需要乘上由相机定义的"渲染空间 ← 世界"变换。
• 新增一种对象类型的三步：把源文件加入 CMakeLists.txt；把类型名加入对应接口所继承的 TaggedPointer 类型列表；在接口的 Create() 中按名称分派到新类型。