1. 项目概述一个看似简单的需求引发的“渲染玄学”最近在项目里优化一个植被场景遇到了一个挺有意思的坑折腾了我大半天。需求很简单给一片使用了Dither抖动透明处理的草地加上正确的阴影。听起来是个标准操作对吧我一开始也是这么想的随手写了个Shader在编辑器里预览效果完美阴影清晰半透过渡自然。但当我切换了渲染路径进行性能测试时问题来了——在Forward Rendering前向渲染路径下阴影一切正常但切换到Deferred Rendering延迟渲染路径后这些草要么完全不接收阴影要么阴影断断续续、支离破碎像被狗啃过一样。这立刻引起了我的警觉。在Unity开发中渲染路径的选择直接影响光照和阴影的计算方式而Dither透明又是一种特殊的Alpha处理技术。当这两者相遇背后隐藏的管线差异就被放大了。这不仅仅是一个“为什么没阴影”的问题更是一个深入理解Unity不同渲染路径下片元着色器Fragment Shader如何与阴影贴图Shadow Map交互的绝佳案例。如果你也遇到过类似问题或者对Unity的阴影机制感到好奇那么这次踩坑经历或许能帮你避开不少弯路。本文将彻底拆解Forward和Deferred路径下为Dither透明物体添加阴影时产生差异的根本原因并提供经过实战检验的解决方案。2. 核心概念拆解Dither、阴影与渲染路径在深入问题之前我们必须先统一战场上的“语言”。理解这三个核心概念是解决所有后续问题的基石。2.1 Dither透明不是真透明是视觉欺骗首先我们得明确一点Dither抖动不是真正的Alpha混合透明。标准的透明渲染Alpha Blending需要物体按从后到前的顺序绘制并进行颜色混合对渲染状态和Draw Call顺序有严格要求性能开销大且容易出错。Dither技术则走了另一条路。它利用一个阈值矩阵通常是Bayer矩阵在像素级别对纹理的Alpha值进行“二值化”处理。简单来说对于一个想要显示为50%透明度的像素Dither算法不会让它和背景色混合成半透明而是通过一个固定的、有规律的棋盘格图案让这个像素要么完全显示不透明要么完全丢弃透明。从远处看人眼会将这些离散的黑白点混合感知为平滑的渐变透明效果。在Shader中一个典型的Dither透明裁剪核心代码如下在片元着色器中// 引入Unity内置的dithering纹理和函数 #include “UnityCG.cginc” #include “AutoLight.cginc” float4 frag (v2f i) : SV_Target { // ... 计算颜色和Alpha值 float alpha tex2D(_MainTex, i.uv).a * _Color.a; // 关键步骤基于屏幕空间位置进行Dither测试 float2 screenPos i.screenPos.xy / i.screenPos.w; // 获取NDC坐标 screenPos * _ScreenParams.xy; // 转换到像素坐标 // 使用Unity内置函数计算Dither因子 float dither UnityDither(screenPos, alpha); // 如果计算出的dither值小于0则丢弃该像素实现“透明” clip(dither); return col; }它的本质是一种像素裁剪clip。被clip的像素不会进入后续的混合阶段因此它不依赖渲染顺序性能更好常用于草地、毛发、粒子等需要大量半透明物体的场景。但正是这个“裁剪”行为为后续的阴影计算埋下了伏笔。2.2 Unity的阴影机制Shadow Map与深度测试Unity以及大多数现代图形引擎的实时阴影基于Shadow Mapping阴影贴图技术。其原理可以概括为三步从光源视角渲染将场景从灯光的角度渲染一次但只记录每个像素距离光源的最近深度值生成一张“深度图”这就是阴影贴图。从相机视角渲染正常渲染场景。对于屏幕上的每一个像素片元将其世界坐标转换回光源的视角空间。深度比较将该像素转换后的深度值与阴影贴图中对应位置存储的深度值进行比较。如果像素深度大于阴影贴图深度意味着该像素在光源和最近物体之间还有遮挡物则该像素处于阴影中。这个过程高度依赖深度信息的准确性。在Forward路径中这个比较通常发生在片元着色器里通过UNITY_LIGHT_ATTENUATION宏或SHADOW_ATTENUATION函数来完成。而在Deferred路径中深度信息存储在G-Buffer中阴影计算是在所有几何信息都收集完毕后在另一个屏幕空间Pass中统一进行的。2.3 Forward vs Deferred两条截然不同的渲染管线这是问题的核心矛盾所在。两种路径处理光照和阴影的逻辑有本质区别Forward Rendering前向渲染过程“几何” - “光照/阴影”一体化。对于每个物体在绘制它的同时就根据影响它的灯光在片元着色器中立即计算该点的光照颜色和阴影衰减。一个物体可能因为多盏灯而被绘制多次Additive Passes。特点光照计算与物体材质、Shader紧密耦合。阴影信息Shadow Map作为纹理输入在物体的着色器Pass内直接采样和计算。Dither裁剪发生在光照和阴影计算之后在同一Pass内因此裁剪不影响该像素之前已经计算好的阴影结果。Deferred Rendering延迟渲染过程“几何” - “光照/阴影”分离。第一步Geometry Pass将所有不透明物体的表面信息位置、法线、颜色、材质属性等渲染到一组叫做G-Buffer的纹理中。Dither透明物体通常无法写入G-Buffer因为它们的像素可能被裁剪无法提供完整、确定的表面信息。第二步Lighting Pass用一个全屏的Quad针对屏幕上的每一个像素读取G-Buffer中的信息统一计算所有灯光的光照和阴影。特点光照计算与几何物体解耦性能受灯光数量影响小但无法很好地处理透明和多重材质。关键点在于Dither物体在第一阶段就被排除在外了它们的几何信息没有进入G-Buffer因此在第二阶段的全屏光照计算中系统根本“不知道”这些草地的存在自然也无法为它们计算阴影。注意这里有一个常见的误解。很多人认为Deferred Path下透明物体完全无法处理阴影其实不然。Unity的Deferred渲染器有一个“Forward透明通道”。对于标为Transparent或AlphaTest的渲染队列的物体Unity会在Deferred的Geometry Pass之后额外用一个Forward Pass来绘制它们。但问题在于这个Forward Pass的光照和阴影计算环境与纯Forward路径下的计算环境可能存在差异特别是阴影的初始化、传递和衰减计算方式。3. 问题根因深度剖析信息链的断裂与重构理解了基础原理我们现在可以精准定位问题所在。Forward和Deferred路径下结果不一致根本原因在于渲染管线中几何信息、深度信息与阴影计算逻辑的传递链条在不同路径下发生了断裂。3.1 Forward路径为何它能“正常”工作在Forward路径下渲染是一个相对线性的过程。对于使用了Dither的Shader顶点着色器输出顶点信息。片元着色器按顺序执行 a. 采样纹理计算颜色和初始Alpha。 b.计算阴影衰减通过UNITY_LIGHT_ATTENUATION采样Shadow Map进行深度比较得到一个阴影衰减系数例如1.0表示完全受光0.0表示完全在阴影中。 c.应用Dither裁剪基于屏幕坐标和Alpha值计算dither因子执行clip(dither)。如果像素被丢弃则后续流程终止。 d.计算光照并混合将阴影衰减系数应用于光照计算最终输出颜色。关键顺序是先算阴影再裁剪。即使这个像素最终因为Dither测试被丢弃了但在它被丢弃之前阴影衰减已经计算完毕并可以正常应用。所以我们看到了正确的阴影效果。阴影信息是“附着”在物体绘制过程中的。3.2 Deferred路径信息在何处丢失在Deferred路径下流程被拆解问题就出在拆解的接缝处。Geometry Pass此Pass的目标是填充G-Buffer包括深度、法线、颜色等。对于使用clip()进行像素裁剪的Shader包括Dither和传统的Alpha TestUnity的标准G-Buffer着色器通常会直接跳过或无法正确处理。因为这些像素的不确定性可能被丢弃违背了G-Buffer需要确定表面信息的假设。因此这些Dither草地的深度、法线等信息很可能根本没有被写入G-Buffer。它们在第一关就被淘汰了。透明物体的Forward Pass由于Geometry Pass失效Unity会尝试将这些物体放入“Forward透明通道”渲染。这个通道是前向渲染。但是这个特殊的Forward通道与默认的Forward渲染路径配置可能不同。最大的疑点在于阴影数据的传递。在标准Forward中阴影数据通过unity_WorldToShadow等矩阵和阴影贴图纹理数组传递。在Deferred的透明通道中阴影计算可能依赖一套不同的机制或者对深度值的来源有特殊要求例如从G-Buffer的深度纹理中重建世界坐标而非从当前渲染的顶点信息计算。如果Dither物体的深度没有正确参与这场“坐标重建”那么从光源视角进行的深度比较就会出错导致阴影计算失效或产生噪点。核心矛盾Deferred路径下Dither物体无法在主流管线G-Buffer中提供深度而在备用管线透明Forward通道中其深度信息与阴影计算所需的上下文可能不匹配导致阴影链断裂。3.3 一个被忽略的开关AlphaToMask在搜索和测试中AlphaToMask是一个高频出现的相关关键词。它本质上是一种硬件特性利用多重采样抗锯齿MSAA的Coverage Mask来实现Alpha Test的效果比传统的clip指令在某些硬件上更高效。但关键在于AlphaToMask在Deferred路径下的行为可能与Forward不同。Unity文档中往往有不起眼的备注指出某些渲染特性在Deferred下不受支持或行为有异。如果你的Dither Shader启用了AlphaToMask这可能是另一个导致差异的因素。更稳妥的方式是坚持使用标准的clip指令进行Dither测试。4. 实战解决方案让阴影在两条路径下都正确显示分析了原因解决方案就有了方向。我们的目标是在Deferred路径下为Dither物体“补全”那条断裂的信息链。这里提供几种经过验证的方案从易到难。4.1 方案一使用双Pass Shader兼容性方案这是最直观、兼容性最好的方法。既然Deferred的透明通道是Forward那我们就在Shader中显式地定义两个Pass一个用于Deferred路径下的透明渲染另一个用于Forward路径。Shader “Custom/DitherGrassWithShadow” { Properties { ... } SubShader { Tags { “Queue”“AlphaTest” “RenderType”“TransparentCutout” } // Pass 1: 用于Deferred Rendering的透明通道 Pass { Tags { “LightMode” “ForwardBase” } // 明确指定为前向基础光照 // 关键关闭剔除确保草的两面都能写入深度可选根据模型调整 Cull Off // 关键使用Alpha to Coverage可能更稳定 AlphaToMask On CGPROGRAM #pragma vertex vert #pragma fragment frag #pragma multi_compile_fwdbase // 关键为这个Pass单独编译一个着色器变体避免使用 deferred 相关的关键字 #pragma multi_compile _ UNITY_HDR_ON // 示例根据需求添加 // 在这个Pass的片元着色器中你需要 // 1. 计算Dither并进行clip。 // 2. 使用 SHADOW_COORDS, TRANSFER_SHADOW, SHADOW_ATTENUATION 这一套传统Forward阴影宏。 // 注意这里不能依赖UNITY_LIGHT_ATTENUATION因为那个宏在Deferred的透明Pass中可能未正确定义。 // 改为手动计算阴影 fixed shadow SHADOW_ATTENUATION(i); fixed3 lighting _LightColor0.rgb * (shadow * dot(normal, lightDir)); … ENDCG } // Pass 2: 用于纯Forward Rendering路径当项目设置为Forward时 Pass { Tags { “LightMode” “ForwardBase” } // 可以在这里使用你原来工作正常的Forward Shader代码 // 包含标准的 #pragma multi_compile_fwdbase 和 UNITY_LIGHT_ATTENUATION … } } FallBack “Legacy Shaders/Transparent/Cutout/VertexLit” // 一个可靠的Fallback }实操心得这种方法实质上是为Deferred路径“定制”了一个它认识且能正确处理阴影的Forward Pass。你需要仔细管理两个Pass的代码确保它们视觉效果一致。FallBack选择一个简单的Cutout Shader有时能解决一些奇怪的兼容性问题。4.2 方案二深度写入与Shadow Caster Pass治本方案方案一是“绕开”问题方案二则是尝试“解决”信息链断裂。思路是确保Dither物体能向深度缓冲区写入有效的深度信息。添加一个专用的Shadow Caster Pass Unity在计算阴影贴图Shadow Map时默认会寻找Shader中的ShadowCasterPass。如果我们不定义它会使用Fallback Shader的这可能不支持Dither裁剪。我们需要自己写一个确保在生成阴影贴图时也执行相同的Dither裁剪逻辑这样物体的阴影轮廓才是正确的。Pass { Name “ShadowCaster” Tags { “LightMode” “ShadowCaster” } CGPROGRAM #pragma vertex vertShadow #pragma fragment fragShadow #pragma multi_compile_shadowcaster #pragma fragmentoption ARB_precision_hint_fastest #include “UnityCG.cginc” struct v2fShadow { V2F_SHADOW_CASTER; float2 uv : TEXCOORD1; float4 screenPos : TEXCOORD2; }; v2fShadow vertShadow(appdata_base v) { … } // 转换坐标传递UV和屏幕位置 float4 fragShadow(v2fShadow i) : SV_Target { // 执行和主Pass一模一样的Dither Alpha测试 float alpha tex2D(_MainTex, i.uv).a * _Color.a; float2 screenPos i.screenPos.xy / i.screenPos.w; screenPos * _ScreenParams.xy; float dither UnityDither(screenPos, alpha); clip(dither); SHADOW_CASTER_FRAGMENT(i) // 这个宏会处理深度输出 } ENDCG }在Deferred中考虑深度预写入 这是一个更进阶的思路。在SubShader的最前面增加一个只写入深度、不输出颜色的PassLightMode可以是ShadowCaster或DepthOnly。这个Pass只做Dither测试和深度写入目的是在Geometry Pass之前先把Dither物体的有效深度经过裁剪后的写进深度缓冲区。这样后续无论是G-Buffer生成还是阴影计算都能读到正确的深度关系。但这需要非常精细的渲染状态控制且可能带来Overdraw需性能权衡。注意事项ShadowCasterPass中的顶点变换必须和主Pass保持一致否则阴影形状会错位。确保用于Dither计算的屏幕坐标或投影坐标是正确的。4.3 方案三渲染路径检测与动态分支如果你希望一个Shader代码能同时完美适配两种路径可以在Shader中使用编译指令#ifdef进行动态分支。#ifdef UNITY_PASS_FORWARDBASE // 这是Forward路径下的阴影计算代码 UNITY_LIGHT_ATTENUATION(atten, i, i.worldPos); fixed shadow atten; #else // 这是Deferred透明通道或其他情况下的阴影计算代码 // 可能需要手动采样阴影贴图 // 或者使用一个更保守的、兼容性更好的计算方法 fixed shadow 1.0; // 临时回退值需要替换为实际计算 #endif同时你还可以根据是否启用了延迟渲染来微调Dither的阈值或算法以补偿两种路径下光照模型的细微差异。这需要大量的测试和调整。4.4 方案评估与选型建议方案一双Pass推荐给大多数项目。它逻辑清晰分离度高调试方便。虽然Shader代码量稍大但稳定性最好能确保在两种路径下都有可接受的表现。方案二深度/ShadowCaster Pass推荐给对阴影质量要求极高的项目。这是最“正确”的图形学解决方案能从根源上保证深度信息一致。特别是添加自定义的ShadowCasterPass是所有生产级植被/毛发Shader的标配。方案三动态分支适合Shader专家和追求单一文件简洁性的情况。它保持了代码的统一性但内部逻辑复杂调试困难且容易因为Unity版本更新或平台差异引入新问题。个人实践在我的植被项目中我最终采用了方案一 方案二的组合。即一个双Pass的Shader结构并且在每个Pass中都明确定义了功能完整的ShadowCasterPass。这样就保证了在Forward路径下使用优化过的Forward光照和阴影。在Deferred路径下使用为其定制的Forward透明通道。在任何路径下生成阴影贴图时都使用相同的Dither裁剪逻辑保证阴影轮廓精准。5. 调试技巧与常见问题排查实录即使按照上述方案修改了Shader在实际项目中仍可能遇到各种稀奇古怪的问题。这里分享一些实用的调试技巧和常见坑点。5.1 调试工具用Frame Debugger和RenderDoc抓“现行犯”Unity Frame Debugger这是第一利器。在Deferred路径下出问题时打开Frame Debugger逐步执行渲染命令。找到渲染你的Dither物体的那个Draw Mesh命令。看看它属于哪个Pass是Render Opaque不可能还是Render Forward如果是后者说明它确实被归到了透明Forward通道。点击该命令查看其渲染状态Render State。重点看深度写入ZWrite是否开启深度测试ZTest函数是什么模板缓冲Stencil是否有特殊设置这些状态可能被Unity的Deferred渲染器修改与你Shader中定义的不符。查看该Pass输出的渲染目标Render Target。是G-Buffer中的某一项还是最终的屏幕颜色这能立刻告诉你它走的是哪条管线。RenderDoc如果Frame Debugger信息不够就需要祭出更强大的图形调试器。用RenderDoc抓取一帧你可以精确查看顶点着色器输入和片元着色器输出确认传递给阴影计算函数的坐标、深度值是否正确。查看阴影贴图本身确认其内容是否正常生成你的Dither物体在阴影贴图里是否被正确裁剪。对比Forward和Deferred两帧的渲染流水线逐纹理、逐缓冲区比对差异。5.2 常见问题速查表问题现象可能原因排查步骤与解决方案Deferred下完全无阴影1. Shader未在Deferred透明通道中执行。2. 阴影计算代码在对应Pass中未编译或错误。1. Frame Debugger确认绘制命令是否存在及其Pass。2. 检查Shader的LightModeTag是否正确确保使用了#pragma multi_compile_fwdbase等必要指令。3. 简化Shader先移除Dither测试一个纯色透明物体是否有阴影。阴影闪烁、撕裂或噪点严重1.深度冲突Z-fightingDither裁剪后的深度与附近物体深度值过于接近。2. 阴影贴图分辨率不足在Dither造成的复杂边缘上采样问题被放大。3. Dither算法引入的随机性与阴影PCF百分比渐近过滤滤波不匹配。1. 轻微调整物体的Z值或缩放或使用Offset指令。2. 提高光源的阴影贴图分辨率或使用软阴影。3. 尝试更稳定的Dither图案如蓝噪声或在阴影计算前对Alpha进行轻微模糊性能开销大。阴影颜色/明暗不正确1. 在Deferred的透明通道中环境光、光照衰减等计算与标准Forward不同。2. 阴影衰减系数被错误地应用了多次。1. 在Frame Debugger中对比Forward和Deferred下片元着色器输出的颜色值。2. 手动计算光照避免使用可能行为不一致的Unity内置光照宏改用ShadeSH9等函数计算环境光。只有某些视角/距离下有阴影1. 相机的远裁剪面或深度缓冲区精度问题。2. Unity的视锥体剔除Frustum Culling或批处理Batching影响了物体渲染状态。1. 检查相机设置调整远近裁剪面。2. 在Shader中禁用批处理DisableBatching True因为批处理可能会合并网格干扰基于单个物体空间的Dither计算。切换到Deferred后帧率暴降1. 双Pass Shader导致Draw Call翻倍。2. 复杂的Dither/阴影计算在Deferred的屏幕空间Pass中执行计算量激增。1. 使用GPU Instancing或SRP Batcher来合并Draw Call。2. 优化片元着色器减少纹理采样和复杂计算。考虑使用更廉价的Dither算法。5.3 一个关键的检查点Shader编译变体Unity Shader的#pragma multi_compile会生成大量变体。你必须确认在Deferred渲染路径下你的Shader是否成功编译出了包含正确阴影计算代码的变体。在编辑器里查看编译后的Shader检查关键指令是否存在。有时因为缺少某个关键的多重编译指令导致在特定渲染路径下阴影计算代码被整个剔除了从而完全失效。这次踩坑经历再次印证了图形渲染中一个朴素的道理看起来一样的效果背后的管线可能天差地别。对于Unity开发者而言明确项目所用的渲染路径并深入理解该路径下着色器、光照和阴影的工作流程是解决一切渲染诡异问题的前提。对于Dither这类非标准混合技术更需要我们主动去适配管线的要求通过添加必要的Pass、明确渲染状态和精细调试来弥合不同路径之间的鸿沟。最终我那个草地场景在两种渲染路径下都获得了稳定、正确的阴影虽然Shader代码变得稍微复杂了一些但换来的是渲染结果的一致性和可预测性这笔交易无疑是值得的。