我接手第一个需要做“实时画面风格化”需求的 Unity 项目时第一反应是怀疑自己听错了——摄像机的实时画面不仅要拍出来还要在渲染的瞬间做一套滤镜、像素化、暗角之类的图像处理。听起来像 PhotoShop 的活儿却要跑在每帧几十毫秒的游戏渲染里。后来菜踩多了才明白 Unity 实时摄像机渲染图像处理其实是个很早就有、一直没被讲透的老话题。它本质上是在相机把画面提交到屏幕之前插一道或几道 GPU 侧的像素搬运工序让画面上每一个像素都有机会被二次编辑。这篇文章适合两类人一类是刚接到“后处理”“滤镜效果”“截图美化”需求的 Unity 新手另一类是已经在用 OnRenderImage 或 RenderTexture但总觉得哪里别扭、想搞清楚每种方案代价的老伙计。我会按实际项目里常见的思考路径来写需求怎么拆、三条实现路径怎么选、一个小而完整的像素化后处理怎么落地、性能开销怎么看最后是排错经验。1. 为什么你的相机画面需要一张“处理层”从需求重新理解图像处理很多人第一次接触“实时摄像机渲染图像处理”是被一个具体需求逼出来的。比如结算界面要把主相机画面变成模糊背景比如角色被击中时屏幕要闪红比如钓鱼游戏要加一个复古 CRT 扫描线特效。这些需求都指向同一件事不满足于相机的原始输出要在最终显示之前插入一个“图像处理层”。但“插入在哪”“谁来插”“处理什么格式的像素”这三问才是真正的技术分水岭。1.1 真实项目里最常碰到的三类处理需求我把这些年见到的需求粗暴分成三类方便你对号入座基于时间的动态效果画面闪白、受伤红屏、黑白过渡、雨夜视线遮挡。特征是效果强度和游戏逻辑变量血量、时间、事件绑定通常用后处理 Shader 里传入一个_Intensity就能解决。基于空间的全屏变换像素化、模糊、锐化、边缘检测、色彩分离。特征是需要对屏幕纹理的相邻像素做采样或降采样算法更复杂对分辨率、纹素texel尺寸的计算尤其敏感。基于内容的分区处理只对画面中的特定物体、特定区域做处理比如只把怪物描边其他地方不动。这类需求一般会用到CameraDepthTexture或摄像机额外渲染的深度/模板缓冲实现难度最高。这三类需求的实现路径不太一样但入口是相通的——你要先拿到“当前帧的相机画面”这张纹理处理完再送回屏幕。而“拿到画面—处理—送回”这个过程正是文章标题里“实时摄像机渲染图像处理”的核心动作。1.2 理解“处理”发生在哪一帧像素管线的时间切片新手拿到后处理需求最容易卡死在“处理到底发生在什么时机”这个问题上。这里我建议你不要去背 API而是记住一个顺序模型相机视角计算 → 场景中所有可见物体逐物体绘制到缓冲 → 缓冲中已有完整相机画面的颜色和深度信息 → 后处理Shader接管 → 输出到屏幕可以理解为Unity 先把整个场景“拍”到一张看不见的中间画布上你的图像处理脚本在这张画布和显示器之间当了一回“滤镜”。不管用哪种技术实现只要想清楚这次“滤镜”发生在场景绘制完成之后、屏幕显示之前就不会把坐标、UV、纹理方向搞乱。另一个容易被忽略的时间切片是后处理的执行顺序。如果项目里挂了三四个后处理脚本它们的执行顺序并不一定等于你在 Inspector 里看到的脚本排列顺序。尤其在老版本内置渲染管线中OnRenderImage的调用顺序取决于脚本的执行顺序Script Execution Order如果脚本之间互相叠加效果排序错了会直接导致画面效果错乱。这是很常见的隐性坑后面排错章节我会再提。2. 技术选型三条实现路径和它们各自的代价在 Unity 里做实时摄像机图像处理主流实现大致有三条路。每条的取舍都不一样选错了轻则不好维护重则整个渲染管线冲突。我把它们放在一起对比并给出我的选型建议。方案适用管线实现成本直观性性能特征OnRenderImage内置渲染管线内置管线极低极直观几行代码可跑通经 Blit 拷贝有整屏纹理解析开销RenderTexture 相机 TargetTexture任意管线中等所见即所得逻辑最直白相机多渲一次显存多一张纹理带宽翻倍URP Renderer FeatureURP中高需理解 Pass/Feature 生命周期可精细控制生效时机性能上限高2.1 OnRenderImage古老但依然有效的入口先说我个人最常用、也最推荐新手先跑的方案OnRenderImage。public class SimplePostEffect : MonoBehaviour { public Material effectMaterial; void OnRenderImage(RenderTexture src, RenderTexture dst) { if (effectMaterial ! null) { Graphics.Blit(src, dst, effectMaterial); } else { Graphics.Blit(src, dst); } } }这段代码的意思很简单相机渲染完成后src里是原画面dst是目标输出。Graphics.Blit把src通过effectMaterial处理完写到dst。效果写在 Shader 里写对了就生效写错了屏幕就黑给你看。它的优点是直接在相机脚本里介入不用创建额外的 RenderTexture结构上最贴合日常 Editor 调试。缺点是只能在内置渲染管线的某个回调里用在 URP 中它不会按这个语义继续工作URP 管线下它可能不会被执行或者行为和预期有偏差。如果项目是 URP意味着你要么选CommandBuffer、要么选Renderer Feature不能把项目打包到 URP 后又指望这个旧入口正常工作。2.2 RenderTexture 方案把相机“盯”到纹理上第二种方案的思路完全不同不依赖“截图”回调而是让相机直接渲染到一张 RenderTexture 上。这件事用一句话概括就是“给相机换一块隐形屏幕”这块隐形屏幕不再直接显示而是成为你的处理素材。RenderTexture rt RenderTexture.GetTemporary(Screen.width, Screen.height, 24); Camera.main.targetTexture rt; // 相机渲染目标变为 rt替代真实屏幕用完记得RenderTexture.ReleaseTemporary(rt)并把targetTexture设回null。把相机指向一张临时纹理适合“这个相机不直接输出画面而是供 UI 或别的相机使用”的场景。但也正是因为多了一次完整渲染带宽开销几乎翻倍——场景原本只用画一次现在先画到纹理这本身就是一份成本后续怎么处理这张纹理又是另一份成本。这种方案目前在大世界项目里很少用作“全屏后处理”的唯一手段更多见于小地图相机、监控相机、反射探针这类“专门渲染一张特殊视角图”的需求。拿它做滤镜逻辑上没问题成本上略奢侈。2.3 URP Renderer Feature现代管线的正确姿势如果你项目从一开始就选 URP那面向未来的做法是ScriptableRendererFeatureScriptableRenderPass。它本质上是“把一次后处理包装成一个可交换的渲染模块”挂在 Renderer 上可以在 Frame Debugger 里清楚看到自己插入的位置。一个最小结构是public class PixelateFeature : ScriptableRendererFeature { public Material pixelateMaterial; public RenderPassEvent renderEvent RenderPassEvent.AfterRenderingPostProcessing; PixelateRenderPass pass; public override void Create() { pass new PixelateRenderPass(pixelateMaterial, renderEvent); } public override void AddRenderPasses(ScriptableRenderer renderer, ref RenderingData renderingData) { if (pixelateMaterial ! null) renderer.EnqueuePass(pass); } }这个方案的优点在于不污染相机脚本、执行顺序和插入阶段都可控制、在生产质量项目里更好分层。代价是要先理解RenderPassEvent的各个阶段发生在渲染流程的哪一步以及后处理 Pass 里如何用CommandBuffer正确申请临时 RT。对初学者来说第一遍看着会有些“饶”但它很难走回头路——一旦上手你会喜欢上这种“各管一段”的清晰结构。选型我的个人结论是老项目内置管线优先 OnRenderImage跨管线或新项目学 URP Feature只有“纯粹得多渲染一张图”的语义才考虑 RenderTexture 相机。三种路径并不互斥大团队经常混用分场景处理各自的需求。3. 手把手写一个像素风滤镜后处理说清楚选型后我来带你完整做一个最经典、也最能练手的小功能像素化后处理Pixelate。它既涉及降采样原理、纹素精度也涉及 Shader 和 C# 的协同做完这一个后面类的效果基本就是排列组合了。3.1 像素化降采样的数学原理像素化的视觉本质是“低分辨率放大回原分辨率”。想象一张 1920x1080 的画面先压缩成 240x135 的“缩略图”再拉回 1920x1080拉回时每个色块被线性拉伸成一大块视觉上就出现了“马赛克晶体”效果。这里的关键暴力算法是对每一个目标像素不采样原图上它自己的位置而是采样一个“所在格子中心”的位置。假设_PixelScale表示每个像素块的边长数值越大块越粗某像素的 UV 是uv那么float2 blockUV floor(uv * _BlockCount) / _BlockCount;floor会把 UV 映射到“第几个块”再除以_BlockCount回到 0~1 的 UV 空间整个过程等价于“只取每块左下角位置的颜色”。因此画面中每个块内所有像素最终都用同一个中心坐标去采样块与块之间颜色不连续就形成了马赛克感。3.2 完整的 C# 挂载脚本与 Shader先写挂相机的脚本。注意我用的是内置管线 OnRenderImage 的版本方便直接跑using UnityEngine; public class PixelateEffect : MonoBehaviour { public Material pixelateMat; private int blockCountID Shader.PropertyToID(_BlockCount); void OnRenderImage(RenderTexture src, RenderTexture dst) { if (pixelateMat ! null) { Graphics.Blit(src, dst, pixelateMat); } else { Graphics.Blit(src, dst); } } void Update() { // 实际项目里可以用 Slider 驱动 if (pixelateMat ! null) { pixelateMat.SetFloat(blockCountID, 80f); } } }然后是 Shader。这里用内置管线的 Unlit 系 Shader按“后处理全屏三件套”的套路来vertex只处理顶点和 UVfragment做真正的采样和处理。Shader Custom/Pixelate { Properties { _MainTex (Source, 2D) white {} _BlockCount (Block Count, Float) 80 } SubShader { Tags { RenderTypeOpaque } Pass { CGPROGRAM #pragma vertex vert #pragma fragment frag #include UnityCG.cginc sampler2D _MainTex; float4 _MainTex_TexelSize; float _BlockCount; struct appdata { float4 vertex : POSITION; float2 uv : TEXCOORD0; }; struct v2f { float4 pos : SV_POSITION; float2 uv : TEXCOORD0; }; v2f vert (appdata v) { v2f o; o.pos UnityObjectToClipPos(v.vertex); o.uv v.uv; return o; } fixed4 frag (v2f i) : SV_Target { float2 blockUV floor(i.uv * _BlockCount) / _BlockCount; fixed4 col tex2D(_MainTex, blockUV); return col; } ENDCG } } }挂载流程是这样先建一个 MaterialShader 选Custom/Pixelate再把这个 Material 赋给脚本的pixelateMat相机上挂着脚本即可。不要忘了给相机挂脚本前先确认渲染路径和 Unity 版本对 OnRenderImage 的支持。3.3 参数调节的经验为什么像素阈值不是越大越好很多人在这一步会开始疯狂拖动滑块然后把_BlockCount调到 20、10、甚至 5觉得“块越大越酷”。但实际项目里这是大忌。块过大的画面会让 UI 文字和角色脸部细节完全不可读玩家会觉得“游戏是不是坏了”。我见过最有效的调法是先定一个“信息可读底线”——比如角色脸部轮廓还看得出UI 主要文字还辨认得出来——再在这个底线附近微调。另外要提醒一个常见认知误区_BlockCount80不代表屏幕上有 80 个像素块而是横向划分 80 个区间。如果你用的是竖向屏会觉得块被拉长这很正常块是沿 UV 均匀分的与屏幕宽高比无关。想保持“正方形块”的话得乘上宽高比修正float aspect _ScreenParams.x / _ScreenParams.y; float2 blockUV float2( floor(i.uv.x * _BlockCount * aspect) / (_BlockCount * aspect), floor(i.uv.y * _BlockCount) / _BlockCount );这个细节很多现成 demo 不提但手机上真机一跑就露馅。还有一个在移动端尤其需要注意的坑不要用if判断块内是否需要采样边缘能不能直接全屏统一计算能。因为顶点阶段只是传 UV真正的计算在 fragment 里面是逐像素跑 GPU 的分支预测在 GPU 上几乎不存在。所以我上面的写法一直是“全屏无分支”的这也替它在老机型上省了不少性能。4. 别只在屏幕上做“木匠活”性能开销与优化画面效果做出来了接着来算账。做实时图像处理不是“贴一张滤镜图”它是在每帧的 GPU 时间线上插了一刀的。预算怎么控是我亲测最容易翻车的地方。4.1 一次屏幕后处理到底花了多少 GPU 预算要估算一次屏幕后处理的开销记住这条公式的直觉版开销 ≈ 屏幕像素数 × 单个像素的采样次数 × 帧率一个 1080p 屏幕约 200 万个像素每帧处理一次1 秒 60 帧就是约 1.2 亿次像素计算这还不算两次 Blit 之间的纹理读写带宽。这也是为什么“后处理不宜多且杂”——每多加一个 Pass就多一次 200 万像素级别的整屏往返。后处理叠了三四个 PassGPU 时间翻倍是常有的事。我项目里一个保底原则移动端整帧后处理 Pass 数控制在 1~2 个桌面端可以放宽到 3~4 个但也要盯帧时间。如果你在 Frame Debugger 里看到同一个效果被拆成 5 个 Pass那纯粹是没做好合并而不是功能需要。4.2 合批、分辨率和带宽的三角取舍接下来是三个优化方向建议按优先级来排分辨率降采样这是收益最高的一刀。与其 1920x1080 全分辨率跑后处理不如把中间 RT 降到 0.5 倍分辨率960x540跑完再放大回屏幕。模糊、泛光、像素化这些“视觉上不需要超高细节”的效果画质损失几乎看不出来但计算量降到四分之一。合并采样的距离一个后处理 Shader 里如果采样 4 张纹理它就比采样 1 张纹理的 Pass 贵 4 倍。遇到“模糊颜色偏移亮度调整”三个效果宁可把它们写进同一个 Shader也不要发三次 Blit。你可以用一张纹理同时存多种信息或用一次采样把两个效果的计算公式合并控制住“每像素采样次数”。带宽预算后处理最烧的其实不是计算是纹理读写。Mobile 上的RenderTexture读写带宽往往比计算更贵所以少建 RT、少用全屏 Blit就是在给带宽让路。这也是为什么 URP 里一个 Feature 内可以GetTemporaryRT再Blit但老手通常会在同一 Pass 内做完尽可能多的效果而不是链式建一堆中间 RT。4.3 从时间线 Profiler 里看到的真相纸上谈兵没说服力我分享一次真实的性能排查经历。某项目的受伤红屏效果很简单——一个OnRenderImage传_Intensity低频操作。但发现它在部分安卓机上掉帧到 45 FPS 左右。第一反应是 Petal 这类 GPU 性能工具看 Shader 复杂度Shader 极简计算量不该那么大。后来用 Frame Debugger 一帧一帧翻发现掉帧原因是那台机型在切换后处理时重建了帧缓冲对象导致带宽峰值爆了。解决办法不是优化 Shader而是提前申请好复用 RT不做每帧申请释放。忠告是性能问题不要凭直觉判断先看时间线和 Frame Debugger。后处理的性能瓶颈分布在计算、带宽、FBO 切换、纹理格式四块不看数据你分不清是哪一个。5. 排错实录相机画面黑屏、翻转、闪烁的已知坑最后一部分我把这些年遇到最多的排错场景整理成一份“症状—原因—修复”对照。先声明我不会给你无法验证的原因猜测每条都是我在实际项目里亲测过的链路。5.1 黑屏的第一嫌疑Depth Texture 与 HDR后处理一开就黑屏这是我见过最频繁的问题。常见的直接原因有两个相机 HDR 设置与 Shader 颜色空间不匹配。如果相机开了 HDR画面是浮点格式你拿到_MainTex的格式也是浮点如果你的 Shader 做了某些假定“输入是 8bit”的压缩操作就可能出现极端黑/白。解决方法是统一检查项目Color Space、相机的Allow HDR确认 Shader 里没有硬编码颜色空间假设。Depth Texture 未开启。凡是后处理里需要采样深度比如景深、扫描线、边缘光的都要在相机设置里勾选Depth Texture。很多人把相机Depth Texture设成None后处理里取_CameraDepthTexture就会得到全黑或脏数据呈现出来的效果就是“画面某些区域被错误抠掉”。排查链路建议从简单到复杂先另存一个不挂后处理的相机看场景是否正常再把后处理 Material 换回默认的Sprites/Default或一个纯色输出 Shader分步二分很快就能定位到是相机配置、脚本逻辑还是 Shader 数据的问题。5.2 画面上下颠倒的真实原因和修复出现上下颠倒绝大多数时候不是相机设置而是纹理坐标的正确性问题。OnRenderImage中src的 UV 原点在左下角而某些平台尤其 OpenGL 系的屏幕 UV 原点在左上角。当你自作聪明地在 Shader 里写了o.uv 1 - v.uv之类的东西就可能在 PC 上正常、手机上翻车或者在 Editor 正常、真机翻倒。正确做法是把_MainTex_TexelSize.y的符号考虑进去#if UNITY_UV_STARTS_AT_TOP if (_MainTex_TexelSize.y 0) { uv.y 1.0 - uv.y; } #endif没有这个防御你的效果就会出现“开发机上好好的打进包里就倒了”的玄学问题。另外如果是在 URP 里用 Renderer Feature纹理翻转由管线统一处理一般不需要你额外管但如果同一套 Shader 既在内置管线用又在 URP 用翻转逻辑还是写全为好。5.3 OnRenderImage 与 URP 的兼容性之痛我看到不少团队把项目迁到 URP 后第一批冒出来的 bug 就是老的后处理脚本失效。原因正如前面所述OnRenderImage不是 URP 的入口。它会无声无息地不执行画面看起来“正常但没有效果”——因为 URP 的渲染路径根本没走到那个回调。但要说一句公道话OnRenderImage并没有被 Unity 官方彻底移除URP 里写它也不会报错只是它真的不会被调用。这导致很多人排查时始终找不到“为什么没效果”。所以迁移到 URP 后的第一件事就是做一次全项目后处理脚本盘点把所有OnRenderImage改写为对应的ScriptableRendererFeature。把这个过程当做一个必做的技术债清理而不是“看有没有时间再处理”。除了这些还有几个出现频率也很高的小坑值得记一下同屏多个相机后处理脚本挂在多个相机上每帧会被执行多次。如果每个相机都做全屏模糊叠加效果会指数级爆掉。注意相机Depth和Culling Mask确认只有主相机挂后处理。RT 泄漏申请了RenderTexture.GetTemporary却忘了ReleaseTemporary会在几帧后耗尽显存。这个错误在 Editor 里有时不明显真机玩久了才会突然卡死。Shader 变体与关键词如果 Shader 里用了#pragma multi_compile你在脚本里EnableKeyword一定要确认打 AssetBundle 时包含了对应变体否则真机上会出现“材质紫色”“效果丢失”之类的怪问题。最后说一句个人体会实时摄像机图像处理严格讲不是一个“高深算法”的问题而是一个“你能不能把管线、时机、数据流理顺”的问题。只要理解了一次 Scene 是怎么变成纹理、纹理如何处理后回到屏幕这件事后面接任何效果都只是往这张处理层上叠加新规则。别被一堆新名词吓住先拿像素化这个最简单的小功能跑通一次全流程你对整套机制的理解会立刻上一个台阶。
