上个月有个做毕业设计的同学给我发来一段视频一个关卡场景里密密麻麻放了三十多盏点光源每盏都在实时投射阴影画面倒是挺热闹但帧率直线掉到了十几。他在群里问我“是不是要把阴影全关掉”我让他先打开 Frame Debugger 看看渲染循环里到底发生了什么结果发现场景里物体的 Shadow Pass 数量早就失控了。这事让我想起很多刚开始接触 Unity 渲染的人都会经历的一个阶段——灯光一拖就完事阴影一勾就卡成幻灯片然后开始在社区里搜各种“Unity 阴影问题”“场景发白”“灯光不生效”。这篇文章就是写给这些人的不聊高大上的 PBR 数学推导就老老实实把灯光、阴影、前向渲染和延迟渲染这四件事讲清楚让新手能看懂原理也能照着调出像样的画面和合理的性能。1. 新手一定会踩的坑灯光越多画面越崩1.1 一个典型翻车现场你肯定见过这种场景美术同学在场景里放了七八盏灯结果画面不是一片惨白就是黑得像进了地窖。更诡异的是明明只是加了灯、开了阴影帧率就从 60 掉到 30 以下。原因其实不复杂——灯光在渲染管线里是“要算账的”。每一盏实时灯光都意味着要对受影响的物体做额外计算阴影更夸张它要在灯光视角下把整个场景重新画一遍。你放进去的不是“一盏灯”而是一个看不见的额外渲染过程。这个过程的频率和开销取决于你用的渲染路径。1.2 渲染路径到底管什么我习惯把渲染路径理解成“餐厅出餐方式”。同样一盘菜一个物体前向渲染和后厨的做法完全不同前向渲染Forward来了一个客人点菜厨师就从头到尾炒一盘。每一个物体都遍历所有影响它的灯光逐盏计算光照结果。延迟渲染Deferred后厨先把所有食材洗好、切好、摆盘写入 G-Buffer等到客人点菜时只需要“浇汁”不管来多少客人浇汁成本都差不多。所以前向渲染更适合“灯光少、物体多”的场景延迟渲染则适合“物体多、灯光更多”的场景。但延迟渲染也有代价——它要先把一大堆中间数据写进显存带宽开销比前向渲染大得多。这就是为什么移动端和 WebGL 上并不总是“延迟更好”的原因。1.3 先把“灯光数量”和“路径选择”挂上钩给新手一个最直观的判断标准如果你的场景里同时有超过 4~5 盏实时灯光会影响同一个物体前向渲染就会出现明显的性能问题。因为你每多一盏灯光物体的 Pass 就多一次也就是多一次完整的渲染。而即便你用延迟渲染“灯光数量随便加”也只是相对前向而言的。延迟渲染在 PC 上很舒服但在手机上是另一回事。这个先记在脑子里后面我详细展开。2. Unity 灯光的计算方法从一盏灯开始说清楚2.1 灯光的类型与使用限制Unity 的 Light 组件有四种常见类型每种的工作原理完全不同用错场景就会出现“看起来亮但实际上没被照亮”的问题。灯光类型核心属性常见误用Directional Light平行光只受旋转影响位置无关以为移动光源就能改变明暗方向Point Light点光源有衰减范围范围外瞬间无光范围调很大导致灯光又暗又废Spot Light聚光灯有圆锥角度有方向有范围角度和范围不匹配硬边明显Area Light面光源默认只支持烘焙实时模式下需要特定管线运行时开起来发现没效果平行光是最典型的——它模拟的是“无限远处的太阳光”位置根本无所谓只有朝向会影响光照效果。很多新手把平行光当成台灯来挪挪半天发现光影没变化然后开始怀疑场景有问题其实只是没搞清楚平行光的定位。点光源和聚光灯则严格受范围Range影响。当你把点光源的 Range 调到 50但强度只有 1画面看起来就是“哪儿都不亮”。这是因为 Unity 在处理真实感光照时光强会随距离衰减范围越大单位面积上的光就越弱。2.2 强度、衰减、范围为什么你调出来的场景总不对这里要提到一个新手最容易忽略的概念衰减Attenuation。在真实世界里光的强度和距离的平方成反比——离灯 2 米远的地方亮度是 1 米处的 1/4。Unity 的实时灯光默认就采用这种平方反比衰减。这意味着你把灯光 Range 从 5 调到 10边缘位置的光照强度不是减半而是降到原来的 1/4。所以当你觉得“灯光太暗”时不要一味去加 Intensity而是要想想是不是灯光范围拉太大或者灯光离物体太远。另外一个容易出错的地方是环境光。Unity 场景默认会带一定强度的环境光和天空盒照明。有时候你什么都没做场景看起来灰蒙蒙的以为是灯光设置有问题有时候你加了一盏强平行光又发现画面整体过曝——这其实是环境光、天空盒和实时光叠加在一起的结果。实操建议平行光强度从 0.5 开始调慢慢往上加别一上来就 3、4。点光源和聚光灯不要只看 Intensity多调整 Range 匹配实际场景尺度。如果场景里没有明确的光源方向需求先把 Environment Lighting 里的 Ambient Mode 改成 Color给一个中性的浅灰你会发现画面更容易控制。2.3 实时光与烘焙光的性能分界线实时灯光确实省事拖进去就能照亮但性能开销也在同时累积。真正让画面“像样”的做法通常是混合使用动态物体吃实时光静态物体吃烘焙光。烘焙Baked Lighting的意思是把灯光信息提前计算好存成光照贴图Lightmap运行时直接采样计算量非常小。它的限制是只能作用于静态物体Static如果场景里的大多数东西都是动态移动的烘焙的意义就大打折扣。我见过不少团队一上来就全场景实时灯光到了设备上卡成 PPT才开始考虑烘焙。但烘焙也不是万能的——动态物体在移动时无法实时接收烘焙阴影它和静态物体之间会出现穿帮。所以这里有个基本判断场景以静态为主尽量烘焙场景全是动态物体就多用实时灯光并控制数量或者用后面提到的 Forward 方案。3. 阴影调试实录从 Shadow Map 到三个翻车现场3.1 Shadow Map 的生成逻辑与 Bias 的意义阴影在 Unity 里的实现方式不是“光线追踪”而是Shadow Map阴影贴图。简单说引擎会在灯光的视角里放一台虚拟摄像机从灯光方向看向场景记录每个点到灯光的距离渲染成一张深度图。真正渲染主场景时只要判断某个像素的深度和阴影贴图里记录的距离是否一致比记录值远说明它在阴影里一致或更近说明能被灯光照到。这个“距离比较”过程中有个经典问题——精度有限。深度图的分辨率不可能无限大两个靠得很近的表面比如地面和紧贴地面的墙面根部会出现深度值几乎一样的状况导致渲染结果一会儿判定在阴影里、一会儿判定不在画面就出现了那种密密麻麻的闪烁斑点也就是Shadow Acne阴影粉刺。解决办法是给阴影判断加一个容差这个容差就是Shadow Bias阴影偏移。Unity 的 Light 组件上有两个关键参数Bias沿光线方向把判定距离往后推一点减少自阴影粉刺。Normal Bias沿法线方向把表面微微“鼓起”一点减少边缘的低频噪声。但这又引入了另一个问题偏移加得太多阴影会“飘”起来看起来物体像踩着高跷也就是常说的Peter Panning彼得潘现象因为影子仿佛不属于这个物体了。3.2 条纹、漂浮、闪烁三个最常见阴影问题的排查链路先说结论遇到阴影相关的视觉 bug第一件事不是调參数而是打开 Frame Debugger 管线逐帧看一遍确认阴影贴图渲染是否正常、主光源的阴影采样是否执行。确定是 Shadow Map 问题后再按下述排查。第一个问题阴影边缘有密集条纹。这种现象通常出现在大面积平面接受阴影的时候比如地板、墙面。排查思路就是看 Bias 是不是过小。你可以把 Light 的 Normal Bias 从默认的 1 调到 0.5 或更低然后观察条纹变化。如果改善不明显考虑提高阴影贴图分辨率在 URP 的 Render Pipeline Asset 里把 Shadow Resolution 从 Medium 提到 High。第二个问题阴影和物体之间出现漂浮间隙看起来像物体离开了地面。这时候反而要把 Bias 往回调小。我见过有人为了消除上一类条纹直接把 Bias 拉到 2、3结果整片阴影全悬空了。正确做法是同时调整 Bias 和 Shadow Resolution用更高分辨率替代无脑加 Bias。第三个问题远处阴影闪烁或直接消失。这通常是 Shadow Distance阴影距离设置和阴影贴图分辨率不匹配导致的。你把阴影距离拉到 300但阴影贴图只有 1024 分辨率远处的阴影会变成一片糊状闪烁。解决方式有两种降低 Shadow Distance让远处物体干脆没有阴影或者开启 Shadow Cascades级联阴影让近处阴影用高分辨率、远处用低分辨率。3.3 级联阴影与软阴影的取舍级联阴影是平行光专属的策略。平行光照射范围非常大整个场景都可能被覆盖如果用一张阴影贴图覆盖全局近处的地面阴影会糊成一团。所以引擎把摄像机的可视范围切成几层近处分配更高分辨率的阴影贴图远处分配低分辨率这就是 Shadow Cascades。在 URP 中默认是 4 个 Cascade画质较好但代价是阴影贴图要渲染 1 份还是 4 份的问题。实际测试下来Cascade 从 4 降到 2阴影相关的 GPU 消耗能明显下降视觉上只要你不是贴着地面细看差别不大。对移动端项目直接从 2 开始都是合理的。至于软阴影Soft Shadows它模拟的是“半影”效果即阴影边缘的过渡带。这个效果不是免费的——它本质上是多点采样等于阴影贴图采样次数直接翻倍。如果项目跑在低端机上建议把软阴影关掉用硬阴影配合合适的阴影贴图分辨率观感反而更干净。4. 前向渲染与延迟渲染两套流水线的真实成本4.1 前向渲染每盏灯都是 Draw Call前向渲染的逻辑很直观对于物体上的每个片元找出所有对该片元有影响的灯光然后把它们的光照结果叠加起来。但这会产生一个致命问题一个物体受多少盏实时灯光的逐像素影响就要重复渲染多少次。比如场景里一个角色同时被 5 盏灯照亮前向路径下角色模型要被渲染 5 次一次主渲染四次额外额外的光照 Pass如果这 5 盏灯还会投射阴影每个 Pass 都可能附带阴影贴图采样开销成倍增长。在实际操作中你可以在 Profiler 的 Rendering 模块里看 SetPass Calls如果发现一个物体的 SetPass 数量远超物体数量优先怀疑是不是实时灯光太多。新手最容易忽略的是即使灯光范围没有覆盖某些物体Unity 也会按照灯光影响范围做剔除但剔除的精度不是完全精确的尤其是聚光灯边缘误判还挺常见的。4.2 延迟渲染G-Buffer 的带宽账单延迟渲染为什么不怕灯光多因为它把光照计算推迟到了“屏幕空间”。第一步先把场景里不透明物体的颜色、法线、深度、金属度、粗糙度等数据分别写入几张纹理这几张纹理合起来叫G-Buffer几何缓冲。第二步对所有屏幕像素逐像素遍历灯光直接从 G-Buffer 里取数据计算光照。这样一来灯光数量对光照计算的影响就小了——不管场景里有多少盏灯每个像素的计算次数只跟覆盖该像素的灯光总数有关不再依赖物体数量。听起来很美代价在哪在带宽。G-Buffer 通常有 4~5 张纹理每张还是高精度格式。一张 1080p 的延迟渲染画面光是 G-Buffer 写入就是几百 MB 的显存开销。移动端的 GPU 带宽是稀缺资源跑延迟渲染很容易发热和掉帧。另外延迟渲染对半透明物体是不友好的——G-Buffer 只能存一层几何信息半透明物体之间没法做正确的遮挡混合所以引擎会把半透明物体单独用前向方式再渲染一遍。这又带来了新的排序问题。还有一个常见坑延迟渲染路径下 MSAA 抗锯齿往往不可用。因为中间多层缓冲都是浮点纹理MSAA 的支持很差。你想做全屏抗锯齿得靠 TAA、SMAA 这类后处理方案。这一条在 URP 里尤其明显切换渲染路径前先想清楚你的抗锯齿方案。4.3 不同平台怎么选PC、移动端、WebGLPC 端显存带宽充足灯光数量多就直接用延迟渲染。但延迟渲染对场景物体的材质有要求某些自定义 Shader 如果不兼容 G-Buffer 输出可能出现物体渲染成黑块、法线异常等问题。移动端能不用延迟就不用延迟。顶级手机无所谓大众机型的带宽是硬伤。而且移动端 GPU 的 tiled-based 架构天然更适合前向渲染很多引擎在移动端还额外做了 Tile Based DeferredTBD但这个不是你能在 Unity 里直接开关的。WebGL兼容性挑战最大。WebGL 1.0 时代基本只能前向WebGL 2.0 下 URP 支持了延迟渲染但能力受浏览器和低端设备限制。我在开发 WebGL 项目时默认都用前向渲染。遇到灯光多的情况优先用烘焙或实时光照剔除来优化而不是急着切延迟。5. 实战切换渲染路径并验证性能差异5.1 环境准备与路径切换步骤新建一个 URP 项目Unity 6 或 Unity 2022 LTS 都可以在 Project 窗口里找到Assets/Settings/URP-HighQuality这样的管线资产选中后在 Inspector 中找到Rendering Path默认是 Forward改成 Deferred。切换前先确认你的项目版本里是否显示“不支持的警告”——URP 的延迟渲染对平台有要求不同版本支持程度不一样。如果项目里有大量自定义 Shader切到延迟渲染后需要仔细观察画面看看是否有异常表现。我建议你手动搭一个测试场景不用太复杂一块地面平面三五成组的立方体、球体、胶囊体散落放置一盏平行光作为主光源阴影打开再加 6~10 盏点光源均匀分布在物体周围然后分别在前向和延迟模式下跑一遍。为什么要这么做因为这类场景最能暴露前向渲染“灯光数量导致多 Pass”的问题也最容易对比出两者在不同灯光数量下的帧率差异。5.2 Frame Debugger 带你逐帧看渲染过程为了真正理解渲染路径的差异打开Window Analysis Frame Debugger点击 Enable然后一帧一帧地看渲染流程。在前向渲染下你会看到类似这样的队列Depth Prepass如果开了深度纹理主光源 ShadowMap 渲染各种物体的 主发光 附加灯光 Pass屏幕空间特效等你会发现一个物体后面可能跟着好几个 “Light Pass” 的条目每多一盏灯光队列里就多一个。这就是前向路径“灯多卡顿”的直接证据。切成延迟渲染后队列会变成G-Buffer 预渲染G-Buffer Pass写入颜色、法线、深度等阴影贴图屏幕空间光照计算后处理你会看到大量信息被压缩在了几个“大 Pass”里灯光再多也是在屏幕空间里批量算桌面级 GPU 非常喜欢这种模式。这个工具绝对是新手进阶的利器——你不光能看流程还能检查每个 Pass 的 GPU Wait/GPU Time 和输入输出资源。5.3 Overdraw 与 SetPass Calls两个关键性能指标分析渲染性能时我经常让新手看两个量一个是Overdraw过度绘制一个是SetPass Calls。Overdraw 是指同一个像素被反复绘制多次。在 Scene 视图的 Shaded 模式下把显示模式切到 Overdraw画面越白的地方说明绘制重复次数越多。半透明粒子、大面积雾、大量带屏幕特效的 UI 都是重灾区。对灯光系统来说如果前向渲染下物体被多盏灯划分成多个 PassOverdraw 也会明显上升。SetPass Calls 是 Profiler 里一个重要数值。它代表渲染管线切换材质 Pass 的次数每切换一次都是不小的开销。在 Lighting 场景里前向渲染的 SetPass Calls 会随着灯光数量上升而上涨延迟渲染则稳很多。不过要提醒一句优化渲染不要光盯这些数字最终还是要看真机帧率和发热。用 Profiler 的 Rendering 模块多采集几轮数据同一场景前后向各跑一遍做好对比记录。哪种路径更适合你的项目数据会说话。6. 给新手的渲染配置速查与我的几点经验6.1 常见问题速查表现象可能原因解决方向地面或墙面上出现密密麻麻的暗斑/条纹Shadow Bias 太小产生阴影粉刺适当调大 Bias / Normal Bias提高阴影贴图分辨率阴影和物体分离像“飘着”Bias 或 Normal Bias 过大回拨偏移值用阴影分辨率换取清晰度远处阴影闪烁或突然消失Shadow Distance 过大、Cascade 不足减小 Shadow Distance增加 Cascade 级数场景整体过曝/全白平行光强度过高或环境光叠加过大降平行光强度调环境光模式和强度灯光越多帧率下降越明显前向渲染中每盏灯都在增加 Pass减少实时灯光转烘焙或切延迟路径延迟渲染下物体边缘锯齿明显MSAA 不可用通常只支持后处理抗锯齿开启 TAA/SMAA或切回前向渲染半透明物体在延迟渲染下表现异常透明物体走的是额外前向 Pass拆分渲染层级减少透明体之间交叉或换路径6.2 我踩过最深的坑和调试习惯我早期做过一个移动端数字孪生项目场景里放了十几盏实时光照的广告灯牌。测试机上帧率稳定在 30 以上心想问题不大。结果只改了阴影贴图分辨率一项帧率直接掉了 10 帧——罪魁祸首不是灯光的计算量而是阴影贴图渲染的尺寸太大加上级联阴影在移动端吃了大量带宽。那次之后我养成了一个习惯每次只改一个参数改完立刻在 Profile 里对比前后数据。这个习惯听起来基础但真的能帮你避免大量“越调越乱”的情况。新手调渲染参数时最容易犯的错就是一次性把所有旋钮都拧一遍结果画面坏了也不知道是哪一步改坏的。另一个值得说的经验是不要迷信“延迟渲染一定更好”。延迟渲染在 PC 大场景、屋内多光源、大世界夜晚效果里有绝对优势但中小型项目、低端设备、WebGL 场景下前向渲染配合烘焙往往更稳。我之前还见过有人为了延迟渲染重写了整个美术管线最后发现效果还不如前向渲染用点心烘焙来得好。6.3 给新手的路径选择经验浓缩版如果你是刚接触 Unity 渲染我给一条不会走错的路先做一个小场景就几面墙、几个箱子、一盏平行光加两三盏点光源。打开 Frame Debugger把渲染队列从头到尾看一遍认清楚每个 Pass 是干什么的。试着增加灯光数量观察 SetPass Calls 和帧率数字怎么变。切换前向/延迟路径再对比一次。最后结合你的目标平台来定方案。这套流程走下来你对渲染路径的理解就不会只是概念层面的“知道”而是真正能判断“这个场景为什么卡”“这盏灯该不该改为烘焙”。灯光和阴影这两个领域非常吃经验早一点学会用管线分析工具能少走很多弯路。
上个月有个做毕业设计的同学给我发来一段视频一个关卡场景里密密麻麻放了三十多盏点光源每盏都在实时投射阴影画面倒是挺热闹但帧率直线掉到了十几。他在群里问我“是不是要把阴影全关掉”我让他先打开 Frame Debugger 看看渲染循环里到底发生了什么结果发现场景里物体的 Shadow Pass 数量早就失控了。这事让我想起很多刚开始接触 Unity 渲染的人都会经历的一个阶段——灯光一拖就完事阴影一勾就卡成幻灯片然后开始在社区里搜各种“Unity 阴影问题”“场景发白”“灯光不生效”。这篇文章就是写给这些人的不聊高大上的 PBR 数学推导就老老实实把灯光、阴影、前向渲染和延迟渲染这四件事讲清楚让新手能看懂原理也能照着调出像样的画面和合理的性能。1. 新手一定会踩的坑灯光越多画面越崩1.1 一个典型翻车现场你肯定见过这种场景美术同学在场景里放了七八盏灯结果画面不是一片惨白就是黑得像进了地窖。更诡异的是明明只是加了灯、开了阴影帧率就从 60 掉到 30 以下。原因其实不复杂——灯光在渲染管线里是“要算账的”。每一盏实时灯光都意味着要对受影响的物体做额外计算阴影更夸张它要在灯光视角下把整个场景重新画一遍。你放进去的不是“一盏灯”而是一个看不见的额外渲染过程。这个过程的频率和开销取决于你用的渲染路径。1.2 渲染路径到底管什么我习惯把渲染路径理解成“餐厅出餐方式”。同样一盘菜一个物体前向渲染和后厨的做法完全不同前向渲染Forward来了一个客人点菜厨师就从头到尾炒一盘。每一个物体都遍历所有影响它的灯光逐盏计算光照结果。延迟渲染Deferred后厨先把所有食材洗好、切好、摆盘写入 G-Buffer等到客人点菜时只需要“浇汁”不管来多少客人浇汁成本都差不多。所以前向渲染更适合“灯光少、物体多”的场景延迟渲染则适合“物体多、灯光更多”的场景。但延迟渲染也有代价——它要先把一大堆中间数据写进显存带宽开销比前向渲染大得多。这就是为什么移动端和 WebGL 上并不总是“延迟更好”的原因。1.3 先把“灯光数量”和“路径选择”挂上钩给新手一个最直观的判断标准如果你的场景里同时有超过 4~5 盏实时灯光会影响同一个物体前向渲染就会出现明显的性能问题。因为你每多一盏灯光物体的 Pass 就多一次也就是多一次完整的渲染。而即便你用延迟渲染“灯光数量随便加”也只是相对前向而言的。延迟渲染在 PC 上很舒服但在手机上是另一回事。这个先记在脑子里后面我详细展开。2. Unity 灯光的计算方法从一盏灯开始说清楚2.1 灯光的类型与使用限制Unity 的 Light 组件有四种常见类型每种的工作原理完全不同用错场景就会出现“看起来亮但实际上没被照亮”的问题。灯光类型核心属性常见误用Directional Light平行光只受旋转影响位置无关以为移动光源就能改变明暗方向Point Light点光源有衰减范围范围外瞬间无光范围调很大导致灯光又暗又废Spot Light聚光灯有圆锥角度有方向有范围角度和范围不匹配硬边明显Area Light面光源默认只支持烘焙实时模式下需要特定管线运行时开起来发现没效果平行光是最典型的——它模拟的是“无限远处的太阳光”位置根本无所谓只有朝向会影响光照效果。很多新手把平行光当成台灯来挪挪半天发现光影没变化然后开始怀疑场景有问题其实只是没搞清楚平行光的定位。点光源和聚光灯则严格受范围Range影响。当你把点光源的 Range 调到 50但强度只有 1画面看起来就是“哪儿都不亮”。这是因为 Unity 在处理真实感光照时光强会随距离衰减范围越大单位面积上的光就越弱。2.2 强度、衰减、范围为什么你调出来的场景总不对这里要提到一个新手最容易忽略的概念衰减Attenuation。在真实世界里光的强度和距离的平方成反比——离灯 2 米远的地方亮度是 1 米处的 1/4。Unity 的实时灯光默认就采用这种平方反比衰减。这意味着你把灯光 Range 从 5 调到 10边缘位置的光照强度不是减半而是降到原来的 1/4。所以当你觉得“灯光太暗”时不要一味去加 Intensity而是要想想是不是灯光范围拉太大或者灯光离物体太远。另外一个容易出错的地方是环境光。Unity 场景默认会带一定强度的环境光和天空盒照明。有时候你什么都没做场景看起来灰蒙蒙的以为是灯光设置有问题有时候你加了一盏强平行光又发现画面整体过曝——这其实是环境光、天空盒和实时光叠加在一起的结果。实操建议平行光强度从 0.5 开始调慢慢往上加别一上来就 3、4。点光源和聚光灯不要只看 Intensity多调整 Range 匹配实际场景尺度。如果场景里没有明确的光源方向需求先把 Environment Lighting 里的 Ambient Mode 改成 Color给一个中性的浅灰你会发现画面更容易控制。2.3 实时光与烘焙光的性能分界线实时灯光确实省事拖进去就能照亮但性能开销也在同时累积。真正让画面“像样”的做法通常是混合使用动态物体吃实时光静态物体吃烘焙光。烘焙Baked Lighting的意思是把灯光信息提前计算好存成光照贴图Lightmap运行时直接采样计算量非常小。它的限制是只能作用于静态物体Static如果场景里的大多数东西都是动态移动的烘焙的意义就大打折扣。我见过不少团队一上来就全场景实时灯光到了设备上卡成 PPT才开始考虑烘焙。但烘焙也不是万能的——动态物体在移动时无法实时接收烘焙阴影它和静态物体之间会出现穿帮。所以这里有个基本判断场景以静态为主尽量烘焙场景全是动态物体就多用实时灯光并控制数量或者用后面提到的 Forward 方案。3. 阴影调试实录从 Shadow Map 到三个翻车现场3.1 Shadow Map 的生成逻辑与 Bias 的意义阴影在 Unity 里的实现方式不是“光线追踪”而是Shadow Map阴影贴图。简单说引擎会在灯光的视角里放一台虚拟摄像机从灯光方向看向场景记录每个点到灯光的距离渲染成一张深度图。真正渲染主场景时只要判断某个像素的深度和阴影贴图里记录的距离是否一致比记录值远说明它在阴影里一致或更近说明能被灯光照到。这个“距离比较”过程中有个经典问题——精度有限。深度图的分辨率不可能无限大两个靠得很近的表面比如地面和紧贴地面的墙面根部会出现深度值几乎一样的状况导致渲染结果一会儿判定在阴影里、一会儿判定不在画面就出现了那种密密麻麻的闪烁斑点也就是Shadow Acne阴影粉刺。解决办法是给阴影判断加一个容差这个容差就是Shadow Bias阴影偏移。Unity 的 Light 组件上有两个关键参数Bias沿光线方向把判定距离往后推一点减少自阴影粉刺。Normal Bias沿法线方向把表面微微“鼓起”一点减少边缘的低频噪声。但这又引入了另一个问题偏移加得太多阴影会“飘”起来看起来物体像踩着高跷也就是常说的Peter Panning彼得潘现象因为影子仿佛不属于这个物体了。3.2 条纹、漂浮、闪烁三个最常见阴影问题的排查链路先说结论遇到阴影相关的视觉 bug第一件事不是调參数而是打开 Frame Debugger 管线逐帧看一遍确认阴影贴图渲染是否正常、主光源的阴影采样是否执行。确定是 Shadow Map 问题后再按下述排查。第一个问题阴影边缘有密集条纹。这种现象通常出现在大面积平面接受阴影的时候比如地板、墙面。排查思路就是看 Bias 是不是过小。你可以把 Light 的 Normal Bias 从默认的 1 调到 0.5 或更低然后观察条纹变化。如果改善不明显考虑提高阴影贴图分辨率在 URP 的 Render Pipeline Asset 里把 Shadow Resolution 从 Medium 提到 High。第二个问题阴影和物体之间出现漂浮间隙看起来像物体离开了地面。这时候反而要把 Bias 往回调小。我见过有人为了消除上一类条纹直接把 Bias 拉到 2、3结果整片阴影全悬空了。正确做法是同时调整 Bias 和 Shadow Resolution用更高分辨率替代无脑加 Bias。第三个问题远处阴影闪烁或直接消失。这通常是 Shadow Distance阴影距离设置和阴影贴图分辨率不匹配导致的。你把阴影距离拉到 300但阴影贴图只有 1024 分辨率远处的阴影会变成一片糊状闪烁。解决方式有两种降低 Shadow Distance让远处物体干脆没有阴影或者开启 Shadow Cascades级联阴影让近处阴影用高分辨率、远处用低分辨率。3.3 级联阴影与软阴影的取舍级联阴影是平行光专属的策略。平行光照射范围非常大整个场景都可能被覆盖如果用一张阴影贴图覆盖全局近处的地面阴影会糊成一团。所以引擎把摄像机的可视范围切成几层近处分配更高分辨率的阴影贴图远处分配低分辨率这就是 Shadow Cascades。在 URP 中默认是 4 个 Cascade画质较好但代价是阴影贴图要渲染 1 份还是 4 份的问题。实际测试下来Cascade 从 4 降到 2阴影相关的 GPU 消耗能明显下降视觉上只要你不是贴着地面细看差别不大。对移动端项目直接从 2 开始都是合理的。至于软阴影Soft Shadows它模拟的是“半影”效果即阴影边缘的过渡带。这个效果不是免费的——它本质上是多点采样等于阴影贴图采样次数直接翻倍。如果项目跑在低端机上建议把软阴影关掉用硬阴影配合合适的阴影贴图分辨率观感反而更干净。4. 前向渲染与延迟渲染两套流水线的真实成本4.1 前向渲染每盏灯都是 Draw Call前向渲染的逻辑很直观对于物体上的每个片元找出所有对该片元有影响的灯光然后把它们的光照结果叠加起来。但这会产生一个致命问题一个物体受多少盏实时灯光的逐像素影响就要重复渲染多少次。比如场景里一个角色同时被 5 盏灯照亮前向路径下角色模型要被渲染 5 次一次主渲染四次额外额外的光照 Pass如果这 5 盏灯还会投射阴影每个 Pass 都可能附带阴影贴图采样开销成倍增长。在实际操作中你可以在 Profiler 的 Rendering 模块里看 SetPass Calls如果发现一个物体的 SetPass 数量远超物体数量优先怀疑是不是实时灯光太多。新手最容易忽略的是即使灯光范围没有覆盖某些物体Unity 也会按照灯光影响范围做剔除但剔除的精度不是完全精确的尤其是聚光灯边缘误判还挺常见的。4.2 延迟渲染G-Buffer 的带宽账单延迟渲染为什么不怕灯光多因为它把光照计算推迟到了“屏幕空间”。第一步先把场景里不透明物体的颜色、法线、深度、金属度、粗糙度等数据分别写入几张纹理这几张纹理合起来叫G-Buffer几何缓冲。第二步对所有屏幕像素逐像素遍历灯光直接从 G-Buffer 里取数据计算光照。这样一来灯光数量对光照计算的影响就小了——不管场景里有多少盏灯每个像素的计算次数只跟覆盖该像素的灯光总数有关不再依赖物体数量。听起来很美代价在哪在带宽。G-Buffer 通常有 4~5 张纹理每张还是高精度格式。一张 1080p 的延迟渲染画面光是 G-Buffer 写入就是几百 MB 的显存开销。移动端的 GPU 带宽是稀缺资源跑延迟渲染很容易发热和掉帧。另外延迟渲染对半透明物体是不友好的——G-Buffer 只能存一层几何信息半透明物体之间没法做正确的遮挡混合所以引擎会把半透明物体单独用前向方式再渲染一遍。这又带来了新的排序问题。还有一个常见坑延迟渲染路径下 MSAA 抗锯齿往往不可用。因为中间多层缓冲都是浮点纹理MSAA 的支持很差。你想做全屏抗锯齿得靠 TAA、SMAA 这类后处理方案。这一条在 URP 里尤其明显切换渲染路径前先想清楚你的抗锯齿方案。4.3 不同平台怎么选PC、移动端、WebGLPC 端显存带宽充足灯光数量多就直接用延迟渲染。但延迟渲染对场景物体的材质有要求某些自定义 Shader 如果不兼容 G-Buffer 输出可能出现物体渲染成黑块、法线异常等问题。移动端能不用延迟就不用延迟。顶级手机无所谓大众机型的带宽是硬伤。而且移动端 GPU 的 tiled-based 架构天然更适合前向渲染很多引擎在移动端还额外做了 Tile Based DeferredTBD但这个不是你能在 Unity 里直接开关的。WebGL兼容性挑战最大。WebGL 1.0 时代基本只能前向WebGL 2.0 下 URP 支持了延迟渲染但能力受浏览器和低端设备限制。我在开发 WebGL 项目时默认都用前向渲染。遇到灯光多的情况优先用烘焙或实时光照剔除来优化而不是急着切延迟。5. 实战切换渲染路径并验证性能差异5.1 环境准备与路径切换步骤新建一个 URP 项目Unity 6 或 Unity 2022 LTS 都可以在 Project 窗口里找到Assets/Settings/URP-HighQuality这样的管线资产选中后在 Inspector 中找到Rendering Path默认是 Forward改成 Deferred。切换前先确认你的项目版本里是否显示“不支持的警告”——URP 的延迟渲染对平台有要求不同版本支持程度不一样。如果项目里有大量自定义 Shader切到延迟渲染后需要仔细观察画面看看是否有异常表现。我建议你手动搭一个测试场景不用太复杂一块地面平面三五成组的立方体、球体、胶囊体散落放置一盏平行光作为主光源阴影打开再加 6~10 盏点光源均匀分布在物体周围然后分别在前向和延迟模式下跑一遍。为什么要这么做因为这类场景最能暴露前向渲染“灯光数量导致多 Pass”的问题也最容易对比出两者在不同灯光数量下的帧率差异。5.2 Frame Debugger 带你逐帧看渲染过程为了真正理解渲染路径的差异打开Window Analysis Frame Debugger点击 Enable然后一帧一帧地看渲染流程。在前向渲染下你会看到类似这样的队列Depth Prepass如果开了深度纹理主光源 ShadowMap 渲染各种物体的 主发光 附加灯光 Pass屏幕空间特效等你会发现一个物体后面可能跟着好几个 “Light Pass” 的条目每多一盏灯光队列里就多一个。这就是前向路径“灯多卡顿”的直接证据。切成延迟渲染后队列会变成G-Buffer 预渲染G-Buffer Pass写入颜色、法线、深度等阴影贴图屏幕空间光照计算后处理你会看到大量信息被压缩在了几个“大 Pass”里灯光再多也是在屏幕空间里批量算桌面级 GPU 非常喜欢这种模式。这个工具绝对是新手进阶的利器——你不光能看流程还能检查每个 Pass 的 GPU Wait/GPU Time 和输入输出资源。5.3 Overdraw 与 SetPass Calls两个关键性能指标分析渲染性能时我经常让新手看两个量一个是Overdraw过度绘制一个是SetPass Calls。Overdraw 是指同一个像素被反复绘制多次。在 Scene 视图的 Shaded 模式下把显示模式切到 Overdraw画面越白的地方说明绘制重复次数越多。半透明粒子、大面积雾、大量带屏幕特效的 UI 都是重灾区。对灯光系统来说如果前向渲染下物体被多盏灯划分成多个 PassOverdraw 也会明显上升。SetPass Calls 是 Profiler 里一个重要数值。它代表渲染管线切换材质 Pass 的次数每切换一次都是不小的开销。在 Lighting 场景里前向渲染的 SetPass Calls 会随着灯光数量上升而上涨延迟渲染则稳很多。不过要提醒一句优化渲染不要光盯这些数字最终还是要看真机帧率和发热。用 Profiler 的 Rendering 模块多采集几轮数据同一场景前后向各跑一遍做好对比记录。哪种路径更适合你的项目数据会说话。6. 给新手的渲染配置速查与我的几点经验6.1 常见问题速查表现象可能原因解决方向地面或墙面上出现密密麻麻的暗斑/条纹Shadow Bias 太小产生阴影粉刺适当调大 Bias / Normal Bias提高阴影贴图分辨率阴影和物体分离像“飘着”Bias 或 Normal Bias 过大回拨偏移值用阴影分辨率换取清晰度远处阴影闪烁或突然消失Shadow Distance 过大、Cascade 不足减小 Shadow Distance增加 Cascade 级数场景整体过曝/全白平行光强度过高或环境光叠加过大降平行光强度调环境光模式和强度灯光越多帧率下降越明显前向渲染中每盏灯都在增加 Pass减少实时灯光转烘焙或切延迟路径延迟渲染下物体边缘锯齿明显MSAA 不可用通常只支持后处理抗锯齿开启 TAA/SMAA或切回前向渲染半透明物体在延迟渲染下表现异常透明物体走的是额外前向 Pass拆分渲染层级减少透明体之间交叉或换路径6.2 我踩过最深的坑和调试习惯我早期做过一个移动端数字孪生项目场景里放了十几盏实时光照的广告灯牌。测试机上帧率稳定在 30 以上心想问题不大。结果只改了阴影贴图分辨率一项帧率直接掉了 10 帧——罪魁祸首不是灯光的计算量而是阴影贴图渲染的尺寸太大加上级联阴影在移动端吃了大量带宽。那次之后我养成了一个习惯每次只改一个参数改完立刻在 Profile 里对比前后数据。这个习惯听起来基础但真的能帮你避免大量“越调越乱”的情况。新手调渲染参数时最容易犯的错就是一次性把所有旋钮都拧一遍结果画面坏了也不知道是哪一步改坏的。另一个值得说的经验是不要迷信“延迟渲染一定更好”。延迟渲染在 PC 大场景、屋内多光源、大世界夜晚效果里有绝对优势但中小型项目、低端设备、WebGL 场景下前向渲染配合烘焙往往更稳。我之前还见过有人为了延迟渲染重写了整个美术管线最后发现效果还不如前向渲染用点心烘焙来得好。6.3 给新手的路径选择经验浓缩版如果你是刚接触 Unity 渲染我给一条不会走错的路先做一个小场景就几面墙、几个箱子、一盏平行光加两三盏点光源。打开 Frame Debugger把渲染队列从头到尾看一遍认清楚每个 Pass 是干什么的。试着增加灯光数量观察 SetPass Calls 和帧率数字怎么变。切换前向/延迟路径再对比一次。最后结合你的目标平台来定方案。这套流程走下来你对渲染路径的理解就不会只是概念层面的“知道”而是真正能判断“这个场景为什么卡”“这盏灯该不该改为烘焙”。灯光和阴影这两个领域非常吃经验早一点学会用管线分析工具能少走很多弯路。
