这是一个围绕 Voxel-based Global Illumination 的实现型系列。文章从全局光照与体素场景表示出发，逐步建立 Compute Shader 体素化、体素光照注入、Voxel Cone Tracing、Screen Trace、时空滤波和合成的完整认知，并把这些概念落到 Unity 6 的 URP Render Graph 数据流上。
Packages/com.qstx.voxelgi本文是系列的入口：先说明全局光照要解决什么问题，再说明为什么用有限体素场景表示承载间接光，最后把一帧中的数据阶段和 Render Graph 的调度关系串起来。这里保留总体认知，体素写入、光照采样和滤波的实现细节分别由后续文章展开。
渲染方程可以写成出射辐射亮度：
本文建立 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。
体素化从 Renderer Registry 的快照开始。它会排除未启用、非活动层级、forceRenderingOff、LayerMask 不匹配、Bounds 与体素立方体不相交的 Renderer；只保留包含三角形 SubMesh、处于 Opaque Render Queue 且允许贡献表面的对象。
体素化结束后，规则网格里已经有了表面属性，但这些属性还不是光。当前实现把 AlbedoOpacity、Normal 和独立的 Emissive 作为材质 GBuffer，把方向光可见性和光照结果写入 DirectRadiance；启用第二次反弹时，再从它得到 FinalRadiance。因此本篇的核心不是“把颜色乘上一个亮度”，而是建立材质数据、阴影空间和辐射资源之间的边界。
体素光照的输入来自上一阶段的 Resolve 结果。AlbedoOpacity 的 RGB 是表面反照率，A 是占用/遮挡值；Normal 的 RGB 是编码到 0–1 的世界法线，A 复用同一占用值；Emissive 的 RGB 是独立的 HDR 自发光，A 仍是占用值。它们描述“这里有什么表面”，而不是“这里已经收到了多少光”。
方向光和自发光已经写入 DirectRadiance，但一个体素表面接收的间接光仍然需要从周围体素查询。当前实现不沿单一细线发射大量 Ray，而是用有限数量的 Cone 覆盖法线半球：距离增加时采样足迹变宽，同时选择更粗的 Radiance Mip，把半球积分压缩为空间层级上的若干次查询。
Ray 是一条理想的零半径路径，每一步只询问一个近似点；Cone 则有一个随距离扩张的截面，代表一簇相邻方向和空间位置。Ray 更接近精确路径，但在体素场中容易受到离散空洞和采样噪声影响；Cone 直接把有限体素分辨率带来的空间平均纳入采样模型。
Voxel Cone Tracing 把辐射写进了三维体素场，但最终要为每一个屏幕像素找到自己的查询起点。Screen Trace 将相机的深度和法线还原为表面点，再把该点送入体素空间，沿法线半球发射若干条 Cone，读取 DirectRadiance 或 FinalRadiance。因此它连接的是“屏幕上看见的表面”和“屏幕外仍然存在的体素辐射”，输出仍是一张屏幕空间间接光纹理。
RecordRenderGraph 只在 cameraDepthTexture 和 cameraNormalsTexture 都有效时登记 Screen Trace。Pass 同时导入当前相机的 Radiance 3D 纹理：启用 SecondBounce 时选 FinalRadiance，否则选 DirectRadiance；蓝噪声纹理也是可选的外部输入。Render Graph 把深度、法线、Radiance 和噪声声明为读，把与相机颜色同尺寸的 Screen Trace 纹理声明为写，执行函数用全屏三角形调用 VoxelGI_ScreenTraceFragment。
Screen Trace 每个像素只用有限条 Cone 和有限步数查询 Radiance。为了让预算可控，方向和步进必须抖动，结果也就带有单帧噪声；若直接把它叠到相机颜色上，会看到颗粒、闪烁和随视角变化的亮度跳动。本篇按当前 Render Graph 中的顺序说明：先得到当前帧结果，再用 Motion Vector 找回历史，用 YCoCg 邻域统计限制异常历史，之后可选地做深度/法线双边滤波，最后和场景颜色合成。
Screen Trace 的噪声来自离散的空间积分，而不是材质颜色本身。每个像素只追踪有限条 Cone，每条 Cone 又只走有限步；半球方向、首步偏移和蓝噪声/哈希会让相邻像素看到不同的 Radiance 足迹。Cone 数量越少，单帧误差越明显，但当前实现仍会把结果写成一张完整的屏幕纹理，供后续阶段读取。
本文整理自视频：《Unity 性能优化》系列课程第零节——项目创建与总览。本文聚焦如何快速认识一个陌生 Unity 项目，以及如何在优化开始前建立可重复、可比较的性能基线。
文中的性能、内存与包体数字均为视频示例项目的优化前观测值，只用于记录该案例的初始状态，不代表 Unity 移动端项目的通用性能预算。
本文整理自视频：《Unity性能优化》第壹节——静态资源优化（1）：Audio 导入设置检查与优化。
本文重点讨论 Unity 音频资源的导入设置、UPR AssetChecker 检查流程，以及如何在内存、CPU、包体和音质之间取得平衡。
文中的检查数量、优化结果和具体阈值均来自视频示例项目。除非特别说明，不应将这些数据理解为 Unity 的通用规则。