Unity预制体光照贴图烘焙：实现动态场景高质量光影的完整方案

1. 项目概述：为什么预制体烘焙是进阶课题？

在Unity项目开发中，尤其是涉及大量重复场景元素（如室内房间、模块化建筑、可组合的道具）时，我们常常会使用预制体（Prefab）来提高效率。然而，当这些预制体需要高质量、真实感的光照效果时，一个棘手的问题就出现了：如何让动态生成的预制体，也能拥有与场景中静态烘焙物体一样细腻、真实的光照贴图（Lightmap）？这就是“预制体烘焙光照贴图”这个进阶课题的核心。

很多开发者，尤其是刚接触光照烘焙的朋友，可能会认为光照贴图是“场景专属”的。他们习惯于在场景编辑器中摆好所有物体，点击“烘焙”，然后得到一个包含了所有静态物体光影信息的贴图集。这个流程对于固定场景是完美的。但是，一旦你的设计变成了“乐高式”的——需要运行时动态组合、生成不同的房间、走廊或建筑模块——传统烘焙流程就立刻失效了。你不可能为运行时可能出现的成千上万种组合，都预先烘焙一个完整场景。

因此，这个项目的目标非常明确：将光照烘焙的成果“封装”进预制体内部。让每一个预制体（比如一个带家具的卧室模块）都自带其独立的光照贴图。这样，无论你在哪个场景、在何时（包括运行时）实例化这个预制体，它都能立刻呈现出正确的烘焙光照效果，无需等待、无需重新计算。这不仅仅是技术实现，更是对项目管线和工作流的深度优化，尤其适用于开放世界、roguelike地牢、模拟建造等需要高度动态环境构建的游戏类型。

2. 核心思路与方案选型：独立烘焙 vs. 场景烘焙

要实现预制体自带光照贴图，主要有两种技术路线，它们各有优劣，选择哪一种取决于你的项目具体需求。

2.1 方案一：独立场景烘焙法（推荐）

这是目前最主流、最稳定的方法。其核心思想是：为需要烘焙的预制体创建一个专属的、独立的、临时的场景文件。

工作流程如下：

1. 创建烘焙场景：在项目中新建一个场景，例如命名为“PrefabBakingScene”。
2. 摆放预制体：将这个预制体实例化到该场景中。注意，这个实例就是我们要烘焙的对象。
3. 配置光照与静态标志：在这个烘焙场景中设置好光照探头（Light Probes）、反射探头（Reflection Probes）以及全局光照（GI）参数。最关键的一步是，确保这个预制体实例的“Static”复选框被勾选（或者至少勾选“Contribute GI”）。这是Unity光照系统识别烘焙对象的依据。
4. 执行烘焙：点击Window -> Rendering -> Lighting，打开光照设置面板，进行光照烘焙。烘焙完成后，Unity会为这个场景生成光照贴图文件（通常位于同名文件夹下）。
5. 提取与关联：烘焙完成后，光照贴图数据会“附着”在这个场景中的预制体实例上。我们需要通过脚本，将这个实例上的光照贴图索引、UV缩放偏移（lightmapScaleOffset）以及关联的光照贴图纹理（lightmapIndex）等信息，提取出来，并保存到预制体资源（Prefab Asset）本身。
6. 清理与复用：保存预制体后，可以关闭或删除这个临时烘焙场景。之后在任何地方实例化这个预制体，它都会自动加载并应用之前保存的光照贴图数据。

为什么推荐这个方案？

• 稳定性高：完全遵循Unity官方的光照烘焙流程，兼容性好，不易出现奇怪的渲染错误。
• 质量可控：可以在一个纯净、独立的环境中为单个预制体精细调整光照参数，不受其他场景物体干扰。
• 流程清晰：易于理解和集成到自动化构建管线（如CI/CD）中。

2.2 方案二：运行时烘焙（动态GI）

Unity提供了动态全局光照（如Enlighten或Progressive GPU/CPU）技术，允许在运行时计算实时光照和间接光照。理论上，你可以将动态生成的预制体标记为“Contribute GI”，然后让Unity的GI系统在运行时为其计算光照。

为什么不推荐作为主要方案？

• 性能开销巨大：运行时烘焙是极其消耗性能的操作，会造成严重的帧率卡顿，完全不适合移动端或需要即时生成大量物体的场景。
• 效果延迟：光照计算需要时间，物体生成后需要等待数帧甚至更久才能看到完整的间接光照效果，体验很差。
• 可控性差：运行时的光照效果受实时环境光源影响大，难以保证与离线烘焙一致的、艺术导向的视觉效果。

因此，对于追求高质量、稳定视觉效果且需要动态生成的项目，方案一（独立场景烘焙法）是几乎唯一可行的工业级解决方案。下文将围绕此方案展开详细实操。

3. 完整实操流程：从预制体到带光照的成品

让我们一步步拆解，如何将一个普通的预制体，变成“自带光影”的进阶预制体。

3.1 第一步：预制体准备与规范

在开始烘焙之前，确保你的预制体符合光照烘焙的基本要求。

1. 模型与UV规范：

   • 第二套UV（UV1）：这是光照贴图使用的UV通道。确保你的模型拥有独立且展开良好的第二套UV。在建模软件（如Maya, 3ds Max, Blender）中完成这项工作。Unity虽然能自动生成光照贴图UV（在模型导入设置中勾选“Generate Lightmap UVs”），但对于复杂模型，手动展开的质量和利用率更高。
   • UV不重叠：光照贴图UV必须不能有重叠，否则烘焙出来的光影会错乱。
   • UV边界间距：各UV岛之间需要留有足够间距（通常2-4个像素），防止烘焙时出现接缝溢色（Bleeding）。

2. 材质与着色器：

   • 确保预制体使用的材质球支持光照贴图。绝大多数Unity内置的标准着色器（Standard, Standard Specular）和通用渲染管线（URP）的Lit着色器都天然支持。
   • 检查材质球是否勾选了“Global Illumination”选项为“Baked”或“Both”。

3. 预制体结构：

   • 将需要一起烘焙的物体（如房间的墙壁、地板、固定家具）作为同一个根预制体的子物体。
   • 如果某些子物体不需要烘焙（如动态角色），确保它们的“Static”标志未被勾选。

3.2 第二步：创建并配置独立烘焙场景

1. 在Project视图中，右键 -> Create -> Scene，命名为“[YourPrefabName]_Bake”，例如“RoomModule_A_Bake”。
2. 打开这个新场景，删除默认的“Main Camera”和“Directional Light”（我们将使用自己的光照设置）。
3. 从Project视图将你的预制体拖入该场景的Hierarchy中。
4. 在Hierarchy中选中该预制体实例，在Inspector面板顶部，勾选“Static”复选框。这会将其所有子物体也标记为Static（用于光照烘焙）。
5. 设置场景光照：
   • 创建一个适合你预制体的光源，比如一个Directional Light模拟日光，或几个Point Light/Spot Light模拟室内灯光。
   • 强烈建议添加Light Probe Group：在场景中右键 -> Light -> Light Probe Group。将光照探头均匀布置在预制体周围的空间中。这对于动态物体（未来进入这个房间的角色）接收正确的间接光照至关重要。
   • 根据需要添加Reflection Probe，以捕获环境反射信息。

3.3 第三步：光照参数设置与烘焙

1. 打开光照设置面板：Window -> Rendering -> Lighting (Unity 2022+ 可能在 Window -> Rendering -> Lighting Settings)。
2. 在Lighting Settings资产中，关键配置如下：
   • Lightmapper：选择“Progressive GPU”（如果硬件支持）或“Progressive CPU”。前者速度更快。
   • Direct Samples/Indirect Samples：控制质量。对于预制体烘焙，可以适当调高（如512/256），因为只烘焙一个物体，时间可接受。
   • Lightmap Resolution：光照贴图分辨率，单位是texels per unit（每单位像素数）。根据预制体大小和所需细节程度设置，室内小物件可能用20-40，大型建筑模块用5-15。这是影响烘焙质量和贴图大小的最关键参数。
   • Lightmap Padding：UV岛之间的间隔像素，防止溢色。通常设为2-4。
   • Compressed：是否压缩光照贴图。勾选以节省磁盘空间，但会轻微损失质量。
   • Ambient Occlusion：环境光遮蔽，强烈建议勾选以增强角落阴影细节。
3. 点击光照设置面板底部的Generate Lighting按钮开始烘焙。等待进度条完成。

注意：烘焙产生的光照贴图文件（*_comp_light.exr,*_comp_dir.png等）默认会保存在与烘焙场景同名的文件夹中。请务必将这个文件夹（例如PrefabBakingScene）移动到项目内一个妥善的位置（如Assets/Art/Lightmaps/），并确保其被包含在版本控制中。

3.4 第四步：关键脚本——将光照数据“烧录”进预制体

烘焙完成后，场景中的预制体实例已经有了光照效果。但现在我们需要把这个效果“固化”到预制体资源里。这需要编写一个编辑器脚本。

// PrefabLightmapBaker.cs // 这是一个Editor脚本，需要放在`Assets/Editor/`文件夹下 using UnityEngine; using UnityEditor; using System.Collections.Generic; public static class PrefabLightmapBaker { [MenuItem("Tools/Bake Prefab Lightmap and Save")] public static void BakeAndSavePrefabLightmap() { // 1. 获取当前场景中选中的物体（假设它就是我们要处理的预制体实例） GameObject selectedGo = Selection.activeGameObject; if (selectedGo == null) { EditorUtility.DisplayDialog("Error", "Please select the prefab instance in the baking scene.", "OK"); return; } // 2. 检查它是否有光照贴图数据 Renderer renderer = selectedGo.GetComponent<Renderer>(); if (renderer == null || !renderer.lightmapIndex.HasValue) { EditorUtility.DisplayDialog("Error", "Selected object does not have valid lightmap data. Please bake the lighting first.", "OK"); return; } // 3. 获取其光照贴图数据 int lightmapIndex = renderer.lightmapIndex.Value; Vector4 lightmapScaleOffset = renderer.lightmapScaleOffset; // 4. 获取该光照贴图对应的纹理资产（需要根据索引从LightmapSettings中查找） // 注意：这里简化处理，假设只有一张光照贴图。实际项目中可能需要处理多张。 Texture2D bakedLightmap = LightmapSettings.lightmaps[lightmapIndex].lightmapColor; // 5. 找到这个预制体对应的原始Prefab资源路径 string prefabPath = PrefabUtility.GetPrefabAssetPathOfNearestInstanceRoot(selectedGo); if (string.IsNullOrEmpty(prefabPath)) { EditorUtility.DisplayDialog("Error", "Selected object is not a prefab instance.", "OK"); return; } // 6. 加载Prefab资源，准备修改 GameObject prefabAsset = PrefabUtility.LoadPrefabContents(prefabPath); // 7. 在Prefab资源上找到对应的Renderer，并为其设置光照贴图数据 // 注意：这里需要根据你的预制体结构找到正确的Renderer，简化起见，我们假设根节点或某个特定子节点 Renderer prefabRenderer = prefabAsset.GetComponentInChildren<Renderer>(); if (prefabRenderer != null) { // 创建一个新的LightmapData LightmapData newLightmapData = new LightmapData(); newLightmapData.lightmapColor = bakedLightmap; // 我们需要将光照贴图纹理作为子资源保存进Prefab，或者引用项目中的纹理 // 更常见的做法是：将烘焙出的光照贴图文件复制到Prefab附近的目录，并建立引用 // 此处演示直接引用场景烘焙生成的纹理（要求纹理文件已存在于项目中） string lightmapAssetPath = AssetDatabase.GetAssetPath(bakedLightmap); if (!string.IsNullOrEmpty(lightmapAssetPath)) { // 将光照贴图索引设置为0（因为我们只关联一张） // 实际索引需要在预制体保存时，与它自身存储的LightmapData数组对应 prefabRenderer.lightmapIndex = 0; prefabRenderer.lightmapScaleOffset = lightmapScaleOffset; // 这里需要一个自定义MonoBehaviour脚本来存储lightmapIndex, scaleOffset和关联的Texture // 例如，给预制体添加一个`PrefabLightmapData`组件 PrefabLightmapData dataComponent = prefabAsset.GetComponent<PrefabLightmapData>(); if (dataComponent == null) dataComponent = prefabAsset.AddComponent<PrefabLightmapData>(); dataComponent.lightmapIndex = 0; dataComponent.lightmapScaleOffset = lightmapScaleOffset; dataComponent.lightmapTex = bakedLightmap; // 存储引用 } } // 8. 保存修改后的Prefab PrefabUtility.SaveAsPrefabAsset(prefabAsset, prefabPath); PrefabUtility.UnloadPrefabContents(prefabAsset); Debug.Log($"Prefab lightmap data saved to: {prefabPath}"); AssetDatabase.Refresh(); } } // 这个组件需要添加到你的预制体上，用于运行时恢复光照贴图数据 public class PrefabLightmapData : MonoBehaviour { public int lightmapIndex; public Vector4 lightmapScaleOffset; public Texture2D lightmapTex; // 实际项目中，可能存储路径而非直接引用 void Start() { ApplyLightmapData(); } [ContextMenu("Apply Lightmap Data")] public void ApplyLightmapData() { Renderer r = GetComponent<Renderer>(); if (r != null) { // 注意：直接设置lightmapIndex在运行时可能不直接生效，因为需要关联到LightmapSettings中的LightmapData数组 // 更健壮的做法是：在场景加载时，将所有预制体用到的光照贴图纹理收集起来，动态构建一个LightmapData数组，并赋值给LightmapSettings.lightmaps // 然后设置每个Renderer的lightmapIndex为这个动态数组中的对应索引。 // 这是一个简化示例，实际应用需要更复杂的纹理管理逻辑。 if (lightmapTex != null) { // 动态构建LightmapData的逻辑此处省略，属于更高级的实现。 // 简单演示：直接使用一个预设的索引（如果只有一张全局光照贴图） // r.lightmapIndex = lightmapIndex; // r.lightmapScaleOffset = lightmapScaleOffset; Debug.LogWarning("Dynamic lightmap application requires a texture manager. Data is stored in component."); } } } }

这个脚本提供了一个基础框架。请注意，这是一个高度简化的示例。在实际生产环境中，你需要一个更健壮的系统来管理多个预制体的多张光照贴图，包括纹理的存储（是作为预制体的子资源还是独立文件）、运行时纹理的加载与注册到LightmapSettings等。

3.5 第五步：运行时加载与渲染

在游戏运行时，当你动态实例化一个带有PrefabLightmapData组件的预制体时，需要在合适的时机（例如场景加载后、所有此类预制体实例化后）调用一个全局管理器，来统一处理光照贴图的应用。

一个简化的运行时管理思路：

1. 所有“可烘焙预制体”都附带一个PrefabLightmapData脚本，里面存储了其对应的光照贴图资源路径（而非直接引用Texture）以及lightmapScaleOffset。
2. 在加载一个包含多个此类预制体的场景时，一个管理器（如LightmapManager）会收集所有实例化的PrefabLightmapData组件。
3. 管理器根据收集到的光照贴图路径，去重后加载所有需要的Texture2D。
4. 管理器动态创建一个LightmapData[]数组，将加载的纹理填入。
5. 将这个数组赋值给LightmapSettings.lightmaps。
6. 遍历所有收集到的Renderer，根据其PrefabLightmapData中存储的索引（该索引对应步骤4中动态数组的索引）和lightmapScaleOffset，为Renderer的lightmapIndex和lightmapScaleOffset属性赋值。

完成以上步骤后，动态生成的预制体就能正确显示出烘焙的光照效果了。

4. 常见问题、避坑指南与性能优化

在实际操作中，你会遇到各种各样的问题。下面是我踩过坑后总结的一些关键点。

4.1 烘焙阶段常见问题

问题1：烘焙后预制体在烘焙场景里是亮的，但保存后重新打开预制体或在新场景实例化时是黑的。

• 原因与排查：
  1. 光照贴图未保存/引用丢失：检查烘焙生成的光照贴图文件是否确实保存在项目中，并且路径没有被移动。在预制体的PrefabLightmapData组件中检查纹理引用是否为空（显示为“None”）。
  2. Static标志丢失：确保在烘焙场景中，预制体实例被标记为Static。但在预制体资源本身，不应勾选Static。Static标志是实例级别的，用于告诉Unity哪些物体参与烘焙。预制体资源保持非Static，以保证其可以动态实例化。
  3. 着色器不支持：检查预制体材质使用的着色器是否真的支持烘焙光照贴图。可以尝试切换为Unity标准着色器测试。

问题2：光照贴图有接缝或纹理拉伸严重。

• 原因与解决：
  1. UV1问题：根本原因是模型第二套UV（光照贴图UV）展开不佳。使用建模软件或Unity的模型导入设置（勾选“Generate Lightmap UVs”）重新生成。确保在UV1通道中检查，UV岛之间没有重叠，并有足够间距。
  2. 光照贴图分辨率过低：提高Lighting Settings中的Lightmap Resolution（如从10提高到30）。但注意这会增加贴图大小和烘焙时间。
  3. Padding值太小：增加Lightmap Padding值（如从2改为4），给UV岛之间更多缓冲空间。

问题3：烘焙时间过长。

• 优化策略：
  1. 降低采样数：适当降低Direct Samples和Indirect Samples。对于预制体预览烘焙，可以先用低采样（如64/32）快速查看效果，最终烘焙再用高质量。
  2. 优化模型：减少模型面数，特别是对于远处看不到的细节。光照烘焙的计算量与顶点数量有关。
  3. 分块烘焙：如果预制体非常大，可以考虑将其拆分成几个子预制体分别烘焙，然后组合使用。
  4. 使用Progressive GPU：如果显卡支持，务必使用GPU光照贴图计算器，速度比CPU快一个数量级。

4.2 脚本与数据管理避坑

坑1：光照贴图纹理的管理混乱。

• 最佳实践：不要将光照贴图纹理作为预制体的子资源（嵌入）。建议将烘焙产生的所有光照贴图文件（*_Bake场景文件夹下的内容）统一移动到一个全局的资源目录下，如Assets/Resources/Lightmaps/或Assets/AssetBundles/Lightmaps/。在PrefabLightmapData组件中只存储该纹理的资源路径字符串（如"Lightmaps/room_module_a_lightmap"）。通过Resources.Load或AssetDatabase.LoadAssetAtPath（编辑器下）来加载。这样便于纹理的复用、更新和打包管理。

坑2：运行时动态注册光照贴图导致DrawCall上升。

• 性能考量：当你动态修改LightmapSettings.lightmaps数组时，如果新的纹理集与之前差异很大，可能会导致Unity重新批处理（Rebatch）一些使用光照贴图的物体，引起帧率波动。建议在场景加载的过渡期（如Loading界面）完成所有光照贴图的收集、加载和注册工作，避免在游戏进行中频繁操作。

坑3：Light Probe和Reflection Probe的缺失。

• 重要提醒：预制体烘焙只解决了物体自身的漫反射光照。如果动态生成的物体周围有动态物体（如玩家角色），它们需要依靠Light Probe来获取间接光照。因此，在烘焙预制体的独立场景中，务必在预制体周围空间布置好Light Probe Group。当你在运行场景中实例化预制体时，也需要确保实例化位置附近有预先放置好的Light Probe（通常在整个游戏场景中全局布置）。同样，反射信息也需要靠Reflection Probe来捕获。

4.3 进阶技巧：自动化烘焙管线

对于拥有大量需要烘焙的预制体的项目，手动操作每个预制体是不可接受的。你需要建立自动化管线。

1. 编辑器扩展：编写一个更强大的编辑器窗口，可以批量选择多个预制体，然后自动：

   • 为每个预制体创建临时烘焙场景。
   • 实例化预制体并配置Static标志。
   • 应用预设的光照设置（复制一个预设的Lighting Settings资产）。
   • 调用Unity的烘焙API（Lightmapping.BakeAsync）进行烘焙。
   • 烘焙完成后，自动执行数据提取（上述脚本功能）并保存预制体。
   • 删除临时场景。

2. 命令行烘焙：Unity支持命令行模式执行烘焙。你可以编写脚本，通过调用Unity.exe -batchmode -executeMethod [YourBakeMethod] -quit来在无界面的情况下进行批量烘焙，这可以集成到CI/CD（持续集成/持续部署）流程中，在每晚的自动构建中完成光照烘焙工作。

3. 版本控制：光照贴图是二进制大文件。务必使用版本控制系统（如Git LFS, Perforce, Plastic SCM）的“大文件存储”功能来管理它们，否则仓库会迅速膨胀。

5. 总结与个人心得

实现预制体的光照贴图烘焙，本质上是在挑战Unity默认的、以场景为中心的光照工作流。它要求开发者更深入地理解光照数据的存储、传递和应用机制。这个过程繁琐且充满细节，但一旦管线搭建完成，对于模块化、程序化生成内容的项目来说，其带来的视觉一致性和工作流效率的提升是巨大的。

我个人在多个项目中实践这套方案后，最大的体会是规划先行。在项目早期就要决定哪些资产需要作为“带光照的模块”来生产，并为此建立统一的模型规范（尤其是UV1）、目录结构和命名约定。同时，要尽早开发出哪怕是最简单的自动化烘焙工具脚本，这将节省你后期海量的重复劳动时间。

另一个深刻的教训是关于光照探头。起初我们只关注物体本身的烘焙效果，忽略了动态物体与烘焙环境的融合，导致角色在精美的房间内显得像个“发光的外来者”。后来强制规定每个可烘焙预制体都必须附带一个定义好的Light Probe Group体积框作为元数据，并在实例化时动态合并到场景的探头系统中，才解决了这个问题。

最后，这套技术并非银弹。它最适合的是中大型的、静态的、重复使用的环境模块。对于完全动态、可破坏或需要极致性能（如大量DrawCall）的场景，可能需要结合实时光照、光照贴图图集（Lightmap Atlas）甚至自定义的烘焙阴影纹理等更复杂的技术方案。但无论如何，掌握“让预制体自带光影”这项技能，无疑会让你在应对复杂的3D项目光照需求时，手里多了一张王牌。