Unity URP全屏模糊插件：从Shader原理到工程实践
1. 项目概述：为什么我们需要一个URP专属的全屏模糊插件？
在Unity项目开发的后期，尤其是涉及到UI界面、过场动画、技能特效或者场景切换时，一个高质量的全屏模糊效果往往是提升视觉沉浸感和叙事张力的关键。它能把玩家的注意力从纷繁的背景中拉回到前景的UI或角色上，营造出“焦点”感。很多开发者，包括我自己，都曾尝试过自己手写一个全屏后处理模糊Shader，或者从Asset Store找一个通用方案。但踩过几次坑之后，我发现，尤其是在URP（Universal Render Pipeline）管线普及的今天，一个“开箱即用、性能可控、效果统一”的全屏模糊插件，其价值远超我们的想象。
为什么这么说？首先，URP的渲染流程和内置管线（Built-in）有显著差异。内置管线里那些经典的OnRenderImage配合Graphics.Blit的方案，在URP里需要重构成基于RenderFeature和CommandBuffer的现代后处理管线。很多从内置管线迁移过来的项目，或者从网上找到的旧教程代码，直接套用在URP上要么不工作，要么性能开销巨大。其次，一个“统一”的解决方案意味着它能在项目的任何角落被方便地调用和管理——从主菜单的弹出、背包系统的打开，到角色受伤时的屏幕血雾、剧情对话时的景深模拟，你不需要为每个场景、每个UI预制体单独配置一套模糊逻辑。
这个“Unity URP统一全屏模糊效果插件”要解决的，正是这个痛点。它不是一个简单的Shader展示，而是一个工程化的、生产就绪的解决方案。它封装了从底层渲染指令到上层逻辑调用的完整链条，让你通过一行代码就能在游戏中任何时刻、任何强度下，开启或关闭屏幕模糊，并且保证效果在不同分辨率、不同设备上的一致性。这对于追求高品质和开发效率的团队来说，几乎是必备的工具。
2. 核心需求解析与方案设计思路
2.1 模糊效果在游戏中的典型应用场景
在动手开发或选择一个插件之前，我们必须明确它的用武之地。模糊效果绝非为了炫技，它的每一次应用都应有明确的交互或叙事目的。
场景一：UI界面聚焦。这是最普遍的需求。当玩家打开游戏内的背包、设置、技能树等复杂UI时，背景游戏场景如果依然清晰锐利，会与UI元素产生视觉冲突，分散玩家注意力。此时，一个中度的高斯模糊能有效将背景“推远”，让UI面板成为绝对的视觉中心，提升操作清晰度和舒适度。实测下来，这种场景对性能要求最高，因为它可能频繁开关，且需要平滑的过渡动画。
场景二：剧情与过场动画。在播放CG、角色对话或回忆闪回时，全屏模糊（有时配合色调调整）能快速营造出不同于常规游戏画面的“电影感”。例如，角色受伤倒地时，屏幕边缘逐渐模糊并泛红，模拟意识涣散的感觉。这里的关键是效果的可控性和与Timeline等叙事工具的易集成性。
场景三：游戏机制反馈。比如角色释放一个“时间减缓”技能，周围环境变得模糊而动态拖影，只有角色自身清晰；或者玩家进入“潜行”状态时，屏幕四周轻微模糊以暗示视野聚焦。这类效果需要与游戏逻辑深度绑定，要求插件提供丰富的参数（如模糊半径、迭代次数、中心清晰区域等）供实时调整。
场景四：性能与美术的平衡。一个常被忽略的点是，模糊效果有时可以作为“遮瑕”手段。当场景中某些模型或贴图精度不足时，适度的全局模糊可以弱化这些瑕疵，提升整体画面的“柔和”与“高级”感。这在移动端或性能受限的项目中是一个实用技巧。
2.2 URP管线下的技术选型考量
在URP中实现全屏后处理，主流且官方推荐的方式是使用渲染器特性（Renderer Feature）和全屏着色器（Fullscreen Shader Graph）的组合。这是与我们过去熟知的方案最大的不同。
为什么是RenderFeature + Shader Graph？
- 管线集成度高：RenderFeature是URP渲染流程中的一等公民，可以精确控制后处理Pass在渲染管线中的插入位置（例如在渲染不透明物体之后，但在UI之前）。这避免了旧方案可能出现的渲染顺序错误。
- Shader Graph可视化开发：对于像高斯模糊这样算法固定但参数繁多的效果，使用Shader Graph进行开发、调试和迭代的效率远高于手写HLSL/CG。美术或技术美术也能参与调整，直观地看到参数变化对最终效果的影响。
- CommandBuffer的精细控制：在RenderFeature的
AddRenderPasses方法中，我们可以创建ScriptableRenderPass，并使用CommandBuffer来调度渲染指令。这允许我们实现多Pass模糊（如DownSample → Blur → UpSample）、渲染目标（RenderTexture）的临时申请与释放，从而在效果和性能间取得最佳平衡。 - 与Volume系统的兼容性：URP的后处理堆栈（Post-processing Stack）严重依赖Volume系统。一个专业的插件应当提供自定义的
VolumeComponent，这样美术师就可以在场景中通过放置Volume全局框或局部框来控制模糊效果，实现基于位置的动态效果切换，这是旧方案难以做到的。
基于以上考量，我们设计的插件核心架构将包含以下模块：
- 一个自定义的Renderer Feature：负责管理模糊Pass的生命周期和插入时机。
- 一个或多个Shader Graph资产：实现高斯模糊的核心算法，可能分为水平模糊和垂直模糊两个Pass。
- 一个可脚本化渲染通道（ScriptableRenderPass）：封装具体的渲染逻辑，包括RT的创建、模糊材质的设置、Blit操作等。
- 一个可选的Volume Component：提供非破坏性的、基于场景位置的效果覆盖。
- 一个简洁的运行时API（C#脚本）：例如
ScreenBlurController.EnableBlur(float intensity, float duration)，供游戏逻辑调用。
3. 插件核心实现细节与Shader原理
3.1 高斯模糊算法在Shader Graph中的实现
高斯模糊的本质是对图像中每个像素，取其周围一个矩形区域（核）内像素的加权平均值，权重符合二维高斯分布（即中间大，四周小）。在实现上，为了提升性能，我们通常将其分离为两个一维Pass：先进行水平方向模糊，再进行垂直方向模糊。
在Shader Graph中构建这个效果，我们需要理解几个关键节点：
Sample Texture 2D LOD节点：这是采样的核心。我们需要根据模糊半径（
_BlurRadius）和纹理的Texel Size（_BlurTex_TexelSize），计算采样偏移。例如，对于一个半径为4的模糊，我们可能需要在当前像素左右各采样4次（共9次采样），每次采样的UV偏移量是(i * _BlurTex_TexelSize.x, 0)，其中i从-4到4。权重计算：我们可以预先计算好一个高斯核的权重数组，作为一个浮点数数组（
float _Weights[9]）传入Shader。在Shader Graph中，可以用多个Float属性和Multiply、Add节点来模拟这个计算过程。一个更工程化的做法是在C#脚本中计算好权重，通过材质属性块（MaterialPropertyBlock）传递给材质。降采样（DownSample）优化：直接对全分辨率屏幕纹理进行多采样模糊，开销巨大。一个标准的优化技巧是先降采样。我们创建一个长宽各为一半（甚至1/4）的RenderTexture，将屏幕图像先渲染到这个低分辨率RT上，然后再对这个低分辨率RT进行模糊处理。这样做有两个好处：一是需要处理的像素数减少为原来的1/4或1/16，性能大幅提升；二是低分辨率下的模糊本身就带有一种“柔和”感，效果往往更好。最后再将模糊后的低分辨率RT上采样回屏幕。这个过程就是经典的双线性降采样模糊。
在Shader Graph中构建这样一个双Pass模糊时，我的经验是：为水平和垂直模糊分别创建两个SubGraph。主图接收一个输入纹理和模糊方向参数，内部是一个根据方向和半径进行多次采样的循环结构（虽然Shader Graph不支持for循环，但我们可以通过复制节点链来模拟固定次数的循环）。这样结构清晰，也便于复用。
注意：Shader Graph中过于复杂的节点连接会严重影响编译速度和运行时性能。对于固定9次采样的高斯模糊，直接展开9组采样计算节点通常是比尝试用Branch节点更高效的选择。虽然看起来不“优雅”，但GPU更喜欢确定性的计算。
3.2 Renderer Feature与RenderPass的工程化封装
这是插件的“大脑”和“调度中心”。一个好的封装应该让使用者几乎感知不到它的存在，同时又提供足够的控制钩子。
核心类设计：
// 1. 设置数据资产 (ScriptableObject) [CreateAssetMenu(menuName = "Rendering/URP Screen Blur Settings")] public class ScreenBlurSettings : ScriptableObject { public Shader blurShader; [Range(0, 10)] public int downsample = 2; [Range(0.0f, 10.0f)] public float blurRadius = 3.0f; public int iteration = 3; // 模糊迭代次数，影响平滑度 } // 2. 可脚本化渲染通道 public class ScreenBlurRenderPass : ScriptableRenderPass { private Material m_BlurMaterial; private RenderTextureDescriptor m_Descriptor; private RTHandle m_CameraColorTarget; // URP推荐使用RTHandle管理RT private ScreenBlurSettings m_Settings; // 临时RT句柄，用于乒乓模糊 private RTHandle m_TemporaryRT1; private RTHandle m_TemporaryRT2; public void Setup(RTHandle cameraColorTarget, ScreenBlurSettings settings) { m_CameraColorTarget = cameraColorTarget; m_Settings = settings; // 根据设置创建或获取模糊材质 if (m_BlurMaterial == null && settings.blurShader != null) m_BlurMaterial = CoreUtils.CreateEngineMaterial(settings.blurShader); } public override void Execute(ScriptableRenderContext context, ref RenderingData renderingData) { if (m_BlurMaterial == null || m_Settings == null) return; CommandBuffer cmd = CommandBufferPool.Get("Screen Blur"); using (new ProfilingScope(cmd, new ProfilingSampler("ScreenBlurPass"))) { // 获取相机原始颜色纹理描述符，并创建降采样后的描述符 m_Descriptor = renderingData.cameraData.cameraTargetDescriptor; m_Descriptor.width >>= m_Settings.downsample; // 右移一位等于除以2 m_Descriptor.height >>= m_Settings.downsample; m_Descriptor.depthBufferBits = 0; // 模糊不需要深度缓冲 // 分配临时RT (RTHandle版本) RenderingUtils.ReAllocateIfNeeded(ref m_TemporaryRT1, m_Descriptor, name: "_TemporaryRT1"); RenderingUtils.ReAllocateIfNeeded(ref m_TemporaryRT2, m_Descriptor, name: "_TemporaryRT2"); // 第一步：将相机颜色Blit到降采样的临时RT1 Blitter.BlitCameraTexture(cmd, m_CameraColorTarget, m_TemporaryRT1); // 第二步：进行多次迭代的乒乓模糊 for (int i = 0; i < m_Settings.iteration; i++) { // 水平模糊: Temp1 -> Temp2 m_BlurMaterial.SetFloat("_BlurRadius", m_Settings.blurRadius); m_BlurMaterial.SetInt("_BlurDirection", 0); // 0 for horizontal Blitter.BlitCameraTexture(cmd, m_TemporaryRT1, m_TemporaryRT2, m_BlurMaterial, 0); // 垂直模糊: Temp2 -> Temp1 m_BlurMaterial.SetInt("_BlurDirection", 1); // 1 for vertical Blitter.BlitCameraTexture(cmd, m_TemporaryRT2, m_TemporaryRT1, m_BlurMaterial, 0); } // 第三步：将最终模糊结果Blit回相机颜色目标 Blitter.BlitCameraTexture(cmd, m_TemporaryRT1, m_CameraColorTarget); } context.ExecuteCommandBuffer(cmd); CommandBufferPool.Release(cmd); } // 清理分配的RT资源 public void Dispose() { m_TemporaryRT1?.Release(); m_TemporaryRT2?.Release(); } } // 3. 渲染器特性 public class ScreenBlurFeature : ScriptableRendererFeature { [SerializeField] private ScreenBlurSettings m_Settings; private ScreenBlurRenderPass m_ScriptablePass; public override void Create() { if (m_Settings == null) return; m_ScriptablePass = new ScreenBlurRenderPass(); m_ScriptablePass.renderPassEvent = RenderPassEvent.BeforeRenderingPostProcessing; // 在后期处理前插入 } public override void AddRenderPasses(ScriptableRenderer renderer, ref RenderingData renderingData) { if (renderingData.cameraData.cameraType == CameraType.Game) { // 仅对游戏主相机生效 m_ScriptablePass.ConfigureInput(ScriptableRenderPassInput.Color); m_ScriptablePass.Setup(renderer.cameraColorTargetHandle, m_Settings); renderer.EnqueuePass(m_ScriptablePass); } } protected override void Dispose(bool disposing) { m_ScriptablePass?.Dispose(); } }关键设计解析：
- 使用RTHandle：URP 12+ 版本推荐使用
RTHandle系统来管理RenderTexture，它提供了更智能的分配和复用策略，能有效减少内存碎片和分配开销。 - 乒乓（Ping-Pong）模糊：我们使用两个临时RT（
Temp1和Temp2）交替作为输入和输出。一次迭代包含一次水平模糊和一次垂直模糊，多次迭代可以增强模糊强度和平滑度，同时避免创建过多临时RT。 - 渲染时机（RenderPassEvent）：选择
BeforeRenderingPostProcessing意味着我们的模糊会在URP内置的后处理（如Bloom, Tonemapping）之前应用。这很重要，因为模糊后的图像再经过泛光等效果，其光晕会更柔和自然。如果你希望模糊应用在所有后处理之后（例如只模糊UI层），则需要选择AfterRenderingPostProcessing并做相应调整。 - 配置输入（ConfigureInput）：
ConfigureInput(ScriptableRenderPassInput.Color)声明本Pass需要上一Pass产生的颜色缓冲区作为输入，这是必须的。
4. 性能优化与参数调校实战
全屏后处理是性能敏感区域，尤其是在移动设备上。一个未经优化的模糊效果可能瞬间吃掉10ms以上的帧时间。因此，插件的价值不仅在于实现效果，更在于提供一套可调校的、高性能的默认配置。
4.1 性能开销分析与优化策略
我们可以通过Unity的Profiler的Rendering区域和Render Pass视图来精确分析模糊Pass的开销。主要开销来自两部分：像素填充率（Fillrate）和纹理采样次数。
降采样是最大的性能杠杆：参数
downsample（通常设为1,2,3）对性能的影响是指数级的。downsample=2意味着处理像素变为1/4，downsample=3则是1/9。对于大多数1080p屏幕下的UI模糊，downsample=2（处理540p图像）在视觉质量和性能上是最佳平衡点。你可以提供一个“性能模式”和“质量模式”的预设，前者用更大的降采样。控制迭代次数与模糊半径：
iteration（迭代次数）和blurRadius（模糊半径）共同决定了最终的模糊强度和平滑度。iteration增加会线性增加渲染Pass（即Draw Call）。通常iteration=2或3已经能产生非常平滑的效果。blurRadius影响每次采样时的偏移距离，过大的半径需要更多的采样点来保持质量（否则会出现色块），在固定采样次数下，过大的半径会导致采样点稀疏，效果变差。我的经验是：优先用适中的半径（如3-5）配合2-3次迭代，来达到想要的模糊强度，而不是用一个超大半径单次迭代。基于视口分辨率的动态调整：一个高级技巧是让
downsample的级别与当前屏幕分辨率动态关联。例如，在4K显示器上，你可以放心地使用downsample=3；而在720p的移动设备上，可能只敢用downsample=1。这可以通过在ScreenBlurRenderPass的Execute方法中，根据m_Descriptor.width/height来动态计算一个合适的降采样级别来实现。避免在不需要时运行：这是最有效的优化。插件应该提供一个全局的开关，并且只在需要的时候启用对应的
RendererFeature。可以通过一个静态类ScreenBlurManager来管理状态，当没有模糊需求时，直接从Renderer中移除或禁用该Feature。
4.2 参数配置表与效果对照
为了帮助使用者快速上手，提供一个预设参数表是非常有用的。下表展示了不同参数组合下的典型用途、视觉特征和性能预估（以1080p分辨率，60FPS为基准）：
| 预设名称 | DownSample | 迭代次数 | 模糊半径 | 典型用途 | 视觉特征 | 性能开销 (预估) | 适用平台 |
|---|---|---|---|---|---|---|---|
| 极速模式 | 3 | 1 | 2.0 | 移动端轻度背景虚化、低电量模式 | 有明显的像素化感，但运动时不易察觉 | < 0.5ms | 低端移动设备 |
| 均衡模式 (推荐) | 2 | 2 | 3.0 | 通用UI背景模糊、对话框聚焦 | 平滑柔和，无明显瑕疵，性价比最高 | 1.0 - 2.0ms | 中高端移动设备/PC |
| 品质模式 | 1 | 3 | 4.0 | 过场动画、截图模式、电影化表现 | 极其平滑，细节保留好，有景深相机感 | 3.0 - 5.0ms | PC/主机/高端移动设备 |
| 动态景深模拟 | 2 | 2 | 可变 (0-8) | 角色技能、呼吸效应 | 模糊强度可动态变化，营造氛围 | 1.0 - 2.0ms (取决于半径) | 全平台(需控制变化频率) |
调校心得：
- 移动端黄金法则：永远从
downsample=2和iteration=1开始测试。如果效果不够，先尝试微调blurRadius（2.0到4.0之间），最后再考虑增加迭代次数。每次增加迭代，务必在目标真机上测试帧率。 - PC/主机端：可以更追求质量。但要注意，即使性能充足，过高的
iteration（如>4）带来的视觉提升也微乎其微，属于无效开销。将downsample设为1，iteration设为2或3，通常就能得到电影级的效果。 - 边缘处理：高斯模糊在屏幕边缘会因采样不到像素而变暗（边缘衰减）。一种改进方法是使用“扩张（Dilate）”或“镜像（Mirror）”模式的纹理包裹（Wrap Mode），但这需要在Shader中额外处理。对于大多数UI模糊场景，由于边缘通常是纯色或被UI遮盖，这个问题可以忽略。
5. 实战集成：从插件调用到高级应用
5.1 简洁的运行时API设计
插件再好，如果调用起来麻烦，也会被开发者抛弃。我们的目标是提供类似ScreenBlur.Enable(float intensity, float fadeTime)这样简单的静态接口。
public static class ScreenBlurController { private static ScreenBlurFeature m_BlurFeature; private static Coroutine m_CurrentFadeCoroutine; // 初始化，通常在游戏启动时调用，用于查找场景中的Blur Feature public static bool Initialize() { var renderer = UnityEngine.Rendering.Universal.UniversalRenderPipeline.asset?.scriptableRenderer; if (renderer == null) return false; m_BlurFeature = renderer.features.OfType<ScreenBlurFeature>().FirstOrDefault(); return m_BlurFeature != null; } // 立即启用/禁用模糊 public static void SetBlurEnabled(bool enabled) { if (m_BlurFeature != null) { m_BlurFeature.settings.active = enabled; // 假设Settings里有一个active布尔值 } } // 启用模糊，并带强度渐变（非常实用的功能） public static void EnableBlur(float targetIntensity = 1.0f, float fadeDuration = 0.3f) { if (m_BlurFeature == null || !Initialize()) return; if (m_CurrentFadeCoroutine != null) { // 停止之前的渐变，避免冲突 // 需要持有MonoBehaviour来启动协程，这里省略了Instance的获取逻辑 // Instance.StopCoroutine(m_CurrentFadeCoroutine); } // 启动一个新的渐变协程 m_CurrentFadeCoroutine = Instance.StartCoroutine(FadeBlurRoutine(true, targetIntensity, fadeDuration)); } // 禁用模糊，带渐变 public static void DisableBlur(float fadeDuration = 0.3f) { // 类似EnableBlur，反向渐变 } private static IEnumerator FadeBlurRoutine(bool enable, float targetIntensity, float duration) { float startTime = Time.time; float startIntensity = m_BlurFeature.settings.currentIntensity; // 当前强度 m_BlurFeature.settings.active = true; // 确保效果激活 while (Time.time - startTime < duration) { float t = (Time.time - startTime) / duration; float currentIntensity = Mathf.Lerp(startIntensity, enable ? targetIntensity : 0f, t); m_BlurFeature.settings.SetIntensity(currentIntensity); // 动态设置强度 yield return null; } m_BlurFeature.settings.SetIntensity(enable ? targetIntensity : 0f); if (!enable) { m_BlurFeature.settings.active = false; // 渐变结束后彻底关闭 } m_CurrentFadeCoroutine = null; } }这样，在需要打开背包的代码里，只需要一行：ScreenBlurController.EnableBlur(0.8f, 0.2f);。0.2秒的渐入时间能避免效果的突兀感，极大提升体验。
5.2 与UI系统（UGUI/UI Toolkit）及Timeline的集成
与UGUI集成：最常见的需求是，当打开一个全屏UI时启用模糊，关闭时禁用。我们可以创建一个通用的BlurBackgroundUI组件，挂载在Canvas根对象或特定全屏面板上。
public class BlurBackgroundUI : MonoBehaviour { [SerializeField] private float blurIntensity = 0.7f; [SerializeField] private float fadeInTime = 0.15f; [SerializeField] private float fadeOutTime = 0.25f; // 关闭可以稍慢，更舒适 private void OnEnable() { ScreenBlurController.EnableBlur(blurIntensity, fadeInTime); } private void OnDisable() { ScreenBlurController.DisableBlur(fadeOutTime); } }与Timeline集成：为了在过场动画中精确控制模糊，我们可以创建一个自定义的PlayableAsset和PlayableBehaviour。
- 创建一个
ScreenBlurClip：在Timeline轨道上，它可以被拖拽和裁剪。 - 在
PlayableBehaviour的ProcessFrame方法中，根据当前播放进度（0到1）计算模糊强度，并调用ScreenBlurController的接口进行设置。这样，导演或动画师就可以像控制镜头一样，在Timeline上关键帧化模糊强度的变化，实现诸如“焦点从角色A转移到角色B时，背景模糊程度随之变化”的复杂叙事效果。
与Volume系统集成（进阶）：如果你希望模糊效果能基于玩家在场景中的位置（例如进入特定区域自动模糊）或由美术师全局配置，可以创建一个ScreenBlurVolumeComponent，继承自VolumeComponent。在其中暴露intensity、downsample等参数。然后在ScreenBlurRenderPass中，每一帧去查询当前相机位置所对应的Volume混合值，并应用这些参数。这赋予了美术师在不写代码的情况下，通过放置Volume物体来设计场景模糊效果的能力。
6. 常见问题排查与进阶技巧
6.1 问题速查表
在实际集成和使用过程中，你几乎一定会遇到下面这些问题。这里是我踩过坑后的总结：
| 问题现象 | 可能原因 | 排查步骤与解决方案 |
|---|---|---|
| 屏幕全黑或全白 | 1. Shader编译错误。 2. 临时RT创建失败。 3. Blit的源或目标纹理错误。 | 1. 检查Unity Console是否有Shader错误（粉色提示）。 2. 在RenderPass中Debug.Log输出临时RT的descriptor和是否创建成功。 3. 确保 Blitter.BlitCameraTexture传入的source和destination句柄正确。新手最容易错在这里：把颜色目标搞反了。 |
| 模糊效果不起作用 | 1. Renderer Feature未启用或未添加到URP Renderer中。 2. 渲染时机（RenderPassEvent）设置不当，效果被覆盖。 3. 模糊强度参数为0。 | 1. 在Project Settings -> Graphics -> URP Global Settings中检查使用的Renderer Asset，并确认Feature已添加并勾选。 2. 尝试调整 RenderPassEvent，比如从BeforeRenderingPostProcessing改为AfterRenderingPostProcessing，看效果是否出现。3. 检查传入Shader的 _BlurRadius等参数值是否大于0。 |
| 模糊效果闪烁或抖动 | 1. 每帧临时RT的分配/释放导致内存抖动。 2. 降采样参数导致分辨率非整数，产生纹理对齐问题。 | 1.务必使用RTHandle系统，并确保在Pass外部初始化，在Dispose中释放，而不是每帧new RenderTexture。2. 确保降采样后的宽高是整数。使用 Mathf.Max(1, descriptor.width >> downsample)进行计算。 |
| UI元素也被模糊 | 渲染顺序问题。模糊Pass在UI渲染之后执行。 | 将Renderer Feature的RenderPassEvent设置为BeforeRenderingPostProcessing（UI通常在AfterRenderingPostProcessing之后渲染）。如果UI是World Space，可能需要更复杂的层（Layer）过滤方案。 |
| 移动设备上帧率骤降 | 性能开销过大。 | 1. 首要降低downsample级别。2. 其次减少 iteration次数。3. 使用Profiler的 Rendering模块查看该Pass的具体耗时，针对性优化。4. 确保在不需要模糊时（如战斗场景），完全禁用该Renderer Feature。 |
| 模糊边缘有黑边或硬边 | 高斯模糊在纹理边缘采样越界。 | 在Shader Graph的Sample Texture 2D节点中，将Sampler的Wrap Mode设置为Clamp（默认）可能会产生黑边。可以尝试在模糊前，将纹理的Border Color设置为透明黑或边缘像素的扩展色，但这会增加复杂度。对于被UI覆盖的场景模糊，此问题通常不可见。 |
6.2 进阶技巧：实现动态模糊与区域模糊
动态模糊：让模糊强度随着游戏事件（如角色血量、速度）变化。这很简单，只需要在ScreenBlurRenderPass.Execute中，根据某个全局变量（如GameManager.PlayerHealthNormalized）来动态计算blurRadius即可。可以将计算逻辑放在一个单独的MonoBehaviour中，每帧更新一个静态变量，供RenderPass读取。
区域模糊（非全屏）：这是更高级的需求，例如只模糊屏幕的四周，中心保持清晰（模拟镜头景深）。实现思路有两种：
- Shader Masking（推荐）：在模糊Shader中，额外传入一个表示“清晰中心区域”的遮罩纹理或参数（如中心点坐标和半径）。在混合模糊结果和原始图像时，根据像素位置与中心的距离，进行插值。这只需要一个额外的Pass，性能较好。
- 双摄像机渲染：使用两个摄像机，一个渲染清晰层（中心区域），一个渲染模糊层（整个场景）。然后通过一个后期Shader将两者合成。这种方法更灵活，可以做出非圆形的模糊区域，但设置复杂，Draw Call翻倍。
对于大多数项目，全屏模糊已经足够。区域模糊的实现可以作为插件的一个“Pro”版本特性来提供。
最后，关于这个插件，我个人最深刻的体会是：后处理效果的成功，90%取决于集成和调参，而不是算法本身。一个参数搭配不当的高斯模糊，看起来就是一团脏兮兮的色块；而参数调校得当，它就能成为提升游戏视觉叙事和交互品质的神器。这个插件提供的，正是一个经过打磨的、参数可调的、易于集成的坚实基础，让你能把精力集中在如何“使用”这个效果来为游戏服务，而不是反复折腾底层渲染管线那些令人头疼的细节。