在 Windows 上用 fxc 编译 shader，默认会把调试信息嵌进 shader 二进制里，包体会因此变大。可以用 fxc /Qstrip_debug 剥掉调试信息，但这样一来 RenderDoc 里就没法调试了。这篇讲怎么两全：把调试信息单独导出成 pdb，剥离后的二进制照常发布，同时让 RenderDoc 仍能加载到调试信息。

原理

1. 在 RenderDoc 里设置 shader 调试信息的搜索路径；
2. 给剥离后的 shader 二进制写一段特殊的 private data，告诉 RenderDoc 对应的 pdb 在哪。

这是一篇调试记录：某主机平台上点光源阴影渲染莫名变得极慢、还伴随显示破损，最后查出根因是 Vertex Shader 的输出结构和 Geometry Shader 的输入结构不匹配，导致 GS 阶段生成了大量无效图元。方法本身和平台无关，记下来当案例。

问题表现

特定区域 GPU 消耗异常升高、帧率明显下降。GPU trace 显示瓶颈在渲染点光源（PointLight）ShadowMap 上——渲染某个角色风格体时单这一项就超过 50ms，而在另一台对照主机平台上同样的内容只花 1ms。两台平台跑同一套引擎和 shader，50 倍差距明显不正常。

现实里没有真正的「点」光源，所有光都有形状——灯泡、灯管、窗户。点光源（punctual light）对图形学很友好，一个位置加一个强度就完事，但它并不真实，也拟合不了现实光照。这篇讲两类光源在 PBR 里怎么建模：点光源的衰减处理，以及面积光的几种主流近似。

点光源：给平方衰减加个窗

真实光照强度按距离平方衰减：

问题是这个函数永远到不了 0。渲染时我们负担不起「每个光源影响全场」的开销，需要一个明确的作用半径，超出就不算。

常见做法是给衰减函数加窗（windowed falloff）：让美术指定一个半径 r，光强在 r 处平滑归零，而大部分区间的形状保持不变。UE4 用的窗函数是：

这一系列记录 UE 渲染相关的原理和源码阅读笔记，聚焦引擎侧的实现细节。

目录

• UE 后处理管线解析 — AddPostProcessingPasses 完整 Pass 顺序、PassSequence 防错、Gamma/线性空间、ToneMapping 四代演进、自定义后处理 Pass 编写
• Nanite 虚拟几何体原理与工程实践 — Cluster/Cluster Group、BVH 剔除、虚拟内存流送，以及形变动画/半透明/TSR 等一堆落地限制
• UE4 默认光照材质：GBuffer 参数与 StandardShading — default lit 的 GBuffer 换算与 StandardShading 核心 HLSL 逐行拆解

Nanite 是 UE5 的虚拟几何体系统，它用一套全新的方式存储和渲染网格：导入时把网格拆成分层的三角形群集（Cluster），渲染时按摄像机视图动态切换 LOD、按需流送数据，只把可见细节留在内存里。它跑在自己的渲染通道里，完全绕过传统 draw call。这篇讲清楚它的三个核心思想和一堆落地时会撞上的限制。

核心思想一：Cluster + 一个 DC 画整个场景

思路可以追溯到《刺客信条：大革命》，后来发展成 Cluster based render pipeline 的最佳实践：把可见 Instance、可见 Cluster、可见 triangle 打包进一个超大的 Index Buffer（Index Buffer Compaction），然后用一个 draw call 渲染整个场景。这是 GPU Driven Pipeline 的基础。

Blinn-Phong 那套经验模型不满足能量守恒，也拟合不了金属，所以现代渲染转向了 PBR。而在众多 PBR 材质模型里，Disney 在 SIGGRAPH 2012 的《Physically Based Shading at Disney》影响最深——UE4、Unity 的标准材质都能看到它的影子。

RenderMan 21 里的材质模型和 2012 那版已经差别不小，这里只谈 2012 的原版。有一点要先讲清：Disney BRDF 的出发点是「艺术家可控」（art directable），而不是「严格物理正确」。它宁可牺牲一点物理准确度，换来一组好调、可预测的参数。