从渲染方程到路径追踪：现代真实感渲染的统一框架

从 Rendering Equation 出发，理解 Path Tracing 如何统一阴影、全局光照、反射与折射，以及 SSAO、SSR、大气散射、体积云、相机效果和风格化渲染在整个渲染体系中的位置。

如果打开一个现代游戏引擎的 Renderer，我们往往会看到一长串看起来彼此独立的技术：

Shadow Map
SSAO / GTAO
SSR
Reflection Probe
Light Probe
Lightmap
Screen Space GI
Ray Traced Reflection
Volumetric Fog
Bloom
Depth of Field
Motion Blur

它们似乎分别解决不同的问题：

阴影是一套系统，反射是一套系统，全局光照又是一套系统。

但如果把视角从“如何实现某个视觉效果”提升到“现实世界为什么会产生这些视觉效果”，就会发现其中相当一部分现象其实来自同一个根本问题：

光如何在场景中传播？

1986 年，James T. Kajiya 在经典论文 The Rendering Equation 中给出了一个统一描述表面光传输的积分方程，并进一步讨论了如何使用 Monte Carlo 方法求解它。¹

这篇文章不会把 Rendering Equation 当成一个孤立公式，而是尝试建立一张更完整的现代渲染知识地图：

Loading diagram…

理解这张图以后，许多看似零散的渲染技术就会重新回到同一套坐标系里。

1从渲染效果到光传输

1.1为什么游戏里有这么多独立的渲染技术

传统实时 Renderer 面对的是一个非常残酷的约束：

必须在大约十几毫秒内生成整张画面。

以 60 FPS 为例，一帧只有：

\frac{1}{60}\approx16.67\text{ ms}

在这个预算里不仅要完成光照，还要处理：

Geometry
Animation
Skinning
Culling
Shadows
Post Processing
UI
GPU Synchronization

因此，游戏图形学历史上大量技术的出发点并不是：

怎样最准确地模拟现实？

而是：

怎样用极低成本制造一个看起来像现实的结果？

例如镜面反射。

真正的反射意味着从表面继续向场景发射光线，找到它所看到的物体。

但过去这件事情太昂贵，于是出现了 Screen Space Reflection：

真实问题：
从反射方向继续查询整个 3D 世界

        ↓ 太贵

SSR：
只从当前屏幕已有的 Color + Depth 中寻找答案

阴影也是如此。

真正的问题是：

光源和表面之间是否有东西阻挡？

传统实时渲染却通常先从光源渲染一张深度图，再用 Shadow Map 比较深度。

这些方法不是错误。

恰恰相反，它们是实时图形学最重要的工程智慧之一：

既然无法计算原因，就寻找一个足够便宜的结果近似。

1.2Shadow、AO、Reflection、GI 真的是不同问题吗

从 Renderer 的 API 看：

Shadow
Reflection
Ambient Occlusion
Global Illumination
Refraction
Caustics

当然是不同功能。

但从物理角度，它们并不是六种互不相关的“特效”。

例如：

Loading diagram…

不同光路产生了不同视觉结果：

光源直接照到物体 → Direct Lighting
光源被物体挡住 → Shadow
光从墙反射到地板 → Indirect Lighting
红墙把红色光反射给白墙 → Color Bleeding
光进入镜面后改变方向 → Reflection
光穿过介质 → Transmission / Refraction
光经过玻璃聚焦 → Caustics

它们背后的共同问题都是：

光从哪里来，又经过了什么？

一个非常重要的区分是：

视觉现象不等于实现这种视觉现象的算法。

Reflection 是现象，SSR 是算法。

Shadow 是现象，Shadow Map 是算法。

间接光照是现象，Lightmap 是一种求解和缓存方案。

1.3从“模拟效果”到“模拟原因”

这带来了一种非常重要的思想变化。

传统实时图形学经常问：

我要怎样实现阴影？

我要怎样实现 Reflection？

我要怎样实现 GI？

而物理光传输的思路则是：

能不能直接模拟产生这些结果的原因？

如果我们能够正确模拟：

Light
 ↓
Propagation
 ↓
Geometry
 ↓
Material Scattering
 ↓
More Propagation
 ↓
Camera

那么许多视觉效果根本不需要被单独“添加”。

它们会作为光传播的结果自然出现。

而描述这个问题最重要的理论基础之一，就是 Rendering Equation。

2Rendering Equation：表面光传输的统一描述

2.1一个表面为什么会呈现某个亮度和颜色

想象摄像机正在观察墙壁上的一个点。

这个点为什么是红色，而且为什么是现在这个亮度？

最简单的答案是：

因为有光从这个点进入了摄像机。

我们把从表面点 $x$ 沿方向 $\omega_o$ 离开的 Radiance 写作：

L_o(x,\omega_o)

那么这部分光可能来自两个来源。

第一种：

表面本身正在发光。

例如：

LED
火焰
发光屏幕
Emissive Material

记作：

L_e(x,\omega_o)

第二种：

别的地方来的光照到了这里，然后被表面反射出去。

于是有：

\boxed{ \text{Outgoing Light} = \text{Emission} + \text{Reflected Incoming Light} }

这就是 Rendering Equation 最核心的思想。

2.2Rendering Equation 的基本形式

常见的表面反射形式可以写成：

L_o(x,\omega_o) = L_e(x,\omega_o) + \int_{\Omega^+} f_r(x,\omega_i,\omega_o) L_i(x,\omega_i) (\mathbf n\cdot\omega_i) \,d\omega_i

乍看复杂，但可以拆成几个非常直观的部分。

项	含义
$L_o$	朝观察方向离开表面的 Radiance
$L_e$	表面自身发出的 Radiance
$L_i$	某个方向照到表面的 Radiance
$f_r$	BRDF，描述材质如何反射光
$\mathbf n\cdot\omega_i$	入射角度带来的余弦权重
$\Omega^+$	表面上方整个半球
$\int$	把所有入射方向的贡献加起来

因此它真正表达的是：

一个表面向某方向发出的光，等于自身发光，加上整个半球中所有入射光经过材质散射后的总和。

PBRT 将它称为 Light Transport Equation，并指出它描述了场景中 Radiance 的平衡分布。²

2.3Radiance、BRDF 与半球积分

2.3.1Radiance：我们究竟在计算什么

Rendering Equation 并不是简单地在计算一个 RGB Color。

它描述的是 Radiance（辐亮度）。

可以暂时把 Radiance 理解为：

某个位置，沿某个方向传播的光能密度。

这也是为什么它同时依赖：

x

和：

\omega

位置相同但方向不同，Radiance 可以完全不同。

镜子就是最明显的例子。

2.3.2BRDF：材质如何回应光

BRDF：

Bidirectional Reflectance Distribution Function

描述的是：

f_r(\omega_i,\omega_o)

即：

光从 $\omega_i$ 方向进来时，有多少会沿 $\omega_o$ 方向出去？

不同材质的差异，本质上就在这里。

粗糙墙壁：

Incoming
   ↓
 ↙ ↓ ↘
Diffuse Scattering

镜面：

Incoming
     \
      \
       \ Surface
        \
         \ Reflection

现代 PBR 中常见的：

Lambert
Cook-Torrance
GGX
Fresnel
Smith Masking-Shadowing

都在描述局部材质和光之间的相互作用。

如果还需要 Transmission，则通常进一步使用更一般的 BSDF：

Bidirectional Scattering Distribution Function

把反射和透射统一起来。

2.3.3为什么是积分

光可能从整个半球中的任意方向到来：

        ↘ ↓ ↙
      ↘   ↓   ↙
    →     ●     ←
          ↑
       Surface

因此不能只检查：

光源方向有没有光？

理论上必须考虑：

所有可能方向。

于是出现：

\int_{\Omega^+}

这也是 Rendering Equation 难以直接求解的第一个原因。

2.4为什么 Rendering Equation 是递归的

更困难的问题来自：

L_i

入射光到底从哪里来？

假设：

Sun
 ↓
Red Wall
 ↓
White Floor
 ↓
Camera

地板收到的光可能来自红墙。

而红墙收到的光又来自太阳。

所以：

L_i(\text{Floor})

实际上来自另一个位置上的：

L_o(\text{Wall})

而那个 $L_o$ 本身又由 Rendering Equation 决定。

于是形成：

Loading diagram…

从数学上可以把 Rendering Equation 抽象成：

L=L_e+KL

其中 $K$ 表示一次光传播与散射操作。

继续展开：

L = L_e + KL_e + K^2L_e + K^3L_e +\cdots

它有非常漂亮的物理解释：

L_e

代表直接来自光源的贡献；

KL_e

代表一次反弹；

K^2L_e

代表两次反弹；

依此类推。

2.5从直接光到多次间接反弹

于是所谓 Global Illumination，并不是突然出现的另一种理论。

它只是：

不再只考虑第一跳光照，而是继续追踪光在整个场景中的传播。

例如：

Sun
 ↓
Window
 ↓
Floor
 ↓
Wall
 ↓
Ceiling
 ↓
Camera

如果只计算第一跳，房间深处可能几乎完全黑掉。

但现实中：

被照亮的表面本身也会继续照亮其他表面。

这就是：

Indirect Lighting
Color Bleeding
Multi-bounce GI

的根源。

Rendering Equation 最重要的价值，并不是“提供一个新的光照公式”，而是把许多看似独立的渲染方法放进同一个 Light Transport 框架里理解。

3从方程到图像：Ray Tracing 与 Path Tracing

3.1Rendering Equation 不是一种渲染算法

这里特别容易混淆。

Rendering Equation 描述的是：

正确答案应该满足什么关系。

但它并没有告诉我们：

计算机应该怎样高效地算出答案。

这类似于：

F=ma

描述了物理规律，却不是一段模拟器代码。

PBRT 直接指出，对于一般复杂场景，Light Transport Equation 无法得到闭式解析解，因此必须使用数值方法求解。³

所以接下来真正的问题变成：

怎样估计那个巨大而递归的积分？

3.2Ray Tracing 到底解决什么问题

Ray Tracing 比 Path Tracing 更基础，也更宽泛。

它最核心的能力可以浓缩成一个查询：

给定一条 Ray，它首先撞到了什么？

Ray(origin, direction)
        ↓
       BVH
        ↓
Triangle Intersection
        ↓
Closest Hit

例如：

Camera
   \
    \ Ray
     \
      ● Wall

计算机需要回答：

是否碰撞？
碰到了哪个 Triangle？
距离是多少？
Hit Position 在哪里？
Normal 是什么？
Material 是什么？

这就是 Ray Intersection。

实际场景可能拥有数百万甚至数十亿 Triangle，因此通常还需要：

BVH
BLAS / TLAS
Spatial Acceleration Structure

来避免每条 Ray 都检查整个场景。

3.3为什么需要 Monte Carlo Integration

Rendering Equation 中存在：

\int_{\Omega} f(\omega)d\omega

但方向是连续无限的。

计算机显然不可能：

把无限多个方向全部计算一遍。

Monte Carlo 的思路非常简单：

那就随机抽一些方向。

对于一般积分：

I=\int_{\Omega} f(x)dx

如果按照概率密度 $p(x)$ 采样 $N$ 个点：

x_1,x_2,\dots,x_N

就可以估计：

I \approx \frac{1}{N} \sum_{k=1}^{N} \frac{f(x_k)}{p(x_k)}

这意味着：

Infinite Directions
       ↓
Random Sampling
       ↓
Finite Samples
       ↓
Average
       ↓
Approximate Integral

样本越多，通常越接近真实积分。

但代价就是：

噪声。

3.4Path Tracing 如何求解 Rendering Equation

Path Tracing 把 Monte Carlo Sampling 与 Ray Tracing 组合起来。

可以从 Camera 发射 Ray：

Loading diagram…

每次碰到表面时，根据 BSDF 随机选择一个新的传播方向：

Camera
  ↓
Surface
  ↘
   Surface
      ↗
     Surface
        ↓
       Light

每一条完整路径都代表：

一种光可能经过场景到达摄像机的方式。

重复大量路径以后，对它们的贡献进行统计平均，就可以估计 Rendering Equation。

因此：

Loading diagram…

这张关系图非常重要。

可以简单记成：

Rendering Equation 是问题。

Path Tracing 是求解方法。

Ray Tracing 是 Path Tracing 用来查询场景的基础能力。

3.5Sampling、SPP、Noise 与 Denoising

SPP：

Samples Per Pixel

表示每个像素采样多少条路径。

如果只有：

1\text{ SPP}

那么每个像素只观察了极少数可能光路，很容易出现剧烈随机误差。

随着：

N\uparrow

噪声会下降。

Monte Carlo 估计的标准误差通常按照大约：

O\left(\frac{1}{\sqrt{N}}\right)

下降。

这意味着一个有些残酷的事实：

想把噪声降低到原来的约一半，通常不是多算一倍，而可能需要大约四倍样本。

于是现代 Path Tracing 的研究重点并不只是：

发更多 Ray。

而是：

怎样让每一条 Ray 更有价值？

于是产生：

Importance Sampling
Next Event Estimation
Multiple Importance Sampling
Russian Roulette
Reservoir Sampling
ReSTIR
Temporal Reuse
Spatial Reuse
Denoising
Ray Reconstruction

Denoising 并不是 Rendering Equation 的组成部分。

它解决的是另一个问题：

当我们只有很少 Monte Carlo 样本时，怎样从 noisy estimate 恢复一个稳定图像？

3.6Rendering Equation、Path Tracing、Ray Tracing 的关系

最终可以用一张知识树总结：

Light Transport Theory
        │
        ▼
Rendering Equation
        │
        │ numerical solution
        ▼
Monte Carlo Integration
        │
        ▼
Path Tracing
        │
        │ scene query
        ▼
Ray Tracing
        │
        ▼
BVH / Ray-Triangle Intersection

因此：

\boxed{ \text{Path Tracing} \subset \text{Ray-Tracing-based Rendering Methods} }

而不是反过来。

经典 Whitted Ray Tracing、Hybrid Ray Tracing、Path Tracing 等都使用了 Ray 查询，但它们怎样产生、传播和组合这些 Ray 并不相同。

4为什么我们曾经需要 SSAO、SSR 和各种近似

4.1物理现象与渲染算法不是一回事

现在就可以重新理解传统实时 Renderer。

我们真正想得到的是：

Light Transport

但完整求解太昂贵。

于是历史上大量技术选择：

只近似某个局部现象。

想解决的问题	常见实时技术
可见性与阴影	Shadow Map / CSM
近距离环境遮蔽	SSAO / GTAO
镜面反射	SSR / Reflection Probe
漫反射间接光	Lightmap / Light Probe / SSGI
柔和阴影	PCF / PCSS
动态间接光	Voxel GI / Probe GI / RTGI

Path Tracing 的不同在于：

它试图重新回到共同原因——Light Transport。

4.2AO 与 SSAO

这里需要做一个很重要的概念修正。

Ambient Occlusion 并不是像 Reflection 一样独立存在的基本光学规律。

AO 本身已经是一种简化模型。

它大致描述：

一个表面点周围有多少方向被附近几何体遮挡。

例如墙角：

│
│
│________

墙角周围很多方向都被几何体挡住，因此在均匀环境光假设下通常应该较暗。

AO 可以表达为类似：

A(x) = \frac{1}{\pi} \int_{\Omega} V(x,\omega) (\mathbf n\cdot\omega) \,d\omega

其中：

V(x,\omega)

表示该方向是否被遮挡。

但是现实世界并不存在一个单独的：

AO 光照项。

真正发生的是：

来自不同方向的间接光被不同程度遮挡。

如果完整计算 Global Illumination，这种“角落较暗”的趋势会自然出现。

SSAO：

Screen Space Ambient Occlusion

则进一步把 AO 近似放到 Screen Space 中完成：

Depth Buffer
+
Normal Buffer
+
邻域采样
        ↓
估计局部几何遮挡

因此关系更加准确地说是：

真实 Multi-bounce Light Transport
            ↓ 简化
       Ambient Occlusion
            ↓ 屏幕空间近似
           SSAO

而不是：

Path Tracing 内部包含一个 SSAO。

4.3Reflection 与 SSR / Reflection Probe

反射本身则直接属于光传输。

镜面击中光以后改变传播方向：

Incoming Ray
      \
       \
--------●---------
         \
          \
       Reflected Ray

Path Tracing 可以继续沿新方向查询真实场景。

SSR 则只拥有当前屏幕已经渲染出的信息：

Color Buffer
Depth Buffer
Normal
   ↓
Screen-Space Ray Marching

所以 SSR 天生无法看到：

屏幕外物体
被前景完全挡住的物体
当前 Camera 根本没有观察到的几何

这不是 SSR 实现得“不够好”。

这是它的信息来源决定的理论限制。

Reflection Probe 则采取另一条路线：

提前把周围环境存进 Cubemap，然后重复利用。

两者都是：

为避免真正追踪整个场景而进行的工程折中。

4.4Shadow 与 Shadow Map

物理意义上的 Shadow 非常简单：

光源和表面之间存在遮挡。

Path Tracing 可以发射 Shadow Ray：

Surface
   │
   │ shadow ray
   ▼
Light

如果中间碰到几何：

Surface
   │
   X Object
   │
 Light

光源贡献就是 0。

Shadow Map 则没有直接查询：

Surface → Light 的这条 Ray 是否被挡住？

而是预先站在光源的位置渲染 Depth：

Light View
   ↓
Depth Map
   ↓
Camera Rendering
   ↓
Depth Comparison

所以 Shadow Map 会产生：

Bias
Peter Panning
Shadow Acne
Resolution
Cascade
Filtering

等一整套工程问题。

它们并不是“阴影本身的问题”。

而是：

Shadow Map 这种近似表达方式所产生的问题。

4.5GI 与 Lightmap / Light Probe / SSGI

真正的 Global Illumination 是：

光可以经过多个表面继续传播。

例如：

Sun
 ↓
Red Wall
 ↓
White Floor

地板会被染上一点红色。

Lightmap 的思路是：

既然实时计算很贵，那提前算好然后存在纹理里。

Light Probe：

把空间中某些位置的低频光照预计算并缓存下来。

SSGI：

尝试利用屏幕信息估计间接光。

Probe-based GI：

在稀疏空间采样点上缓存 Radiance 或 Irradiance，再插值使用。

这些技术并不是和 Path Tracing 描述不同的世界。

很多时候，它们只是在问：

怎样用更少计算、更少信息、更强假设，逼近完整 Light Transport？

4.6Path Tracing 能否最终取代这些技术

如果假设：

无限算力
无限内存
没有功耗限制
可以使用足够高的 SPP
我们追求物理光传输结果

那么许多技术确实没有存在必要。

例如：

SSR
Reflection Probe
SSAO
Shadow Map
Static Lightmap

因为 Path Tracing 已经在直接求解它们试图近似的问题。

Minecraft with RTX 就很好地展示了这种思路：其 Path-Traced Renderer 使用一个统一的光传输模型生成直接光、阴影、GI、反射、折射等过去经常由不同实时算法负责的效果。⁴

但现实世界没有无限 GPU。

实时 Renderer 仍然受到：

Performance
Power
Latency
Memory
Temporal Stability
Platform Compatibility
Artistic Control

限制。

因此更准确的说法不是：

Path Tracing 会消灭所有传统技术。

而是：

Path Tracing 给出了一个越来越接近 Ground Truth 的统一方向，而实时图形学继续研究怎样以更低成本逼近它。

5Rendering Equation 之外：完整的光传输与成像

到这里很容易产生一个新的误解：

如果 Rendering Equation 能统一这么多东西，那是不是整个 Renderer 最后只剩这一个方程？

并不是。

经典 Rendering Equation 主要讨论：

表面之间的光传输。

而现实世界还有：

空气
雾
烟
云
镜头
光圈
快门
Sensor
Display

所以真正更大的概念应该是：

\boxed{\text{Light Transport}}

甚至进一步是：

\boxed{\text{Image Formation}}

5.1Surface Transport 与 Volume Transport

如果光只在真空中传播，碰到表面才发生散射，那么 Rendering Equation 已经可以描述大量问题。

但现实中光也会在空间中与物质作用。

例如：

Fog
Smoke
Cloud
Atmosphere
Dust
Water

这些物质统称为：

Participating Media

光经过它们时可能：

Absorption
Out-scattering
In-scattering
Emission

于是需要更加一般的：

Radiative Transfer Equation / Equation of Transfer

PBRT 将 Rendering Equation 看作没有 Participating Media 时，对更一般体积光传输问题的一种特殊情况。⁵

所以知识结构更准确地是：

Loading diagram…

这比把所有东西都强行塞进 Rendering Equation 更清楚。

5.2大气散射：蓝天、日落与高空大气层

从太空观察一颗拥有大气的行星时，边缘会出现一层非常薄的蓝色或红橙色光晕。

这不是一个人为绘制的 Gradient。

它来自：

太阳光在大气中的吸收与散射。

体积介质中常见一个重要关系：

\sigma_t = \sigma_a+\sigma_s

其中：

$\sigma_a$ ：Absorption Coefficient
$\sigma_s$ ：Scattering Coefficient
$\sigma_t$ ：Extinction Coefficient

光沿路径传播时会不断衰减。

一个简化的 Transmittance 可以写成：

T(a,b) = e^{-\int_a^b \sigma_t(s)\,ds}

但与此同时，大气中其他方向的光又可能被散射进当前视线。

所以：

Sunlight
   ↓
Atmosphere
 ↙ ↓ ↘
Scattering
   ↓
Camera

5.2.1Rayleigh Scattering

对于远小于可见光波长的粒子，例如空气分子，常用 Rayleigh Scattering 描述。

其散射强度具有近似：

\propto\frac{1}{\lambda^4}

短波长的蓝光比长波长红光更容易被散射。

因此白天从各个方向进入眼睛的散射光中蓝色成分更多：

天空看起来是蓝色。

5.2.2为什么日落会变红

当太阳接近地平线时：

Sun ─────────────────→ Camera
        long atmosphere path

光需要穿越更长的大气距离。

大量短波长成分被沿途散射出去。

最终直接到达观察者的光中：

红色、橙色等较长波长比例更高。

所以出现：

Red Sunset
Orange Horizon
Planet Atmosphere Rim

Bruneton 与 Neyret 的经典实时大气散射工作就通过预计算包含 Rayleigh、Mie 以及多次散射的光传输，实现从地面一直观察到太空尺度的大气效果。⁶

5.3雾、烟与体积云

体积云也不是普通 Mesh Surface。

Camera Ray 实际会进入一个拥有连续密度变化的体积：

Camera
  ↓
  ↓
[ Cloud Volume ]
  ↓ scatter
  ↓ scatter
  ↓ absorb
  ↓
Exit

Renderer 需要知道：

这个位置的密度是多少？

通常可以写成：

\rho(x)

然后得到对应：

Absorption
Scattering
Extinction

还需要 Phase Function：

p(\omega_i,\omega_o)

描述：

光被介质粒子散射以后，更倾向于朝哪个方向传播？

云、水雾、气溶胶通常具有明显的 Forward Scattering，所以太阳附近会出现很强的亮边与银边。

完整 Volumetric Path Tracing 可以自然处理这些现象，但对于游戏来说仍然极其昂贵。

因此实时体积云通常又会使用：

Ray Marching
Low-resolution Volume
Temporal Reprojection
History Accumulation
Precomputed Scattering
Approximate Multiple Scattering

也就是说，同样的历史再次发生：

真实 Volume Light Transport
          ↓ 太贵
Realtime Approximation

5.4Camera 与 Lens：Depth of Field 和 Motion Blur

还有一些效果甚至不是 Light Transport 本身，而是：

Camera 如何观察这些光。

最简单的 Pinhole Camera：

Scene
 \ | /
  \|/
   ●
   |
 Sensor

所有光都经过无限小的针孔，因此理论上不会产生真实镜头的景深。

真实相机的 Aperture 有面积：

Scene
 \   |   /
  \  |  /
   [Lens]
   \ | /
    \|/
   Sensor

Path Tracer 可以在 Lens Aperture 上随机选择采样点。

于是 Depth of Field 自然出现。

所以：

Path Tracing 可以生成 DOF，但 DOF 不是表面 Rendering Equation 本身描述的现象。

它来自 Camera Model。

Motion Blur 类似。

真实 Camera 的快门有一个曝光时间区间：

[t_0,t_1]

如果物体在这段时间运动，最终 Pixel 实际上是在时间上的积分。

Path Tracer 可以随机采样：

t\sim[t_0,t_1]

然后查询这个时刻的场景。

于是产生物理意义上的 Motion Blur。

5.5Sensor、Exposure、Tone Mapping 与 Bloom

即使我们已经计算得到非常准确的 Scene Radiance：

图片依然还没有结束。

因为真实相机和显示设备都不是无限动态范围系统。

完整流程可能是：

Loading diagram…

因此一些常见效果的位置是：

效果	更主要属于
GI	Surface Light Transport
Reflection	Surface Light Transport
Refraction	Surface / BSDF
Atmosphere	Volume Transport
Fog	Volume Transport
Cloud	Volume Transport
Depth of Field	Camera / Lens
Motion Blur	Camera + Time
Exposure	Camera / Sensor
Bloom	Lens / Sensor / Post Process
Tone Mapping	Image / Display Mapping
Color Grading	Post Processing
Film Grain	Film / Sensor Simulation

Bloom 尤其值得注意。

真实强光在镜头、Sensor 或 Film 中可能产生能量扩散，但游戏中的 Bloom 往往是：

从 HDR Image 中提取高亮区域，再进行 Blur 和 Composite。

所以一个视觉效果完全可以：

有真实物理来源，但使用一个后处理近似算法实现。

5.6从 Rendering Equation 提升到完整的 Image Formation

因此，如果要建立一张真正完整的知识地图，最高层不应该是：

Rendering Equation

而应该是：

Image Formation
│
├── Light Transport
│   │
│   ├── Surface Transport
│   │   └── Rendering Equation
│   │
│   └── Volume Transport
│       └── Radiative Transfer
│
├── Camera
│   ├── Lens
│   ├── Aperture
│   └── Shutter
│
├── Sensor
│   ├── Exposure
│   └── Response
│
└── Display / Post
    ├── Tone Mapping
    ├── Bloom
    └── Color Grading

Rendering Equation 很重要，但不要把它神化成“整个 Renderer 的唯一方程”。

它真正重要的地方，是它让我们第一次能够从一个统一的 Light Transport 视角理解大量表面光照现象。

6物理真实之后：实时渲染与风格化渲染

6.1物理光传输并不意味着只能追求照片级真实

一个很自然的问题是：

如果 Renderer 越来越物理正确，它是不是只能产生照片一样的画面？

并不是。

这里必须区分两件事：

光从哪里来
艺术家希望材质怎样回应这些光

第一件事可以非常物理。

第二件事完全可以风格化。

例如一个 Anime Character 依然可以接受：

真实太阳方向
真实 Shadow Visibility
真实环境间接光
真实 Reflection Environment
真实大气
真实 Volumetric Lighting

但在最终 Shading 阶段，把连续光照重新映射成艺术化结果。

6.2PBR 与 NPR 为什么可以共存

传统认知容易把：

PBR

和：

NPR

理解成两个互斥阵营。

实际上它们回答的问题并不完全相同。

PBR 更强调：

材质与光之间的响应应该满足合理的物理约束。

NPR：

Non-Photorealistic Rendering

更强调：

最终画面是否符合某种艺术语言。

因此完全可以构造：

Physical Visibility
+
Physical GI
+
Physical Atmosphere
+
Stylized Character Shading

例如环境使用：

GGX
Metallic/Roughness
Physical Reflection

角色使用：

Lighting Ramp
Face SDF
Stylized Specular
Hair Highlight
Rim Light
Outline

最终形成一种：

真实世界中的风格化角色

这样的混合视觉。

6.3Stylized BRDF、Ramp、Face Shading 与 Hair Shading

假设真实光照计算得到：

N\cdot L = 0.37

物理 Lambert Shading 会连续响应这个数值：

L_d\propto0.37

但 Toon Shader 可以人为进行量化：

R(x) = \begin{cases} C_\text{shadow}, & x<t \\ C_\text{light}, & x\ge t \end{cases}

于是：

Physical Lighting

0 ---------------------------- 1
             0.37

             ↓ Ramp

Shadow Color │ Light Color
-------------│--------------
             t

真实世界给出：

光来自哪里、有多强、有没有被挡住。

而风格化 Shader 决定：

我们如何把这些信息解释成最终画面。

Face SDF 更进一步。

Anime Face 往往不希望使用普通 Normal Lighting，因为鼻梁、眼窝、面部拓扑产生的真实明暗可能破坏二维设计感。

于是可以根据：

Light Direction
Face Orientation
SDF Texture

人为控制脸部阴影边界。

这已经不是严格的物理 BSDF。

但这并不妨碍整个世界其他部分继续使用物理 Light Transport。

6.4“真实世界 + 风格化角色”的混合 Renderer

如果目标是类似半写实二次元的视觉方向，一个很有吸引力的架构是：

Loading diagram…

这种方案的核心思想可以浓缩成一句话：

光从哪里来，可以服从物理；角色如何回应这些光，可以服从艺术。

这也解释了为什么：

使用 Path Tracing、Ray Traced GI 或真实大气，并不意味着必须放弃 Anime / Stylized Rendering。

物理正确不是美术风格。

它只是提供了一套稳定、一致的世界光照基础。

艺术家依然可以选择：

在什么地方遵守现实，在什么地方故意背离现实。

6.5这些理论今天实际用在哪里

Rendering Equation 和 Path Tracing 并不是停留在论文里的理论。

现代生产 Renderer 已经大量建立在 Monte Carlo Light Transport 上。

类别	代表	意义
DCC / Offline	Blender Cycles	Production physically-based path tracer
电影动画	Disney Hyperion	Disney Animation 自研 physically-based path tracer
电影 / VFX	Pixar RenderMan	从 REYES 逐步转向 RIS Path Tracing，并进一步进入 XPU
游戏引擎	Unreal Engine Path Tracer	用于高质量输出与实时 Renderer 的 Ground Truth 对照
实时游戏	Minecraft with RTX	统一 Path-Traced Lighting 的代表案例
实时游戏	Cyberpunk 2077 等	展示现代 Hybrid / Path-Traced Lighting 的发展方向
实验 Renderer	Kajiya	Rust + Vulkan 的实时 GI 实验项目

Blender 官方将 Cycles 定义为用于生产渲染的 Physically Based Path Tracer。⁷

Disney Animation 的 Hyperion 同样是一套内部 Physically Based Path Tracer，通过追踪光在虚拟场景中的多次传播生成最终电影画面。⁸

Pixar RenderMan 的历史则很好地反映了整个行业的发展：

REYES
  ↓
Hybrid Ray Tracing
  ↓
RIS Full Path Tracing
  ↓
XPU CPU + GPU Production Rendering

早期硬件无法承担大量 Ray Tracing，因此 REYES 通过各种聪明方法绕过完整光传输；随着计算能力提高，RenderMan 逐步转向 Monte Carlo Path Tracing。⁹

Unreal Engine 的 Path Tracer 甚至明确承担了一个很有意思的角色：

Ground Truth Reference

也就是：

Path Tracer
    ↓
高质量参考答案

Realtime Renderer
    ↓
Lumen / RT / Raster Approximation

开发者可以用更加完整的 Path-Traced Result 判断：

实时 Renderer 离目标结果还有多远。¹⁰

另一个有趣例子是 Rust + Vulkan 项目 Kajiya。

它的目标不是暴力实现一个游戏级完整 Path Tracer，而是尝试：

在动态场景中，以实时速度尽可能接近 Path-Traced Reference。

因此它同时包含 Rasterization、Ray Tracing、GI Cache 和 Reference Path Tracer，是观察：

Ground Truth 与 Realtime Approximation

之间关系的非常直观案例。

该实验项目目前已经停止维护并归档。¹¹

7结语：不要模拟效果，要理解产生效果的原因

学习实时渲染时，很容易形成这样一张知识表：

Shadow Map
SSAO
SSR
Lightmap
Reflection Probe
RTGI
Volumetric Fog
DOF
Bloom
...

然后开始逐个学习：

这个效果怎么实现？

这些知识当然重要。

但 Rendering Equation 带来的真正价值，是让我们退后一步重新问：

它为什么会存在？

Shadow 不是因为 Renderer 有一个 Shadow Pass。

Reflection 不是因为我们写了 SSR。

Color Bleeding 不是因为我们增加了一个 GI Feature。

它们首先来自：

光在世界中的传播。

Rendering Equation 把大量表面光传输现象放进了一个统一框架：

\boxed{ L_o = L_e + \text{Scattered Incoming Radiance} }

Path Tracing 再利用 Monte Carlo 方法去估计这个难以解析求解的积分。

Ray Tracing 则提供：

一条 Ray 究竟撞到了什么？

这样的底层场景查询能力。

于是：

Loading diagram…

这也给出了理解现代 Renderer 更有用的一套层级：

\boxed{ \text{Image Formation} \supset \text{Light Transport} \supset \text{Surface / Volume Transport} }

Rendering Equation 是其中极其重要的一块，但不是全部。

而实时图形学过去几十年的许多历史，也可以从一个非常简单的矛盾来理解：

我们一直知道自己真正想算什么，只是过去算不起。

于是出现 Shadow Map、Lightmap、Probe、SSAO、SSR，以及无数聪明的近似。

随着 GPU、Hardware Ray Tracing、Sampling、Denoising 和 Reconstruction 不断发展，实时 Renderer 又逐渐开始靠近那个最原始的问题：

如果真的让光在这个世界里传播，摄像机最终应该看到什么？

这可能才是 Rendering Equation 留给现代计算机图形学最重要的思想。

James T. Kajiya, The Rendering Equation, SIGGRAPH 1986, pp. 143–150, DOI: 10.1145/15886.15902. ↩
Matt Pharr, Wenzel Jakob, Greg Humphreys, Physically Based Rendering: From Theory to Implementation, 4th Edition, Chapter 13: Light Transport I — Surface Reflection. ↩
Physically Based Rendering: From Theory to Implementation, 4th Edition, System Overview. PBRT 使用 Monte Carlo 数值方法估计无法闭式求解的 Light Transport Equation。 ↩
NVIDIA / Microsoft / Mojang, Minecraft with RTX. 该实现以 Path Tracing 统一直接光照、阴影、GI、反射、折射等多类实时光照效果。 ↩
Physically Based Rendering: From Theory to Implementation, 4th Edition, Chapter 14: Light Transport II — Volume Rendering. Equation of Transfer 将表面光传输推广到 Participating Media。 ↩
Eric Bruneton, Fabrice Neyret, Precomputed Atmospheric Scattering, Computer Graphics Forum 27(4), 2008, DOI: 10.1111/j.1467-8659.2008.01245.x. ↩
Blender Manual, Cycles. Blender 官方将 Cycles 定义为用于生产渲染的 Physically-Based Path Tracer。 ↩
Walt Disney Animation Studios, Disney's Hyperion Renderer. Hyperion 是 Disney Animation 自研的 Physically-Based Path Tracer。 ↩
Pixar RenderMan, The Evolution of RenderMan. RenderMan 从 REYES、Hybrid Ray Tracing 演进至 RIS Full Path Tracing，并继续发展到 XPU。 ↩
Epic Games, Path Tracer in Unreal Engine. Unreal Path Tracer 用于高质量 Production Rendering，也可作为实时渲染结果的 Ground Truth Comparison。 ↩
EmbarkStudios/kajiya, Experimental real-time global illumination renderer made with Rust and Vulkan. 项目目标是在动态场景中以实时速度接近 Path-Traced Reference，目前已归档。 ↩

从渲染方程到路径追踪：现代真实感渲染的统一框架

沿着这篇文章继续

On this page