每像素每帧只追踪一条或少量路径时，Monte Carlo 光照估计可能在相邻像素之间剧烈变化：一个样本恰好命中光源，另一个样本没有获得贡献。直接做大范围模糊会抹掉阴影和反射细节，只做时间累积又会遇到显露、运动和光照变化。SVGF（Spatiotemporal Variance-Guided Filtering）把两者连接起来：先复用可信历史，再估计亮度的不确定程度，用它控制不同尺度上的空间滤波。
SVGF 是低采样光照的重建滤波器，不是新的光照积分算法。射线如何生成、BRDF 如何采样、可见性如何查询，仍由上游渲染器负责；滤波器通过共享时空样本降低可见噪声，同时引入需要控制的偏差。原始工作由 Schied 等人在 HPG 2017 发表，重点面向每像素一条路径的实时重建。NVIDIA Research 论文页
这是一个围绕 Voxel-based Global Illumination 的实现型系列。文章从全局光照与体素场景表示出发，逐步建立 Compute Shader 体素化、体素光照注入、Voxel Cone Tracing、Screen Trace、时空滤波和合成的完整认知，并把这些概念落到 Unity 6 的 URP Render Graph 数据流上。
com.qstx.voxelgi 0.1.0d5a0253915a4094b1db1e804b394ff9dee619836Packages/com.qstx.voxelgiPackages/com.qstx.voxelgi/Samples/SampleScene/SampleScene.unity本文只建立 Voxel GI 的管线视图：场景数据怎样进入体素场，辐射结果怎样被屏幕查询，以及 Render Graph 怎样表达这些阶段的依赖。体素坐标、三角形写入、Cone 采样和滤波细节留给后续文章。
本文建立 Voxel GI 的空间与数据契约：先区分相机影响范围和体素化范围，再定义体素网格、坐标变换、体素中心与 3D UV，最后说明 3D GBuffer 的通道语义和分辨率约束。所有公式对应当前插件的体素空间约定。
体素化最容易混淆的是两个范围。VoxelGIVolume 挂载对象上的 Collider 是相机影响区：相机在区域内时才启用 GI；独立 GameObject 上的 Voxelization Bounds 才提供体素网格覆盖的世界空间。前者控制“何时生效”，后者控制“写入哪里”。
体素空间与 3D GBuffer 定义了数据应该存在哪里；本篇处理另一半问题：如何把 Unity 场景中的 Renderer、网格和材质转换为对三维网格的并发写入。当前实现不要求材质额外提供 Voxelization Pass，而是由 Compute Shader 读取 Raw Vertex/Index Buffer，按三角形覆盖范围写入原子累积 Buffer，最后 Resolve 成浮点 3D GBuffer。
贯穿本篇的例子是一只代表性三角形 △T。它属于一个同时带有 MeshRenderer、材质和世界变换的对象；在 Renderer 阶段，△T 还只是 Registry 快照中的候选几何，先要和它所在 Renderer 一起通过状态、LayerMask、Bounds、SubMesh 与 Render Queue 过滤。
体素化结束后，规则网格里已经有了表面属性，但这些属性还不是光。本篇把边界收在 DirectRadiance：从 AlbedoOpacity、Normal、独立 Emissive 和方向光阴影开始，说明项目如何得到“自发光 + 当前方向光直射”的体素辐射结果。后续辐射查询所需的其他阶段不在本文展开。
体素阶段的 Resolve 结果提供三个输入 3D 纹理：AlbedoOpacity 的 RGB 是表面反照率、A 是占用/遮挡；Normal 的 RGB 是编码到 0–1 的世界法线、A 复用占用值；Emissive 的 RGB 是独立的 HDR 自发光。它们描述“这里有什么表面”，而不是“这里已经收到多少光”。
方向光和自发光已经写入 DirectRadiance，但一个体素表面接收的间接光仍然需要从周围体素查询。当前实现不沿单一细线发射大量 Ray，而是用有限数量的 Cone 覆盖法线半球：距离增加时采样足迹变宽，同时选择更粗的 Radiance Mip，把半球积分压缩为空间层级上的若干次查询。indirectConeAngle 表示 Cone 角度（全角），Shader 在正切公式中使用它的半角 。
Voxel Cone Tracing 把辐射写进了三维体素场，但最终要为每一个屏幕像素找到自己的查询起点。Screen Trace 将相机的深度和法线还原为表面点，再把该点送入体素空间，沿法线半球发射 Cone，读取当前可用的 Radiance。它连接的是“屏幕上看见的表面”和“屏幕外仍然存在的体素辐射”，输出仍是一张屏幕空间间接光纹理。
RecordRenderGraph 只在 cameraDepthTexture 和 cameraNormalsTexture 都有效时登记 Screen Trace。Pass 读取当前相机的 Radiance 3D 纹理和可选蓝噪声，写入与相机颜色同尺寸的 Screen Trace 纹理；执行函数用全屏三角形调用 VoxelGI_ScreenTraceFragment。
Screen Trace 每个像素只用有限条 Cone 和有限步数查询 Radiance。为了让预算可控，方向和步进必须抖动，结果也就带有单帧噪声；若直接把它叠到相机颜色上，会看到颗粒、闪烁和随视角变化的亮度跳动。本篇按当前 Render Graph 中的顺序说明：先得到当前帧结果，再用 Motion Vector 找回历史，用 YCoCg 邻域统计限制异常历史，之后可选地做深度/法线双边滤波，最后和场景颜色合成。
Screen Trace 的噪声来自离散的空间积分，而不是材质颜色本身。每个像素只追踪有限条 Cone，每条 Cone 又只走有限步；半球方向、首步偏移和蓝噪声/哈希会让相邻像素看到不同的 Radiance 足迹。Cone 数量越少，单帧误差越明显，但当前实现仍会把结果写成一张完整的屏幕纹理，供后续阶段读取。
核心问题
为什么现代游戏画面看起来越来越"真实"？为什么不同光照环境下，同一把枪看起来都像是用同一种金属做的？答案就是 PBR——基于物理的渲染。
传统经验光照模型（如 Phong/Blinn-Phong）靠美术调参凑效果，换个光照环境就穿帮。PBR 的目标是：
用物理规律（能量守恒、菲涅尔效应、微表面理论）描述光与材质的交互，让材质在任何光照下都表现一致、可信，参数也符合物理直觉（金属度、粗糙度）。