1
场景：一个房间，1 个角色模型，20 盏动态灯光
2

3
前向渲染：
4
  角色模型的每个片元 → 对 20 盏灯各做一次光照计算
5
  → 200 万片元 × 20 盏灯 = 4000 万次光照计算
6

7
  而且！如果 10 盏灯被墙挡住了，这些计算白费了
8
  更糟的是——你不知道哪些灯被挡住，因为还没画墙
9

10
延迟渲染：
11
  先画完所有物体（不计算光照，只把属性写进 G-Buffer）
12
  再对屏幕上每个可见像素，统一计算所有灯的光照
13
  → 200 万像素 × 20 盏灯 = 4000 万次
14

15
  等等……次数一样？
16
  不一样——只有最终可见的像素才计算！
17
  被遮挡的片元（在 G-Buffer 写入阶段就被深度测试淘汰了）

1
// Unity Forward Rendering 的光源处理策略
2

3
// 场景中有 50 盏点光源，但每个物体只受最近的 4 盏影响
4
// Unity 会自动排序光源——每帧根据物体位置选出最重要的几盏
5

6
// 光源模式（在 Light 组件上设置）：
7
// Important（像素光）：逐像素计算——最贵，放最重要的光源
8
// Not Important（顶点光）：逐顶点计算——较便宜
9
// Auto：Unity 自动决定
10

11
// 前向渲染的 Pass 结构（Unity Built-in RP）：
12
// ForwardBase Pass:
13
//   - 1 盏方向光（通常是主光源） + 所有逐顶点光 + SH 环境光
14
//   - 这个 Pass 计算环境光和主光
15
//
16
// ForwardAdd Pass（每个额外的逐像素光多一个 Pass）：
17
//   - 额外的逐像素光——每个光源一个 Pass！
18
//   - 这就是"前向渲染光源数 × 物体 DrawCall"的来源
19
//   - Blend One One（叠加混合——把每个光源的贡献累加上去）

1
// 典型的 G-Buffer 布局（4 张 RT）
2
//
3
// RT0 (ARGB32): Albedo.rgb + 保留
4
// RT1 (ARGB32): Normal.xy（Octahedron 编码）+ Roughness + Metallic
5
// RT2 (ARGBHalf): WorldPosition.rgb + 保留
6
// RT3 (ARGB32): AO + 保留 + 保留 + 保留
7

8
// ============ GBuffer Pass 的片元着色器 ============
9
struct GBufferOutput {
10
    float4 albedoRT    : SV_TARGET0;  // RT0: albedo.rgb
11
    float4 normalRT    : SV_TARGET1;  // RT1: normal.xy + roughness + metallic
12
    float4 positionRT  : SV_TARGET2;  // RT2: worldPos.xyz
13
    float4 aoRT        : SV_TARGET3;  // RT3: ao
14
};
15

16
GBufferOutput GBufferPS(VertexOutput input) {
17
    GBufferOutput output;
18

19
    // 采样材质
20
    float3 albedo = SAMPLE_TEXTURE2D(_AlbedoMap, sampler_Albedo, input.uv).rgb;
21
    float metallic = SAMPLE_TEXTURE2D(_MetallicMap, sampler_Metallic, input.uv).r;
22
    float roughness = SAMPLE_TEXTURE2D(_RoughnessMap, sampler_Roughness, input.uv).r;
23
    float ao = SAMPLE_TEXTURE2D(_AOMap, sampler_AO, input.uv).r;
24
    float3 N = GetWorldNormal(input);
25

26
    // 写入 GBuffer——不计算光照！
27
    output.albedoRT = float4(albedo, 1.0);
28

29
    // 法线压缩：Octahedron 编码把 3 分量法线 → 2 分量（省带宽）
30
    float2 encodedNormal = EncodeNormalOctahedron(N);
31
    output.normalRT = float4(encodedNormal, roughness, metallic);
32

33
    output.positionRT = float4(input.worldPos, 1.0);
34
    output.aoRT = float4(ao, 0, 0, 1.0);
35

36
    return output;
37
}
38

39
// ============ Lighting Pass 的片元着色器 ============
40
float4 DeferredLightingPS(float4 screenPos : SV_POSITION) : SV_TARGET {
41
    // 从 G-Buffer 解码
42
    float3 albedo = GBuffer0.Sample(sampler, uv).rgb;
43
    float3 N = DecodeNormalOctahedron(GBuffer1.Sample(sampler, uv).xy);
44
    float roughness = GBuffer1.Sample(sampler, uv).z;
45
    float metallic = GBuffer1.Sample(sampler, uv).w;
46
    float3 worldPos = GBuffer2.Sample(sampler, uv).xyz;
47
    float ao = GBuffer3.Sample(sampler, uv).x;
48

49
    // 重建 View Direction
50
    float3 V = normalize(_WorldSpaceCameraPos - worldPos);
51

52
    // ===== 对每盏灯计算光照（和前向渲染的片元着色器一样）=====
53
    float3 Lo = 0;
54

55
    // 主方向光
56
    Lo += ComputePBRLighting(albedo, N, V, roughness, metallic,
57
                              _MainLightDirection, _MainLightColor);
58

59
    // 额外的点光源——在屏幕空间逐像素计算
60
    for (int i = 0; i < _PointLightCount; i++) {
61
        float3 L = _PointLights[i].position - worldPos;
62
        float dist = length(L);
63
        if (dist < _PointLights[i].range) {
64
            L /= dist;  // normalize
65
            float attenuation = 1.0 - (dist / _PointLights[i].range);
66
            Lo += ComputePBRLighting(albedo, N, V, roughness, metallic,
67
                                      L, _PointLights[i].color) * attenuation;
68
        }
69
    }
70

71
    float3 ambient = albedo * _AmbientColor.rgb * ao;
72
    return float4(Lo + ambient, 1.0);
73
}

1
✅ 优点：
2
  1. 光照计算 O(屏幕像素 × 光源数)——摆脱了物体数的依赖
3
  2. 大量光源场景性能极好——Lighting Pass 只跑一次
4
  3. G-Buffer 可以用于后处理——SSAO/SSR 都需要法线和深度
5
  4. Shader 变体少——光照计算的 Shader 只有一个
6

7
❌ 缺点：
8
  1. 不支持 MSAA——G-Buffer 是屏幕分辨率的，
9
     没有几何信息来做子像素采样（硬件 MSAA 需要知道三角形边界）
10
  2. 透明物体必须额外走 Forward Pass——G-Buffer 只能存一层几何信息
11
  3. G-Buffer 带宽消耗大——4 张 RT，每帧都要写和读
12
     1920×1080 × 4 张 RT × 每张 4 bytes = 33MB 的读写/帧
13
  4. Shader 不灵活——所有物体在 Lighting Pass 里用同一个 Shader 算光照，
14
     不能像前向渲染那样"这个物体用特殊的 Shader"
15
  5. 深度/Stencil 预先写入——不能利用 Early-Z 省掉片元着色器

1
MSAA（多重采样抗锯齿）的原理：
2
  每个像素采样 N 次（4×MSAA = 4 个子像素）
3
  光栅化时判断三角形覆盖了哪些子像素
4
  片元着色器只跑 1 次（颜色共享给所有覆盖的子像素）
5
  解析时：混合 4 个子像素的颜色 → 抗锯齿
6

7
延迟渲染的问题：
8
  G-Buffer 的片元着色器输出的是"几何属性"（法线、粗糙度等），
9
  不是最终颜色。如果做了 MSAA——
10
  G-Buffer 子像素 A 和 子像素 B 可能来自不同的三角形，
11
  法线完全不同。但 Lighting Pass 时用哪个法线？
12

13
解决方案：
14
  1. 不解决——Lighting Pass 后做 FXAA/TAA 等后处理抗锯齿（主流方案）
15
  2. 每个子像素都存一份 G-Buffer——内存 ×4（太贵了，没人这么干）
16
  3. Forward+（见 6.5 节）——保留了前向渲染的 MSAA 支持

1
前向渲染和延迟渲染的折中方案：
2

3
思路：把屏幕分成 Tile（如 32×32 像素的格子）
4
      对每个 Tile，找出影响它的光源
5
      渲染这个 Tile 时，只计算这些光源
6

7
步骤：
8
  1. 深度预渲染（Z-Prepass）→ 得到屏幕的深度信息
9
  2. 光源分类（CPU/Compute Shader）：
10
     对每个 Tile，计算它被哪些灯光影响
11
     只存命中率高的光源索引列表
12
  3. 前向渲染：
13
     每个物体渲染时，根据它覆盖的 Tile，
14
     只算可能影响它的光源而非全场景光源
15

16
优势：
17
  保留了前向渲染的 MSAA + 灵活的 Shader
18
  接近延迟渲染的多光源性能
19
  G-Buffer 带宽开销 ↓
20

21
代价：
22
  需要 Compute Shader 支持（或 CPU 端分 Tile）
23
  光源分类本身有开销

1
"本质区别是光照计算的时机。
2

3
前向渲染在渲染每个物体时，对每盏灯做一次光照计算——
4
光照和几何是耦合的。好处是支持 MSAA、透明物体自然处理、
5
Shader 灵活。坏处是多光源时复杂度 O(N×M)，DrawCall 爆炸，
6
大量被遮挡的片元浪费光照计算。
7

8
延迟渲染分成两个阶段——
9
先画所有不透明物体，把 Albedo/法线/深度/材质参数写入 G-Buffer；
10
再对屏幕每个像素统一算所有灯的光照。
11
好处是多光源开销与物体数无关、G-Buffer 数据可供 SSAO/SSR 等后处理复用。
12
坏处是不支持 MSAA、透明物体必须走额外 Forward Pass、
13
G-Buffer 带宽消耗大（每帧 4+ 张 RT 的读写）、移动端不适用。
14

15
现代方案是 Forward+ / Clustered Forward——
16
在屏幕空间分 Tile/Cluster 管理光源索引，
17
让每个物体/像素只计算可能影响它的光源。"