Lightmapping 全流程精讲：从 UV 展开到烘焙参数的独立游戏实战标准
光照贴图 UV 生成策略 · Texel Density 计算 · 烘焙引擎选型 · 独立游戏 TOP10 故障排查
烘焙光照贴图（Lightmapping）是独立游戏开发者最强大的视觉工具之一。它能在几乎不计运行时性能代价的前提下，为静态场景提供高质量的全局光照效果。但烘焙的「入门门槛」远低于「精通门槛」——大多数开发者能在 30 分钟内完成第一次烘焙，却可能在接下来的三个月里反复与接缝、漏光和烘焙时间长这三个问题缠斗。
本文从工程化视角出发，建立从 UV 展开到烘焙参数选型的完整工作流标准。无论你使用 Progressive Lightmapper 还是第三方方案，核心逻辑是一致的：理解 Texel Density 的物理意义，就掌握了 Lightmap 烘焙的决策权。
Lightmap UV 展开策略：自动生成 vs 手动展开
Lightmap 烘焙要求每个物体拥有独立且不重叠的第二套 UV 坐标（通常称为 UV2 或 Lightmap UV）。这套 UV 的排布质量直接决定了烘焙结果的精度和正确性。
自动生成：Unity 内置的自动 UV 展开算法在大多数标准几何体上表现良好。它具备以下控制参数：
| 参数 | 推荐值 | 过低的后果 | 过高的后果 |
|---|---|---|---|
| Pack Margin | 4–8（Texel 为单位） | 相邻 UV island 间颜色串扰 | Atlas 利用率下降，内存浪费 |
| Angle Error | 8–15° | UV island 数量过多，排列效率低 | 弯曲表面的接缝风险增加 |
| Area Error | 5–10 | UV 面积分配不合理 | 小面积 UV island 精度浪费 |
手动展开：对于角色、道具等视觉敏感物体，建议在 Blender 或 Maya 中手动展 UV。手动展开的核心优势在于：可以精确控制切线接缝的位置（藏在模型结构线或摄像机构图看不到的区域），以及按需为不同区域分配不同的 Texel 密度（面部精细、背部粗略）。
判断标准：如果一个物体的视觉重要性高（主角、关键道具）或具有复杂的曲面结构，手动展开的投入是值得的。对于场景中的基础构件（墙体、地板、大块岩石），自动生成即可。
Lightmap Resolution 与 Texel Density 的工程关系
Texel Density（纹素密度）是 Lightmap 烘焙中最核心但也最容易被忽视的指标。它定义了场景中每单位世界距离被多少像素覆盖。单位通常为 pixels per meter（ppm）。
计算公式极为简单：Texel Density = Lightmap Resolution / (场景世界尺寸 × Object Scale Factor)，但其工程影响贯穿始终：
- 精度不足：阴影边界模糊、小尺寸物体光照细节完全丢失
- 精度过高：Lightmap Atlas 尺寸膨胀，内存超限，移动端尤其敏感
独立游戏推荐基线：
| 目标平台 | 推荐 Texel Density | 对应 Lightmap Resolution（100m 场景） |
|---|---|---|
| PC 写实 | 20–40 ppm | 2048–4096 |
| PC 风格化 | 10–20 ppm | 1024–2048 |
| 移动端 | 5–10 ppm | 512–1024 |
| WebGL | 4–8 ppm | 256–512 |
这些数值不是绝对的，而是意味着：如果一个 100 米见方的场景以 1024 分辨率烘焙，其 Texel Density 约为 10 ppm——在 PC 风格化游戏中可以接受，但在 PC 写实游戏中就需要提升到 2048 或 4096。
烘焙引擎选型：Progressive GPU vs CPU Lightmapper
Unity 当前提供了两种内置的 Progressive Lightmapper，它们在底层算法、性能和适用场景上有本质差异：
GPU Lightmapper：利用 GPU 的计算着色器（Compute Shader）执行路径追踪。在 NVIDIA RTX 显卡上可以借助 Tensor Core 加速 Denoising。单帧采样速度极高，通常在几分钟到半小时内完成中小型场景的烘焙。限制在于 VRAM 容量——光照贴图数据需要在 GPU 显存中处理，对于大型开放世界场景可能遇到显存溢出。
CPU Lightmapper：在 CPU 上执行纯路径追踪。速度较慢（通常需要数小时），但稳定性和可控性更高。优势是可以处理超出 GPU 显存限制的大型场景，且烘焙过程中系统仍然可进行其他轻量操作。独立开发者的优势在于：可以在睡前启动 CPU 烘焙，第二天早上查看结果。
选择决策：如果你的场景在 1024-2048 分辨率下可被 GPU 显存容纳，优先选择 GPU Lightmapper——迭代反馈快，有利于快速调整参数。当场景规模超过四张 2048 分辨率 Lightmap，或遇到 GPU 驱动导致的崩溃问题时，切换到 CPU Lightmapper 作为稳定保底方案。
Lightmap Atlas 打包策略与内存管理
每次烘焙都会生成一组 Lightmap Atlas（贴图集），这些 Atlas 需要常驻 GPU 内存。在大型独立游戏项目中，Lightmap 可能是除纹理资源外最大的内存消费者。
Atlas 分组逻辑：将场景按区域分区，每个区域独立烘焙，共享同一个 Atlas 同一区域内的物体应被打包在一起。这不仅是组织上的便利，更是运行时内存管理的基石——玩家进入新区域时只需加载该区域的 Atlas，而不是整个场景的万亿像素数据。
压缩格式选型：
| 格式 | 压缩比 | 画质 | 平台 |
|---|---|---|---|
| BC6H | 6:1 | 高（支持 HDR） | PC、Xbox、PS |
| BC7 | 6:1 | 高（仅 LDR） | PC、Xbox、PS |
| ETC2 | 6:1 | 中高 | Android（GLES 3.0+） |
| ASTC 4×4 | 4:1 | 中高 | iOS、高端 Android |
| ASTC 8×8 | 16:1 | 中 | 低端移动设备 |
注意：HDR Lightmap 必须使用支持 HDR 的压缩格式（如 BC6H），使用 LDR 格式会导致光照动态范围严重损失。
独立游戏烘焙故障 TOP10 与解决路径
- UV Island 间颜色串扰：提高 Pack Margin。如果已经烘焙完成，唯一的修复路径是修正 UV 后重新烘焙。
- 光照接缝（Light Seam）：检查 UV 接缝是否落在几何体的硬边角上。将其移动到相对平坦的区域可以显著减少接缝可视度。
- 烘焙时间过长：降低 Sample Count 到 500-1000 进行初步预览，确定光照布局后再提升到 2000-3000 出最终品质。
- 大面积噪点：提升 Sample Count 或启用 Denoising。GPU Lightmapper 的 AI Denoiser 在 500 Samples 下能达到接近 2000 Samples 的无噪点效果。
- 漏光（Light Leak）：检查场景几何体的封闭性。地表模型之间的微小缝隙是漏光的最常见来源。
- 动态物体与静态物体光照不匹配：由 Light Probe 插值位置不当引起。在静态物体与动态物体交界处增加探针密度。
- GPU 烘焙崩溃：通常是显存不足导致。降低 Lightmap Resolution 或将引擎切换为 CPU Lightmapper。
- 方向性 Lightmap 的视觉问题：Directional Lightmap 开启后内存翻倍。仅在需要法线贴图响应阴影细节时启用。
- Lightmap 压缩伪影：ETC2 在低对比度区域可能出现色块。测试阶段不要开启压缩，最终发布前再启用。
- 烘焙结果与编辑器预览不一致：检查 Color Space 是否设置为 Linear（而不是 Gamma），这是独立的游戏中最常见的配置错误。
多场景（Multi-Scene）环境下的光照数据组织
当独立游戏项目规模增长到需要多个 Scene 文件时，光照数据的管理复杂度急剧上升。每个 Scene 拥有独立的 Lighting Settings Asset，这意味着跨 Scene 的光照一致性需要手动维护。
推荐的工程实践是：创建一个专用的 Lighting Scene，其中只包含光照相关的游戏对象（Directional Light、Light Probe Group、Reflection Probe）和覆盖全场景的不可见静态触发器网格。将这个 Lighting Scene 在所有其他 Scene 加载之前 Additive 加载，确保全场景共享同一套光照设置。
这种「光照主权分离」的架构在社区中被称为 Lighting Scene 模式，虽然增加了一些 Scene 管理复杂度，但它彻底消除了跨场景光照不一致的问题，对于 5 个以上 Scene 的项目来说几乎是必须采用的方案。