URP半透明渲染深度排序优化：Shader与Renderer Feature实战

1. 半透明渲染的痛点与URP管线特性拆解

做过Unity项目的人大概率都遇到过这种场景：一个玻璃杯、一片树叶、一团烟雾，或者角色身上半透明的披风，在镜头转动到某些角度时，突然出现奇怪的色块、闪烁的条纹，或者前后层叠关系完全错乱。这不是美术资源的问题，也不是显卡驱动的问题，而是半透明物体渲染排序这个老生常谈的坑在作祟。

我最近在一个URP项目中就踩到了这个坑。场景里有一组半透明的能量护盾，多层叠加在一起，还带自交叠结构。用默认设置跑起来，镜头稍微一转，护盾内部就出现明显的深度冲突，前后层忽明忽暗，像极了早期3D游戏里的Z-fighting。更麻烦的是，这个问题在编辑器里预览时有时不明显，打包到真机上就暴露得很彻底。

这篇文章就是围绕这个具体问题展开的。我会把URP下半透明物体深度排序的机制拆开讲清楚，说明为什么默认方案会出问题，然后给出几套经过实测的优化方案，从Shader层面的深度写入策略，到Renderer Feature的自定义排序，再到工程层面的分层管理。内容适合有一定Unity基础、正在做URP项目、被半透明渲染瑕疵困扰的开发者。如果你刚接触URP，也能从中学到半透明渲染的基本原理和排查思路。

1.1 URP半透明渲染的基本流程

URP的渲染顺序和内置管线有本质区别。内置管线里，半透明物体默认走的是Transparent队列，按物体中心到相机的距离从远到近排序，然后逐个渲染，关闭深度写入但保留深度测试。URP继承了这个基本逻辑，但在Renderer层面做了更多控制。

具体来说，URP的UniversalRenderer在渲染半透明物体时，会经历这几个阶段：首先是不透明物体渲染，写入深度缓冲；然后是深度预pass（如果开启了Depth Priming）；接着是半透明物体排序和渲染。排序的依据主要是Renderer.sortingFudge、材质队列值、以及物体包围盒中心到相机的距离。

这里有个关键点：URP默认使用物体包围盒中心点来计算排序距离，而不是逐像素或逐三角形的深度。这就意味着，对于一个自交叠的半透明物体，比如一个弯曲的护盾或者多层叠加的粒子系统，包围盒中心只有一个，但物体表面的不同部分到相机的实际距离差异很大。排序算法无法区分这些差异，导致渲染顺序和实际深度关系不匹配，最终出现视觉瑕疵。

1.2 自交叠半透明物体的渲染瑕疵成因

自交叠半透明物体的渲染瑕疵，本质上是一个排序粒度问题。我画个简单的示意：假设有一个半透明的球体，球体正面和背面到相机的距离不同。如果球体被当作一个整体来排序，那么它要么整体在某个物体前面，要么整体在后面。但球体自身的正面和背面之间也存在遮挡关系，这个关系在单次绘制中是无法正确处理的。

在URP中，半透明物体默认关闭深度写入（ZWrite Off），这意味着每个半透明片元在渲染时不会更新深度缓冲。当同一个物体的不同部分互相重叠时，后绘制的片元会直接覆盖先绘制的片元，而不管它们的实际深度谁更近。如果绘制顺序恰好是背面先画、正面后画，那结果看起来是对的；但如果顺序反了，正面先画、背面后画，背面就会错误地覆盖正面，产生视觉上的“穿透”效果。

更复杂的情况是多层半透明物体互相嵌套。比如护盾A在护盾B内部，护盾B又在护盾C内部。如果排序算法把A排在了C后面，那么C会覆盖A，但实际空间关系是A在C前面。这种错误在镜头运动时尤其明显，因为排序结果会随着相机位置变化而跳变，产生闪烁。

1.3 为什么默认排序在URP中不够用

URP的默认排序策略在大多数简单场景下是够用的，比如一堆独立的半透明物体，彼此之间没有交叠，或者交叠很少。但一旦遇到自交叠结构，或者多个半透明物体在深度上交错排列，默认策略就力不从心了。

我实测过一个典型案例：场景中有三个半透明的环形护盾，它们互相嵌套，且每个护盾自身有前后两层表面。用URP默认设置渲染，镜头从侧面看时，护盾的前后层关系完全错乱，内层护盾有时会盖住外层护盾，有时又被外层盖住，闪烁非常严重。用Frame Debugger抓帧后发现，URP把三个护盾按包围盒中心排序，但每个护盾的包围盒中心几乎在同一深度上，排序结果基本是随机的。

这个问题的根源在于，URP的排序是物体级别的，而半透明渲染需要的是片元级别的深度关系。要解决这个问题，要么在Shader层面做文章，要么在渲染管线层面插入自定义的排序逻辑，要么从工程层面把复杂物体拆分成多个简单物体。下面我会逐一展开这几套方案。

2. 核心优化方案与Shader层面深度控制

解决半透明自交叠渲染瑕疵，最直接的手段是在Shader层面控制深度写入和渲染顺序。这一章我会详细讲几种Shader层面的策略，包括双Pass渲染、深度预写入、以及基于Alpha的深度偏移。每种方案都有适用场景和代价，我会结合实测数据说明什么时候该用哪种。

2.1 双Pass方案：先写深度再渲染颜色

双Pass方案的核心思路是：第一个Pass只写入深度，不输出颜色；第二个Pass正常渲染半透明颜色，但关闭深度写入。这样做的目的是让半透明物体在渲染颜色之前，先把自身的深度信息写入深度缓冲，从而让后续的片元能够正确地进行深度测试。

具体实现上，第一个Pass的Shader代码大概是这样：

Pass { Name "DepthOnly" Tags { "LightMode" = "DepthOnly" } ZWrite On ColorMask 0 Cull Back HLSLPROGRAM #pragma vertex vert #pragma fragment frag half4 frag() : SV_Target { return 0; } ENDHLSL }

第二个Pass保持正常的半透明渲染设置：

Pass { Name "ForwardLit" Tags { "LightMode" = "UniversalForward" } ZWrite Off Blend SrcAlpha OneMinusSrcAlpha // 正常的半透明渲染逻辑 }

这个方案的效果立竿见影。我实测下来，对于单层自交叠的半透明物体，比如一个弯曲的玻璃管，双Pass方案能消除绝大部分深度冲突。原因是深度预写入让物体的背面深度先被记录下来，正面渲染时就能正确通过深度测试，不会被背面错误覆盖。

但双Pass方案有个明显的代价：它会让半透明物体对自身产生正确的遮挡，但也会对后面的其他半透明物体产生遮挡。如果场景中有多个半透明物体互相重叠，第一个物体的深度预写入可能会错误地遮挡第二个物体。所以这个方案更适合孤立的自交叠物体，或者物体之间深度关系明确、不需要互相透视的场景。

注意：双Pass方案在移动端上会增加一次Draw Call，对于Draw Call敏感的项目需要权衡。另外，如果物体本身有顶点动画或骨骼动画，两个Pass的顶点变换必须完全一致，否则深度信息会对不上。

2.2 深度预写入与Alpha To Coverage的取舍

除了双Pass，还有一种更轻量的方案是使用Alpha To Coverage（ATC）。ATC的原理是把Alpha值转换成多采样抗锯齿（MSAA）的覆盖掩码，从而在开启MSAA的情况下实现半透明边缘的深度写入。这个方案的好处是不需要额外的Pass，直接在原Pass上开启即可。

在URP中开启ATC的Shader设置：

Pass { Tags { "LightMode" = "UniversalForward" } ZWrite On AlphaToMask On Blend SrcAlpha OneMinusSrcAlpha // 片元着色器输出Alpha }

ATC的效果取决于MSAA的采样数。4x MSAA下，Alpha会被量化成5个等级（0、0.25、0.5、0.75、1.0），边缘过渡会有明显的阶梯感。8x MSAA下会好一些，但移动端开启8x MSAA的性能开销不小。

我实测对比过双Pass和ATC在同一个护盾模型上的表现。双Pass的深度正确性更好，边缘也更平滑，但Draw Call翻倍；ATC的Draw Call不变，但边缘有锯齿，且深度写入的精度受MSAA采样数限制。如果项目对性能敏感且能接受一定的边缘瑕疵，ATC是更划算的选择；如果追求画质且Draw Call预算充足，双Pass更稳妥。

还有一个折中方案是使用Depth Priming。URP的Depth Priming模式会先渲染一遍不透明物体的深度，然后在半透明渲染时利用这个深度缓冲。但这个模式对半透明自交叠的帮助有限，因为它只处理不透明物体的深度，半透明物体自身的深度关系仍然需要额外处理。

2.3 基于视图空间的深度偏移技巧

有时候我们不需要完整的深度写入，只需要让半透明物体的不同部分在排序时有一个合理的先后关系。这时候可以用视图空间的深度偏移（View Space Depth Offset）来微调。

思路是在顶点着色器中计算顶点在视图空间中的深度，然后根据这个深度对顶点位置做一个微小的偏移。这样，物体的不同部分在排序时就会有不同的深度值，排序算法就能区分它们的前后关系。

float4 vert(float4 vertex : POSITION) : SV_POSITION { float4 viewPos = mul(UNITY_MATRIX_MV, vertex); float depthOffset = viewPos.z * 0.001; // 根据深度做微小偏移 viewPos.z += depthOffset; return mul(UNITY_MATRIX_P, viewPos); }

这个技巧的关键在于偏移量的选择。偏移太大，物体会看起来变形；偏移太小，排序算法仍然无法区分。我一般会先用0.001到0.01之间的值测试，根据物体尺寸和相机距离调整。

这个方案的局限性也很明显：它只能处理深度差异较大的自交叠，对于深度差异很小的部分，偏移量很难精确控制。而且偏移会导致物体在视觉上轻微变形，对于精度要求高的场景不适用。

2.4 方案对比与选型建议

为了更直观地对比这几种方案，我整理了一个表格：

选型的时候，我一般会先问自己几个问题：场景里有多少半透明物体？它们之间有没有交叠？目标平台是什么？画质和性能的优先级怎么排？回答完这几个问题，方案基本就确定了。

3. Renderer Feature自定义排序与工程实践

Shader层面的方案能解决单个物体的自交叠问题，但多个半透明物体之间的排序错误，就需要在渲染管线层面动手了。URP提供了Renderer Feature机制，允许我们在渲染流程中插入自定义的Pass。这一章我会讲如何用Renderer Feature实现自定义的半透明排序，以及工程层面的一些实用技巧。

3.1 Renderer Feature插入自定义半透明Pass

URP的UniversalRenderer在渲染半透明物体时，会调用RenderObjects相关的逻辑。我们可以通过Renderer Feature来拦截这个流程，插入自己的排序和渲染逻辑。

一个基本的自定义半透明Renderer Feature结构如下：

public class CustomTransparentSortFeature : ScriptableRendererFeature { class CustomTransparentPass : ScriptableRenderPass { public override void Execute(ScriptableRenderContext context, ref RenderingData renderingData) { // 获取半透明物体列表 // 按自定义规则排序 // 逐个渲染 } } public override void Create() { // 初始化Pass } public override void AddRenderPasses(ScriptableRenderer renderer, ref RenderingData renderingData) { // 插入Pass到渲染流程 } }

在Execute方法中，我们可以通过renderingData.cullResults获取所有可见物体，然后筛选出半透明物体，按自定义规则排序。排序规则可以基于物体包围盒的最近点、最远点，或者基于物体在视图空间中的深度范围。

我实测过一种排序策略：计算每个半透明物体包围盒的八个顶点在视图空间中的深度，取最小值和最大值，然后按最小值从远到近排序。这个策略比默认的包围盒中心排序更准确，因为它考虑了物体的深度范围。对于深度范围重叠的物体，可以再按最大值做二次排序。

3.2 基于包围盒最近点的排序策略

默认的包围盒中心排序在物体尺寸差异大或者物体深度范围重叠时容易出错。基于包围盒最近点的排序策略，是取物体包围盒上离相机最近的点的深度作为排序依据。这样，即使两个物体的中心深度相同，最近点深度更远的物体会被先渲染，从而保证前面的物体后渲染、正确覆盖。

计算包围盒最近点深度的代码大概是这样：

float GetClosestDepth(Bounds bounds, Camera camera) { Vector3[] corners = new Vector3[8]; corners[0] = bounds.min; corners[1] = bounds.max; // ... 填充八个顶点 float minDepth = float.MaxValue; foreach (var corner in corners) { Vector3 viewPos = camera.worldToCameraMatrix.MultiplyPoint(corner); minDepth = Mathf.Min(minDepth, -viewPos.z); } return minDepth; }

这个策略对于大多数场景都能显著改善排序质量。我实测下来，在一个有20个半透明物体的场景中，默认排序有大约30%的帧会出现明显的排序错误，换成最近点排序后，错误率降到了5%以下。

但最近点排序也有它的局限：当两个物体的包围盒在深度上完全重叠时，最近点深度几乎相同，排序仍然可能出错。这时候需要更细粒度的排序，比如基于物体表面的实际深度分布，或者干脆把物体拆分成更小的部分。

3.3 分层渲染与队列值精细化管理

除了自定义排序，工程层面还有一个很实用的技巧：通过材质队列值（Render Queue）来手动控制渲染顺序。URP的渲染队列值范围是0到5000，其中2500以下是不透明队列，2500以上是半透明队列。我们可以给不同的半透明物体分配不同的队列值，强制它们按我们期望的顺序渲染。

比如，场景中有三层护盾，从内到外分别是A、B、C。我们可以设置A的队列值为3000，B为3001，C为3002。这样URP会先渲染A，再渲染B，最后渲染C。如果相机是从外向内看，C会覆盖B，B会覆盖A，看起来就是正确的层叠关系。

这个方法的优点是简单直接，不需要写任何代码。缺点是队列值是静态的，如果相机位置变化导致前后关系反转，排序就会出错。所以它只适用于相机位置相对固定、或者物体前后关系不会反转的场景。

对于相机位置会变化的场景，可以结合脚本动态调整队列值。在每帧的OnPreRender或OnPreCull中，根据相机位置重新计算物体的前后关系，然后更新队列值。这个方案的开销主要在脚本计算上，对于物体数量不多的场景完全可接受。

3.4 工程实践中的分层与拆分策略

有时候，最有效的优化不是技术手段，而是工程手段。把复杂的自交叠半透明物体拆分成多个简单的、不交叠的子物体，可以从根源上避免排序问题。

比如，一个多层嵌套的护盾，可以拆分成三个独立的环形网格，每个网格自身不交叠，然后通过队列值或自定义排序控制它们之间的顺序。这样每个网格的渲染都是简单的，不需要复杂的深度处理。

拆分的代价是Draw Call增加，但换来的是渲染正确性和可维护性。我一般会在美术制作阶段就要求把复杂半透明物体拆分成合理的子物体，而不是等到渲染出问题了再回头改。

另一个工程技巧是使用Sorting Group组件。Unity的Sorting Group可以把多个Renderer当作一个整体来排序，同时保持内部的排序关系。对于由多个部分组成的半透明物体，Sorting Group能简化排序管理。

提示：拆分物体时要注意子物体之间的接缝处理。如果子物体之间有重叠区域，重叠部分的半透明混合可能会出现双重混合，导致颜色偏深。解决办法是让子物体在接缝处稍微错开，或者使用相同的混合模式并确保重叠区域只渲染一次。

4. 常见问题排查与性能优化实录

这一章我整理了一些在实际项目中遇到的典型问题，以及排查和解决的过程。这些问题有些是URP特有的，有些是半透明渲染的通用问题，但都在URP环境下有特定的表现和解决方案。

4.1 半透明物体闪烁与深度冲突排查

闪烁是半透明渲染中最常见的问题，表现为物体表面出现不规则的亮暗变化，或者前后层关系在帧与帧之间跳变。排查闪烁问题，我一般按这个顺序来：

第一步，用Frame Debugger抓帧，看半透明物体的渲染顺序。如果顺序在帧之间变化，说明排序不稳定。排序不稳定的原因可能是物体包围盒中心深度接近，或者相机运动导致排序结果跳变。

第二步，检查材质的ZWrite和ZTest设置。半透明物体通常应该是ZWrite Off、ZTest LEqual。如果ZWrite被错误地开启了，会导致深度缓冲被半透明物体污染，影响后续物体的渲染。

第三步，检查是否有多个半透明物体使用了相同的队列值。相同队列值的物体排序是不确定的，容易导致闪烁。给它们分配不同的队列值，或者用自定义排序来稳定顺序。

第四步，检查相机的近裁剪面和远裁剪面设置。近裁剪面太小会导致深度精度下降，加剧深度冲突。我一般会把近裁剪面设置在0.1到0.3之间，根据场景尺度调整。

我遇到过一个案例，闪烁的根源是相机的Near Clip设成了0.01，导致深度缓冲精度严重不足。把Near Clip改成0.1后，闪烁问题基本消失。这个坑很隐蔽，因为0.01的近裁剪面在编辑器里看起来没问题，但在实际渲染中深度精度已经不够用了。

4.2 移动端半透明渲染的性能陷阱

移动端上半透明渲染的性能问题比桌面端严重得多，主要原因是移动端GPU的带宽有限，半透明渲染的Overdraw会迅速耗尽带宽。我在移动端项目上踩过的坑包括：

第一个坑是过度使用全屏半透明特效。比如全屏的雾气、光晕、扭曲效果，这些效果在桌面端跑得很流畅，但在移动端上会带来巨大的Overdraw。解决办法是尽量用不透明或Alpha Test替代半透明，或者降低特效的分辨率。

第二个坑是半透明粒子的过度堆叠。粒子系统很容易产生大量半透明片元，如果粒子数量多、尺寸大，Overdraw会非常严重。我一般会限制粒子的最大数量，使用较小的粒子尺寸，并开启粒子的Soft Particles来减少硬边。

第三个坑是忽略了半透明物体的深度预写入开销。双Pass方案在移动端上会让Draw Call翻倍，如果场景中有大量半透明物体，这个开销不可忽视。在移动端上，我倾向于用ATC或者简单的深度偏移，而不是完整的双Pass。

4.3 常见问题速查表

为了方便快速排查，我整理了一个常见问题速查表：

这个表格覆盖了我遇到的大部分问题，但实际项目中问题往往更复杂，需要结合具体情况分析。

4.4 实测性能数据与优化收益

我在一个中型URP项目上做过一轮半透明渲染优化，优化前后的数据对比：

优化的主要措施包括：把三个复杂护盾拆分成九个简单子物体，用自定义Renderer Feature做最近点排序，对粒子系统开启Soft Particles并限制最大粒子数，把部分全屏特效改成不透明实现。

这个数据说明，半透明渲染优化不是单一手段能解决的，需要从Shader、管线、工程多个层面综合施策。而且优化收益是累积的，每个小改进叠加起来，最终效果很可观。

4.5 避坑经验与实操心得

最后分享几条我在实际项目中总结的经验，都是文档里不会写的：

第一条，不要等到项目后期才处理半透明排序问题。半透明排序是架构级的问题，越早处理成本越低。我一般会在项目初期就建立半透明渲染的规范，包括队列值分配、物体拆分标准、Shader模板等。

第二条，美术制作阶段就要考虑渲染排序。很多排序问题是美术资源制作不当导致的，比如把应该拆分的物体合并成一个，或者给半透明物体设置了不合理的包围盒。让美术了解基本的渲染排序原理，能省掉后期大量的返工。

第三条，多用Frame Debugger和Overdraw视图。这两个工具是排查半透明问题的利器，能直观地看到渲染顺序和Overdraw分布。我几乎每天都会用它们检查渲染效果。

第四条，性能优化要量化。不要凭感觉说“优化了”，要用数据说话。记录优化前后的Draw Call、Overdraw、帧率等指标，才能判断优化是否有效。

第五条，保持Shader的简洁。半透明Shader的片元计算越复杂，Overdraw的代价越大。在移动端上，半透明Shader应该尽量简单，把复杂计算移到顶点着色器或者预计算中。

这些经验都是我在多个项目中踩坑踩出来的，希望能帮你少走一些弯路。半透明渲染排序是个深坑，但只要理解了原理，掌握了工具，建立了规范，就能把它控制住。