开场：
在开发大型 3D 项目时，很多新手切换到延迟渲染（Deferred Rendering）管线后会遇到一堆痛点：画面出现莫名其妙的条纹、高光断层，或者在 Profiler 里看到 G-Buffer 的带宽占用高得离谱。面对 Frame Debugger 里那几张花花绿绿的“信息图”，不少人会困惑：这些纹理到底是怎么被片元着色器一行行填满的？尤其是法线信息，稍有不慎就会在光照计算时翻车。今天，我们就把 G-Buffer 的数据填充机制彻底拆解——它不是什么黑魔法，而是一套极其有条理的工程智慧。
一、G-Buffer 是什么：按通道归类的“像素档案”
G-Buffer（Geometry Buffer）是延迟渲染第一阶段（Geometry Pass）的输出目标。要理解它为什么长这样，先回顾延迟渲染的核心约束：光照被推迟到几何之后，而光照时场景 Mesh 已经不在手边了。所以 Geometry Pass 必须把光照所需要的一切“原料”——每个像素处那块可见表面的位置、法线、颜色、材质参数——提前“拍扁”缓存到全屏纹理里，供 Lighting Pass 逐像素读回。
面对“那么多信息怎么塞进图里”的疑问，答案就是按通道拆解归类：漫反射颜色（Albedo）放一张 RT 的 RGB，遮挡（AO）塞进它的 A 通道；法线放另一张 RT；金属度/光滑度（Metallic/Smoothness）、自发光（Emission）各占其位。每张 RT 都是一张全屏纹理，多个像素并行写入，互不干扰。这也正是延迟渲染的优势来源：无论场景中有 10 个还是 100 个光源，Geometry Pass 的开销只与像素覆盖率有关，与灯光数无关。
