本文建立 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 数量越少，单帧误差越明显，但当前实现仍会把结果写成一张完整的屏幕纹理，供后续阶段读取。
