1. 项目概述从“卡顿”到“流畅”的性能蜕变在Unity项目开发的中后期尤其是当场景复杂度提升、美术资源大量导入后性能问题往往会像幽灵一样突然出现。最典型的症状就是“卡顿”——帧率FPS不稳定画面一卡一卡的在移动设备上可能直接导致发热和耗电剧增。很多开发者第一时间会去检查脚本逻辑、模型面数但常常忽略了一个隐形的性能杀手动态实时灯光。一个看似简单的方向光Directional Light如果照射到大量静态物体上每一帧Unity都需要为这些物体重新计算光照产生海量的DrawCall这是导致CPU瓶颈和帧率波动的核心元凶之一。“从‘卡顿’到‘流畅’”这个标题精准地描述了灯光烘焙Light Baking带来的最直观收益。它不是一个高深莫测的黑科技而是一套成熟、标准且效果立竿见影的优化流程。其核心原理就是将场景中静态物体Static Objects的光照信息包括直接光、间接光、阴影预先计算好并“烘焙”到这些物体自身的纹理即光照贴图Lightmap上。运行时这些物体不再需要实时计算光照GPU直接读取烘焙好的光照贴图进行渲染从而将原本每帧都需要进行的、昂贵的逐像素光照计算转变为一次性的纹理采样操作。DrawCall直降50%甚至更多这绝非夸张。一个中等复杂度的室内场景使用动态全局光照如Unity的Enlighten或GPU Lightmapper实时计算DrawCall轻松突破上千。而经过合理的静态划分和灯光烘焙后DrawCall降到500以内是完全可以实现的。这不仅仅是数字上的变化更是用户体验从“勉强能玩”到“流畅顺滑”的本质提升。本指南将带你深入灯光烘焙的每一个环节从原理认知、工具配置、实操流程到避坑指南手把手让你掌握这项让项目性能脱胎换骨的关键技能。2. 核心原理为什么灯光烘焙是性能优化的“王牌”要理解灯光烘焙为何如此有效我们必须先拆解Unity的渲染管线在遇到动态灯光和静态物体时到底做了什么。2.1 DrawCall的本质与动态光照的成本DrawCall简单理解就是CPU命令GPU“画一个东西”的指令。每次DrawCall都有固定的CPU开销。一个没有合并的网格Mesh使用独特的材质Material就会产生一次DrawCall。当一盏动态灯光如Directional Light, Point Light照射物体时Unity的渲染引擎无论是内置管线、URP还是HDRP为了计算该灯光对物体的影响通常需要为这个物体准备额外的渲染通道Pass。例如一个使用标准着色器Standard Shader的物体被一盏动态方向光照射除了自身的Base Pass很可能还会增加一个额外的“Additive Pass”来叠加这盏光的效果。关键点来了这个额外的Pass对于每个受该灯光影响的、且未被合批的物体都可能产生一次新的DrawCall。假设你的场景有200个静态的箱子每个都是独立的MeshRenderer被一盏动态方向光照射。在不做任何优化的情况下这200个箱子可能会产生200次DrawCallBase Pass 200次DrawCall为方向光增加的Additive Pass总计400次。这仅仅是一盏灯的成本如果再加上点光源、聚光灯DrawCall数量会呈指数级增长CPU瞬间被压垮这就是“卡顿”的根源。2.2 烘焙光照如何“消灭”DrawCall灯光烘焙的思路是“以空间换时间以预处理换实时计算”。预处理计算在编辑器模式下即开发阶段Unity的灯光烘焙系统如Progressive Lightmapper会模拟光线在场景中的传播包括直接照射、反射间接光照、阴影等所有光学现象为每一个静态物体表面上的点计算出一个最终的颜色值。生成光照贴图这些计算好的颜色值不会凭空消失而是被编码成一张或多张2D纹理——这就是光照贴图Lightmap。每个静态物体会被分配一个光照贴图上的特定区域UV区块用来存储它自身的光照信息。运行时替换游戏运行时这些静态物体使用的材质其光照信息不再来自实时光源计算而是直接采样绑定好的光照贴图。这意味着渲染这200个箱子不再需要为那盏方向光提交额外的Additive Pass DrawCall。它们很可能通过静态合批Static Batching被合并最终渲染所有箱子所需的DrawCall可能只有个位数。性能收益对比表光照方案CPU开销 (每帧)GPU开销 (每帧)DrawCall数量内存占用适用场景纯动态光照高需每帧计算光照、阴影高多Pass渲染极高每灯每物体可能1 DC低全动态场景、角色、需要动态变化的光照灯光烘焙极低仅纹理采样低单Pass复杂光照已烘焙极低静态物体可大幅合批高存储光照贴图静态环境、建筑、地形、固定光源场景混合光照中等动态部分需计算中等中等高大部分游戏场景静态环境烘焙动态物体/角色用实时光注意灯光烘焙并非万能。它只对标记为“Static”的物体生效。动态物体玩家、NPC、可移动道具无法享受此优化它们仍需依赖实时光或光照探针Light Probes来与烘焙环境融合。因此“动静分离”的设计思想是使用烘焙光照的前提。2.3 核心工具Unity的Lightmapping系统Unity提供了两套主流的灯光烘焙系统渐进式光照贴图Progressive Lightmapper这是当前的主流和默认选择。它提供交互式预览所见即所得非常适合迭代。它使用CPU或GPU进行路径追踪计算质量高但烘焙速度相对较慢尤其对于大场景。Enlighten旧版Unity旧版的默认烘焙系统已被逐渐淘汰。它烘焙速度较快但预览和迭代体验较差且在某些间接光照场景下效果不如渐进式。对于绝大多数项目坚持使用Progressive LightmapperGPU模式是最佳选择。它平衡了质量、易用性和性能。要启用它只需打开Window Rendering Lighting窗口在Lightmapping Settings中将Lightmapper选项改为Progressive GPU如果显卡支持或Progressive CPU。3. 实战准备场景与资源的标准化处理在点击“Generate Lighting”按钮之前大量的准备工作决定了烘焙的成败和效率。盲目烘焙只会得到糟糕的视觉效果和巨大的贴图资源。3.1 物体的静态标记Static Flag策略这是最关键的一步。在Hierarchy中选中一个物体在Inspector右上角勾选Static复选框。但这其实是一个复合选项点击下拉箭头你会看到Everything将物体完全静态化参与光照烘焙、遮挡剔除Occlusion Culling、导航网格Navigation Static等所有静态系统。Lightmap Static我们最常用的选项。仅标记物体参与光照烘焙但不一定参与其他静态系统。对于只希望烘焙光照但可能仍需移动如通过脚本控制的物体不要勾选此项。Occluder Static / Occludee Static参与遮挡剔除。Navigation Static参与导航网格生成。实操心得不要滥用“Everything”我曾在一个项目初期为了方便给所有环境物体都勾选了“Everything”。结果后来需要为敌人生成导航网格时发现一些本该可移动的障碍物也被算成了静态导航障碍导致AI路径异常。正确的做法是只勾选你确定该物体需要的静态属性。对于绝大多数静态环境美术资产墙壁、地板、岩石、树木只勾选Lightmap Static和Occluder Static如果是大物体即可。3.2 光照贴图UV的生成与校验光照贴图需要第二套UV坐标UV1来存储光照信息。Unity可以自动为没有第二套UV的模型生成“光照贴图UV”Generate Lightmap UVs。操作路径在Project窗口选中模型文件在Inspector的Model分页下找到Generate Lightmap UVs选项并勾选。然后点击Apply。注意事项自动生成的UV可能有问题自动生成算法如“Pack Margin”虽然方便但对于复杂模型如带有许多细小结构的雕塑、镂空家具很容易产生UV重叠、拉伸或过大的间距。这会导致烘焙时出现难看的接缝、光斑或浪费光照贴图空间。检查方法在模型导入设置的Preview窗口将UV Channel切换到1查看生成的UV1布局是否均匀、无重叠。解决方案对于重要的、大面积的静态模型如主建筑墙面、独特的地板强烈建议由美术人员在3D建模软件如Maya, 3ds Max, Blender中手动展好第二套UV。手动展的UV利用率更高烘焙质量更好。3.3 材质与着色器的适配确保你的静态物体使用的材质/着色器支持光照贴图。Unity的标准着色器Standard、通用渲染管线URP的Lit着色器、高清渲染管线HDRP的Lit着色器都默认支持。检查项在材质的Inspector中确保Global Illumination属性设置为Baked或Both如果该物体同时接受烘焙光和实时光。如果设置为Realtime则该材质将忽略烘焙光照。自定义着色器如果你使用了自定义Shader需要确保其包含了光照贴图的采样逻辑。通常需要声明unity_Lightmap和unity_LightmapST等内置变量并在片元着色器中采样。4. 手把手烘焙流程参数详解与性能权衡一切准备就绪现在打开Window Rendering Lighting窗口Unity 2022可能在Window Rendering Lighting Settings我们进入核心操作区。4.1 环境光与天空盒设置在Environment标签页下Source设置环境光的来源。选择Color可以简单指定一个颜色选择Gradient可以设置天空、地平线、地面的颜色渐变选择Skybox则使用指定的天空盒材质。这里的环境光会作为间接光照的重要来源被烘焙进光照贴图。Environment LightingIntensity Multiplier控制环境光的强度。值太大会使场景看起来平淡、缺乏对比值太小则阴影区域会死黑。通常从1.0开始调试。Environment ReflectionsSource同样可以设置为天空盒烘焙的反射探针会捕获天空盒信息影响物体的反射效果。提示使用一个HDR高动态范围的天空盒或颜色可以提供更丰富、更真实的间接照明信息尤其是在室内场景从窗户透入的天光会更有层次感。4.2 灯光烘焙参数深度解析切换到Lightmapping Settings标签页这里是控制烘焙质量和性能的核心。1. 灯光贴图分辨率Lightmap Resolution这是最重要的参数之一单位是“纹素/单位”texels per unit。它定义了世界空间中每单位长度通常是米分配多少个光照贴图像素。值越高光照细节越丰富阴影和间接光越平滑但生成的光照贴图尺寸越大内存占用越高烘焙时间越长。值越低贴图尺寸小内存占用低烘焙快但细节丢失可能出现像素化马赛克的阴影。常用参考值室内精细场景如房间内饰20 - 40室外建筑/中景物体10 - 20大型地形、远景山脉2 - 52. 灯光贴图尺寸Lightmap Size定义单张光照贴图的最大尺寸如1024, 2048, 4096。Unity会自动将多个静态物体的光照信息“打包”到一张或多张这个尺寸的贴图中。策略通常使用2048或4096。更大的尺寸可以减少贴图张数即减少DrawCall但单张贴图内存翻倍。不建议使用超过4096因为很多移动设备不支持那么大的非2次幂尺寸贴图且内存压力大。打包效率在烘焙后查看Lighting窗口的Lightmaps标签可以看到打包图Atlas的利用率。利用率过低如低于50%说明有很多空白空间可以尝试提高Lightmap Resolution或调整物体的Scale In Lightmap参数。3. 间接光照质量相关参数Indirect Resolution通常设置为Lightmap Resolution的1/2到1倍。它控制间接光照光线反弹的计算精度。对于室内场景间接光重要可以设高些如与分辨率相同对于室外可以设低些。Lightmap Padding物体在光照贴图上UV区块之间的间隔。防止纹理采样时“ bleed ”颜色渗漏。默认2-4像素通常足够如果出现边缘渗色可以适当增加到4-8。Direct Samples / Indirect Samples / Environment Samples这些是渐进式光照贴图器的采样数。采样数直接决定最终质量和烘焙时间。编辑器预览Bake按钮可以用较低采样如64-256快速查看效果。最终发布烘焙Generate Lighting则需要高采样如512-1024甚至更高来消除噪点。4. 压缩与编码Compression勾选此选项会对光照贴图进行压缩大幅减少磁盘和内存占用但会引入轻微的压缩失真。发布版本务必勾选。Ambient Occlusion在烘焙过程中计算环境光遮蔽AO让角落、缝隙更暗增加物体的体积感和真实度。强烈建议勾选它几乎不增加额外成本但视觉效果提升显著。Directional Mode选择Directional或Non-Directional。Non-Directional只烘焙光照颜色信息存储量小。Directional额外烘焙主要光照方向信息用于支持法线贴图Normal Map在烘焙光照下的细节表现效果更真实但贴图尺寸会增大通常是4倍。如果你的场景大量使用法线贴图选择Directional否则用Non-Directional以节省内存。4.3 执行烘焙与监控设置好参数后可以先点击Bake按钮进行快速预览。在Progressive Lightmapper模式下你可以在Scene视图实时看到光照逐渐计算、收敛的过程。烘焙过程监控查看Lighting窗口底部的进度条和状态信息。在Console窗口切换到Lighting标签页可以看到详细的烘焙日志包括打包信息、警告如重叠的UV等。烘焙时间可能从几分钟到数小时不等取决于场景复杂度、分辨率和采样数。在迭代期务必使用低分辨率、低采样进行快速烘焙。当预览效果满意后进行最终烘焙点击Generate Lighting按钮或者勾选Auto Generate然后触发一次烘焙。最终的光照贴图会保存在项目目录的LightingData文件夹或指定的文件夹中。5. 高级优化技巧与参数微调掌握了基础烘焙后这些进阶技巧能让你在质量和性能间找到更佳的平衡点并解决一些特定问题。5.1 按物体调整Scale In Lightmap不是所有物体都需要同样的光照细节。一个远处的石头和一个近处的精美雕像应该区别对待。在物体的MeshRenderer组件上有一个Scale In Lightmap参数在Lighting部分。默认值为1表示使用全局的Lightmap Resolution设置。对于重要的、近处的、表面细节丰富的物体如主角常接触的桌面、关键道具可以将其提高到2或4让它在光照贴图上占据更多像素获得更精细的光影。对于次要的、远处的或表面平滑的物体如远景山体、大块平地可以将其降低到0.5甚至0.25节省宝贵的光照贴图空间。实操心得分级管理我会在场景中建立不同的空物体作为父节点如“_HighResLM”、“_MidResLM”、“_LowResLM”将不同重要性的静态物体拖入。然后可以写一个简单的编辑器脚本批量修改同一父节点下所有物体的Scale In Lightmap值效率极高。5.2 解决漏光与阴影瑕疵烘焙后常见问题之一是“漏光”Light Leaking即光线穿透了本应封闭的墙体或角落。原因模型本身有缝隙建模问题或者烘焙时用于计算光线的“射线”穿过了过薄的单面墙体。解决方案检查模型确保所有封闭结构如房间的模型是严丝合缝的没有破面或重叠面。增加墙体厚度在建模时给墙体一定的厚度而不是单一片面。调整世界设置在Lighting窗口的Lightmapping Settings中找到Advanced Parameters或类似名称调整Bounces反弹次数和Filtering过滤参数。有时降低反弹次数或启用过滤可以缓解问题但非根本解决。使用光照贴图通道Lightmap Channels对于复杂嵌套结构可以尝试将内外部分离到不同的光照贴图通道但这属于较高级的用法。5.3 光照探针Light Probes混合动态物体烘焙光照只作用于静态物体。那么动态物体玩家、车辆如何融入这个烘焙好的光照环境呢答案就是光照探针Light Probes。作用光照探针在场景空间中采样烘焙好的光照信息颜色和强度。动态物体会根据其位置从周围最近的几个探针中插值获取光照数据从而让动态物体看起来像是处在烘焙光照的环境中。布置技巧在光照变化剧烈的区域如门口、走廊拐角、灯光下需要密集放置。在开阔、光照均匀的区域可以稀疏放置。使用Light Probe Group组件在场景中可视化地放置探针点。一个常用的技巧是沿着角色的行动路径和活动区域进行布置。确保动态物体的MeshRenderer组件上勾选了Use Light Probes。5.4 遮挡剔除Occlusion Culling的协同优化灯光烘焙优化了渲染状态切换DrawCall而遮挡剔除优化的是根本不用渲染那些看不到的东西。两者结合效果最佳。原理将大型静态物体如建筑、山体标记为Occluder Static在烘焙阶段预计算其可见性。运行时相机看不到的物体根本不会进入渲染队列。操作在Window Rendering Occlusion Culling中烘焙。对于大型开放世界遮挡剔除的收益可能比灯光烘焙还要大。但需要注意动态物体通常不作为遮挡物且烘焙参数如单元格大小需要根据场景尺度仔细调整。6. 性能验证与DrawCall分析实战烘焙完成不是终点我们必须用数据验证优化成果。6.1 使用Frame Debugger逐帧分析Unity的Frame Debugger窗口 分析 Frame Debugger是分析DrawCall的终极利器。在Game视图运行游戏。打开Frame Debugger点击Enable。逐帧或逐DrawCall步进你可以清晰地看到每一帧GPU到底绘制了什么以及为什么绘制。对比分析烘焙前你会看到大量名为“Render Forward: Additive”或类似名称的DrawCall条目每一个都可能对应一个物体为某盏实时光进行的额外绘制。烘焙后这些“Additive”的DrawCall会大量消失。静态物体的绘制通常被合并到少数几个“Render Forward: Opaque”的DrawCall中后面明确写着“Static Batching”。在我的一个优化案例中一个室内场景烘焙前仅渲染静态家具的DrawCall就超过300次。烘焙并启用静态合批后这些家具的DrawCall被合并为3次。这就是标题中“DrawCall直降50%”甚至90%以上的直观体现。6.2 使用Profiler定位性能瓶颈Profiler窗口 分析 Profiler用于宏观性能分析。查看Rendering区域关注SetPass Calls大致等同于DrawCall和Batches的数量变化。烘焙优化后这两个数值应有显著下降。查看CPU Usage区域观察RenderThread渲染线程和WaitForPresent等待GPU的时间。DrawCall减少会直接降低CPU的渲染准备工作负载使RenderThread时间缩短帧率更稳定。内存考量在Profiler的Memory区域检查Texture Memory的增长。烘焙后会新增光照贴图纹理内存。你需要权衡DrawCall降低带来的CPU性能提升和内存增长带来的负担。对于移动平台尤其要注意光照贴图的总体尺寸和压缩格式。6.3 目标平台的真机测试编辑器中的数据仅供参考最终性能表现必须在目标平台尤其是安卓/iOS真机上验证。构建开发包使用Development Build选项并勾选Autoconnect Profiler和Deep Profiling。连接真机Profiler在Unity编辑器的Profiler窗口中选择真机设备进行性能分析。关注指标除了帧率FPS更要关注帧时间的稳定性有无卡顿 spikes、内存占用、以及发热情况。一个成功的烘焙优化应该带来更平滑的帧时间曲线和更低的CPU占用率。7. 常见问题排查与避坑指南即使按照流程操作也难免会遇到各种“坑”。这里记录了一些典型问题及其解决方案。问题1烘焙后物体变黑或全白。可能原因A物体没有正确标记为Lightmap Static。检查Static标记。可能原因B物体的材质着色器不支持光照贴图或者材质的Global Illumination属性设置错误。检查并确保其为Baked。可能原因C光照贴图UVUV1有问题如重叠、翻转或未生成。检查模型的UV1通道。可能原因D场景中没有任何被标记为Baked或Mixed模式的灯光。至少需要一盏参与烘焙的灯。问题2光照贴图有接缝或像素化。可能原因ALightmap Resolution设置过低。尝试提高分辨率。可能原因B物体的Scale In Lightmap值太小导致分配到的像素不足。对于该物体提高此值。可能原因CLightmap Padding太小导致纹理采样时边缘颜色渗漏。适当增加此值。可能原因D模型自身的UV1展开不当存在拉伸或岛屿间距离太近。需要回3D软件调整UV。问题3动态物体在烘焙场景中颜色突兀或不匹配。可能原因A没有放置或正确放置光照探针Light Probes。动态物体需要光照探针来获取环境光。可能原因B光照探针放置太稀疏或者没有覆盖动态物体的活动区域。在关键位置增加探针密度。可能原因C动态物体使用的材质对光照反应过强或过弱。调整其材质的反射率、金属度等参数或使用后处理Post-Processing进行全局色调调和。问题4烘焙时间过长。优化策略A在迭代阶段将Lightmap Resolution和所有采样数Direct/Indirect Samples调到最低使用Bake按钮快速预览。优化策略B使用Progressive GPU模式如果显卡支持通常比CPU模式快很多。优化策略C将场景分块烘焙。对于超大型场景可以将其分成多个子场景使用Addressables或场景分块加载分别烘焙光照。优化策略D检查场景中是否有不必要的、面数极高的物体被标记为Static或者灯光数量是否过多。优化模型和精简灯光是根本。问题5构建后光照效果与编辑器不一致。可能原因A构建时没有包含光照数据。确保在Player SettingsPlayerOther Settings中Lightmap Encoding和Lightmap Stream等选项设置正确并且光照数据被打包进构建。可能原因B使用了Directional模式的光照贴图但目标平台的图形API不支持所需的纹理格式。尝试切换到Non-Directional模式。可能原因C某些自定义Shader在构建时没有正确处理光照贴图相关的变体Variants。检查Shader的编译日志和变体数量。灯光烘焙是Unity性能优化中投入产出比极高的一环。它要求开发者对场景结构、资源管理和光照原理有更深的理解而不仅仅是点击一个按钮。这个过程充满了权衡分辨率与内存、质量与时间、静态与动态。但当你看到Profiler中骤降的DrawCall曲线和游戏中稳定流畅的画面时所有这些细致的调整和等待都是值得的。记住优化是一个持续的过程灯光烘焙是其中坚实的第一步它为后续的GPU优化、内存管理打下了坚实的基础。开始对你项目中那个最卡顿的场景动手吧用数据见证从“卡顿”到“流畅”的蜕变。
1. 项目概述从“卡顿”到“流畅”的性能蜕变在Unity项目开发的中后期尤其是当场景复杂度提升、美术资源大量导入后性能问题往往会像幽灵一样突然出现。最典型的症状就是“卡顿”——帧率FPS不稳定画面一卡一卡的在移动设备上可能直接导致发热和耗电剧增。很多开发者第一时间会去检查脚本逻辑、模型面数但常常忽略了一个隐形的性能杀手动态实时灯光。一个看似简单的方向光Directional Light如果照射到大量静态物体上每一帧Unity都需要为这些物体重新计算光照产生海量的DrawCall这是导致CPU瓶颈和帧率波动的核心元凶之一。“从‘卡顿’到‘流畅’”这个标题精准地描述了灯光烘焙Light Baking带来的最直观收益。它不是一个高深莫测的黑科技而是一套成熟、标准且效果立竿见影的优化流程。其核心原理就是将场景中静态物体Static Objects的光照信息包括直接光、间接光、阴影预先计算好并“烘焙”到这些物体自身的纹理即光照贴图Lightmap上。运行时这些物体不再需要实时计算光照GPU直接读取烘焙好的光照贴图进行渲染从而将原本每帧都需要进行的、昂贵的逐像素光照计算转变为一次性的纹理采样操作。DrawCall直降50%甚至更多这绝非夸张。一个中等复杂度的室内场景使用动态全局光照如Unity的Enlighten或GPU Lightmapper实时计算DrawCall轻松突破上千。而经过合理的静态划分和灯光烘焙后DrawCall降到500以内是完全可以实现的。这不仅仅是数字上的变化更是用户体验从“勉强能玩”到“流畅顺滑”的本质提升。本指南将带你深入灯光烘焙的每一个环节从原理认知、工具配置、实操流程到避坑指南手把手让你掌握这项让项目性能脱胎换骨的关键技能。2. 核心原理为什么灯光烘焙是性能优化的“王牌”要理解灯光烘焙为何如此有效我们必须先拆解Unity的渲染管线在遇到动态灯光和静态物体时到底做了什么。2.1 DrawCall的本质与动态光照的成本DrawCall简单理解就是CPU命令GPU“画一个东西”的指令。每次DrawCall都有固定的CPU开销。一个没有合并的网格Mesh使用独特的材质Material就会产生一次DrawCall。当一盏动态灯光如Directional Light, Point Light照射物体时Unity的渲染引擎无论是内置管线、URP还是HDRP为了计算该灯光对物体的影响通常需要为这个物体准备额外的渲染通道Pass。例如一个使用标准着色器Standard Shader的物体被一盏动态方向光照射除了自身的Base Pass很可能还会增加一个额外的“Additive Pass”来叠加这盏光的效果。关键点来了这个额外的Pass对于每个受该灯光影响的、且未被合批的物体都可能产生一次新的DrawCall。假设你的场景有200个静态的箱子每个都是独立的MeshRenderer被一盏动态方向光照射。在不做任何优化的情况下这200个箱子可能会产生200次DrawCallBase Pass 200次DrawCall为方向光增加的Additive Pass总计400次。这仅仅是一盏灯的成本如果再加上点光源、聚光灯DrawCall数量会呈指数级增长CPU瞬间被压垮这就是“卡顿”的根源。2.2 烘焙光照如何“消灭”DrawCall灯光烘焙的思路是“以空间换时间以预处理换实时计算”。预处理计算在编辑器模式下即开发阶段Unity的灯光烘焙系统如Progressive Lightmapper会模拟光线在场景中的传播包括直接照射、反射间接光照、阴影等所有光学现象为每一个静态物体表面上的点计算出一个最终的颜色值。生成光照贴图这些计算好的颜色值不会凭空消失而是被编码成一张或多张2D纹理——这就是光照贴图Lightmap。每个静态物体会被分配一个光照贴图上的特定区域UV区块用来存储它自身的光照信息。运行时替换游戏运行时这些静态物体使用的材质其光照信息不再来自实时光源计算而是直接采样绑定好的光照贴图。这意味着渲染这200个箱子不再需要为那盏方向光提交额外的Additive Pass DrawCall。它们很可能通过静态合批Static Batching被合并最终渲染所有箱子所需的DrawCall可能只有个位数。性能收益对比表光照方案CPU开销 (每帧)GPU开销 (每帧)DrawCall数量内存占用适用场景纯动态光照高需每帧计算光照、阴影高多Pass渲染极高每灯每物体可能1 DC低全动态场景、角色、需要动态变化的光照灯光烘焙极低仅纹理采样低单Pass复杂光照已烘焙极低静态物体可大幅合批高存储光照贴图静态环境、建筑、地形、固定光源场景混合光照中等动态部分需计算中等中等高大部分游戏场景静态环境烘焙动态物体/角色用实时光注意灯光烘焙并非万能。它只对标记为“Static”的物体生效。动态物体玩家、NPC、可移动道具无法享受此优化它们仍需依赖实时光或光照探针Light Probes来与烘焙环境融合。因此“动静分离”的设计思想是使用烘焙光照的前提。2.3 核心工具Unity的Lightmapping系统Unity提供了两套主流的灯光烘焙系统渐进式光照贴图Progressive Lightmapper这是当前的主流和默认选择。它提供交互式预览所见即所得非常适合迭代。它使用CPU或GPU进行路径追踪计算质量高但烘焙速度相对较慢尤其对于大场景。Enlighten旧版Unity旧版的默认烘焙系统已被逐渐淘汰。它烘焙速度较快但预览和迭代体验较差且在某些间接光照场景下效果不如渐进式。对于绝大多数项目坚持使用Progressive LightmapperGPU模式是最佳选择。它平衡了质量、易用性和性能。要启用它只需打开Window Rendering Lighting窗口在Lightmapping Settings中将Lightmapper选项改为Progressive GPU如果显卡支持或Progressive CPU。3. 实战准备场景与资源的标准化处理在点击“Generate Lighting”按钮之前大量的准备工作决定了烘焙的成败和效率。盲目烘焙只会得到糟糕的视觉效果和巨大的贴图资源。3.1 物体的静态标记Static Flag策略这是最关键的一步。在Hierarchy中选中一个物体在Inspector右上角勾选Static复选框。但这其实是一个复合选项点击下拉箭头你会看到Everything将物体完全静态化参与光照烘焙、遮挡剔除Occlusion Culling、导航网格Navigation Static等所有静态系统。Lightmap Static我们最常用的选项。仅标记物体参与光照烘焙但不一定参与其他静态系统。对于只希望烘焙光照但可能仍需移动如通过脚本控制的物体不要勾选此项。Occluder Static / Occludee Static参与遮挡剔除。Navigation Static参与导航网格生成。实操心得不要滥用“Everything”我曾在一个项目初期为了方便给所有环境物体都勾选了“Everything”。结果后来需要为敌人生成导航网格时发现一些本该可移动的障碍物也被算成了静态导航障碍导致AI路径异常。正确的做法是只勾选你确定该物体需要的静态属性。对于绝大多数静态环境美术资产墙壁、地板、岩石、树木只勾选Lightmap Static和Occluder Static如果是大物体即可。3.2 光照贴图UV的生成与校验光照贴图需要第二套UV坐标UV1来存储光照信息。Unity可以自动为没有第二套UV的模型生成“光照贴图UV”Generate Lightmap UVs。操作路径在Project窗口选中模型文件在Inspector的Model分页下找到Generate Lightmap UVs选项并勾选。然后点击Apply。注意事项自动生成的UV可能有问题自动生成算法如“Pack Margin”虽然方便但对于复杂模型如带有许多细小结构的雕塑、镂空家具很容易产生UV重叠、拉伸或过大的间距。这会导致烘焙时出现难看的接缝、光斑或浪费光照贴图空间。检查方法在模型导入设置的Preview窗口将UV Channel切换到1查看生成的UV1布局是否均匀、无重叠。解决方案对于重要的、大面积的静态模型如主建筑墙面、独特的地板强烈建议由美术人员在3D建模软件如Maya, 3ds Max, Blender中手动展好第二套UV。手动展的UV利用率更高烘焙质量更好。3.3 材质与着色器的适配确保你的静态物体使用的材质/着色器支持光照贴图。Unity的标准着色器Standard、通用渲染管线URP的Lit着色器、高清渲染管线HDRP的Lit着色器都默认支持。检查项在材质的Inspector中确保Global Illumination属性设置为Baked或Both如果该物体同时接受烘焙光和实时光。如果设置为Realtime则该材质将忽略烘焙光照。自定义着色器如果你使用了自定义Shader需要确保其包含了光照贴图的采样逻辑。通常需要声明unity_Lightmap和unity_LightmapST等内置变量并在片元着色器中采样。4. 手把手烘焙流程参数详解与性能权衡一切准备就绪现在打开Window Rendering Lighting窗口Unity 2022可能在Window Rendering Lighting Settings我们进入核心操作区。4.1 环境光与天空盒设置在Environment标签页下Source设置环境光的来源。选择Color可以简单指定一个颜色选择Gradient可以设置天空、地平线、地面的颜色渐变选择Skybox则使用指定的天空盒材质。这里的环境光会作为间接光照的重要来源被烘焙进光照贴图。Environment LightingIntensity Multiplier控制环境光的强度。值太大会使场景看起来平淡、缺乏对比值太小则阴影区域会死黑。通常从1.0开始调试。Environment ReflectionsSource同样可以设置为天空盒烘焙的反射探针会捕获天空盒信息影响物体的反射效果。提示使用一个HDR高动态范围的天空盒或颜色可以提供更丰富、更真实的间接照明信息尤其是在室内场景从窗户透入的天光会更有层次感。4.2 灯光烘焙参数深度解析切换到Lightmapping Settings标签页这里是控制烘焙质量和性能的核心。1. 灯光贴图分辨率Lightmap Resolution这是最重要的参数之一单位是“纹素/单位”texels per unit。它定义了世界空间中每单位长度通常是米分配多少个光照贴图像素。值越高光照细节越丰富阴影和间接光越平滑但生成的光照贴图尺寸越大内存占用越高烘焙时间越长。值越低贴图尺寸小内存占用低烘焙快但细节丢失可能出现像素化马赛克的阴影。常用参考值室内精细场景如房间内饰20 - 40室外建筑/中景物体10 - 20大型地形、远景山脉2 - 52. 灯光贴图尺寸Lightmap Size定义单张光照贴图的最大尺寸如1024, 2048, 4096。Unity会自动将多个静态物体的光照信息“打包”到一张或多张这个尺寸的贴图中。策略通常使用2048或4096。更大的尺寸可以减少贴图张数即减少DrawCall但单张贴图内存翻倍。不建议使用超过4096因为很多移动设备不支持那么大的非2次幂尺寸贴图且内存压力大。打包效率在烘焙后查看Lighting窗口的Lightmaps标签可以看到打包图Atlas的利用率。利用率过低如低于50%说明有很多空白空间可以尝试提高Lightmap Resolution或调整物体的Scale In Lightmap参数。3. 间接光照质量相关参数Indirect Resolution通常设置为Lightmap Resolution的1/2到1倍。它控制间接光照光线反弹的计算精度。对于室内场景间接光重要可以设高些如与分辨率相同对于室外可以设低些。Lightmap Padding物体在光照贴图上UV区块之间的间隔。防止纹理采样时“ bleed ”颜色渗漏。默认2-4像素通常足够如果出现边缘渗色可以适当增加到4-8。Direct Samples / Indirect Samples / Environment Samples这些是渐进式光照贴图器的采样数。采样数直接决定最终质量和烘焙时间。编辑器预览Bake按钮可以用较低采样如64-256快速查看效果。最终发布烘焙Generate Lighting则需要高采样如512-1024甚至更高来消除噪点。4. 压缩与编码Compression勾选此选项会对光照贴图进行压缩大幅减少磁盘和内存占用但会引入轻微的压缩失真。发布版本务必勾选。Ambient Occlusion在烘焙过程中计算环境光遮蔽AO让角落、缝隙更暗增加物体的体积感和真实度。强烈建议勾选它几乎不增加额外成本但视觉效果提升显著。Directional Mode选择Directional或Non-Directional。Non-Directional只烘焙光照颜色信息存储量小。Directional额外烘焙主要光照方向信息用于支持法线贴图Normal Map在烘焙光照下的细节表现效果更真实但贴图尺寸会增大通常是4倍。如果你的场景大量使用法线贴图选择Directional否则用Non-Directional以节省内存。4.3 执行烘焙与监控设置好参数后可以先点击Bake按钮进行快速预览。在Progressive Lightmapper模式下你可以在Scene视图实时看到光照逐渐计算、收敛的过程。烘焙过程监控查看Lighting窗口底部的进度条和状态信息。在Console窗口切换到Lighting标签页可以看到详细的烘焙日志包括打包信息、警告如重叠的UV等。烘焙时间可能从几分钟到数小时不等取决于场景复杂度、分辨率和采样数。在迭代期务必使用低分辨率、低采样进行快速烘焙。当预览效果满意后进行最终烘焙点击Generate Lighting按钮或者勾选Auto Generate然后触发一次烘焙。最终的光照贴图会保存在项目目录的LightingData文件夹或指定的文件夹中。5. 高级优化技巧与参数微调掌握了基础烘焙后这些进阶技巧能让你在质量和性能间找到更佳的平衡点并解决一些特定问题。5.1 按物体调整Scale In Lightmap不是所有物体都需要同样的光照细节。一个远处的石头和一个近处的精美雕像应该区别对待。在物体的MeshRenderer组件上有一个Scale In Lightmap参数在Lighting部分。默认值为1表示使用全局的Lightmap Resolution设置。对于重要的、近处的、表面细节丰富的物体如主角常接触的桌面、关键道具可以将其提高到2或4让它在光照贴图上占据更多像素获得更精细的光影。对于次要的、远处的或表面平滑的物体如远景山体、大块平地可以将其降低到0.5甚至0.25节省宝贵的光照贴图空间。实操心得分级管理我会在场景中建立不同的空物体作为父节点如“_HighResLM”、“_MidResLM”、“_LowResLM”将不同重要性的静态物体拖入。然后可以写一个简单的编辑器脚本批量修改同一父节点下所有物体的Scale In Lightmap值效率极高。5.2 解决漏光与阴影瑕疵烘焙后常见问题之一是“漏光”Light Leaking即光线穿透了本应封闭的墙体或角落。原因模型本身有缝隙建模问题或者烘焙时用于计算光线的“射线”穿过了过薄的单面墙体。解决方案检查模型确保所有封闭结构如房间的模型是严丝合缝的没有破面或重叠面。增加墙体厚度在建模时给墙体一定的厚度而不是单一片面。调整世界设置在Lighting窗口的Lightmapping Settings中找到Advanced Parameters或类似名称调整Bounces反弹次数和Filtering过滤参数。有时降低反弹次数或启用过滤可以缓解问题但非根本解决。使用光照贴图通道Lightmap Channels对于复杂嵌套结构可以尝试将内外部分离到不同的光照贴图通道但这属于较高级的用法。5.3 光照探针Light Probes混合动态物体烘焙光照只作用于静态物体。那么动态物体玩家、车辆如何融入这个烘焙好的光照环境呢答案就是光照探针Light Probes。作用光照探针在场景空间中采样烘焙好的光照信息颜色和强度。动态物体会根据其位置从周围最近的几个探针中插值获取光照数据从而让动态物体看起来像是处在烘焙光照的环境中。布置技巧在光照变化剧烈的区域如门口、走廊拐角、灯光下需要密集放置。在开阔、光照均匀的区域可以稀疏放置。使用Light Probe Group组件在场景中可视化地放置探针点。一个常用的技巧是沿着角色的行动路径和活动区域进行布置。确保动态物体的MeshRenderer组件上勾选了Use Light Probes。5.4 遮挡剔除Occlusion Culling的协同优化灯光烘焙优化了渲染状态切换DrawCall而遮挡剔除优化的是根本不用渲染那些看不到的东西。两者结合效果最佳。原理将大型静态物体如建筑、山体标记为Occluder Static在烘焙阶段预计算其可见性。运行时相机看不到的物体根本不会进入渲染队列。操作在Window Rendering Occlusion Culling中烘焙。对于大型开放世界遮挡剔除的收益可能比灯光烘焙还要大。但需要注意动态物体通常不作为遮挡物且烘焙参数如单元格大小需要根据场景尺度仔细调整。6. 性能验证与DrawCall分析实战烘焙完成不是终点我们必须用数据验证优化成果。6.1 使用Frame Debugger逐帧分析Unity的Frame Debugger窗口 分析 Frame Debugger是分析DrawCall的终极利器。在Game视图运行游戏。打开Frame Debugger点击Enable。逐帧或逐DrawCall步进你可以清晰地看到每一帧GPU到底绘制了什么以及为什么绘制。对比分析烘焙前你会看到大量名为“Render Forward: Additive”或类似名称的DrawCall条目每一个都可能对应一个物体为某盏实时光进行的额外绘制。烘焙后这些“Additive”的DrawCall会大量消失。静态物体的绘制通常被合并到少数几个“Render Forward: Opaque”的DrawCall中后面明确写着“Static Batching”。在我的一个优化案例中一个室内场景烘焙前仅渲染静态家具的DrawCall就超过300次。烘焙并启用静态合批后这些家具的DrawCall被合并为3次。这就是标题中“DrawCall直降50%”甚至90%以上的直观体现。6.2 使用Profiler定位性能瓶颈Profiler窗口 分析 Profiler用于宏观性能分析。查看Rendering区域关注SetPass Calls大致等同于DrawCall和Batches的数量变化。烘焙优化后这两个数值应有显著下降。查看CPU Usage区域观察RenderThread渲染线程和WaitForPresent等待GPU的时间。DrawCall减少会直接降低CPU的渲染准备工作负载使RenderThread时间缩短帧率更稳定。内存考量在Profiler的Memory区域检查Texture Memory的增长。烘焙后会新增光照贴图纹理内存。你需要权衡DrawCall降低带来的CPU性能提升和内存增长带来的负担。对于移动平台尤其要注意光照贴图的总体尺寸和压缩格式。6.3 目标平台的真机测试编辑器中的数据仅供参考最终性能表现必须在目标平台尤其是安卓/iOS真机上验证。构建开发包使用Development Build选项并勾选Autoconnect Profiler和Deep Profiling。连接真机Profiler在Unity编辑器的Profiler窗口中选择真机设备进行性能分析。关注指标除了帧率FPS更要关注帧时间的稳定性有无卡顿 spikes、内存占用、以及发热情况。一个成功的烘焙优化应该带来更平滑的帧时间曲线和更低的CPU占用率。7. 常见问题排查与避坑指南即使按照流程操作也难免会遇到各种“坑”。这里记录了一些典型问题及其解决方案。问题1烘焙后物体变黑或全白。可能原因A物体没有正确标记为Lightmap Static。检查Static标记。可能原因B物体的材质着色器不支持光照贴图或者材质的Global Illumination属性设置错误。检查并确保其为Baked。可能原因C光照贴图UVUV1有问题如重叠、翻转或未生成。检查模型的UV1通道。可能原因D场景中没有任何被标记为Baked或Mixed模式的灯光。至少需要一盏参与烘焙的灯。问题2光照贴图有接缝或像素化。可能原因ALightmap Resolution设置过低。尝试提高分辨率。可能原因B物体的Scale In Lightmap值太小导致分配到的像素不足。对于该物体提高此值。可能原因CLightmap Padding太小导致纹理采样时边缘颜色渗漏。适当增加此值。可能原因D模型自身的UV1展开不当存在拉伸或岛屿间距离太近。需要回3D软件调整UV。问题3动态物体在烘焙场景中颜色突兀或不匹配。可能原因A没有放置或正确放置光照探针Light Probes。动态物体需要光照探针来获取环境光。可能原因B光照探针放置太稀疏或者没有覆盖动态物体的活动区域。在关键位置增加探针密度。可能原因C动态物体使用的材质对光照反应过强或过弱。调整其材质的反射率、金属度等参数或使用后处理Post-Processing进行全局色调调和。问题4烘焙时间过长。优化策略A在迭代阶段将Lightmap Resolution和所有采样数Direct/Indirect Samples调到最低使用Bake按钮快速预览。优化策略B使用Progressive GPU模式如果显卡支持通常比CPU模式快很多。优化策略C将场景分块烘焙。对于超大型场景可以将其分成多个子场景使用Addressables或场景分块加载分别烘焙光照。优化策略D检查场景中是否有不必要的、面数极高的物体被标记为Static或者灯光数量是否过多。优化模型和精简灯光是根本。问题5构建后光照效果与编辑器不一致。可能原因A构建时没有包含光照数据。确保在Player SettingsPlayerOther Settings中Lightmap Encoding和Lightmap Stream等选项设置正确并且光照数据被打包进构建。可能原因B使用了Directional模式的光照贴图但目标平台的图形API不支持所需的纹理格式。尝试切换到Non-Directional模式。可能原因C某些自定义Shader在构建时没有正确处理光照贴图相关的变体Variants。检查Shader的编译日志和变体数量。灯光烘焙是Unity性能优化中投入产出比极高的一环。它要求开发者对场景结构、资源管理和光照原理有更深的理解而不仅仅是点击一个按钮。这个过程充满了权衡分辨率与内存、质量与时间、静态与动态。但当你看到Profiler中骤降的DrawCall曲线和游戏中稳定流畅的画面时所有这些细致的调整和等待都是值得的。记住优化是一个持续的过程灯光烘焙是其中坚实的第一步它为后续的GPU优化、内存管理打下了坚实的基础。开始对你项目中那个最卡顿的场景动手吧用数据见证从“卡顿”到“流畅”的蜕变。
 - 诚收名表回收平台)
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
