先说结论透明玻璃是 VR 项目里最容易被低估的 GPU 杀手。你要是打开 Frame Debugger 刷一帧看看通常会发现整个场景的 Overdraw 和屏幕覆盖率有一大半都是玻璃制品贡献的——而且是那种“看着好看、性能惨不忍睹”的贡献。我在优化 Pico 4 和 Quest 2 一体机项目时只要场景里有展柜、窗户、酒瓶这类透明物体帧时间最先崩掉的区域十有八九就在这。这一篇是 Unity VR 优化实战的第五篇前几篇聊过大纲帧、阴影和光照烘焙这次专门拆透明玻璃、屏幕覆盖率Screen Coverage和 Overdraw 三者的关系。先说人话版本VR 是双眼渲染所有屏幕空间开销天然翻倍透明的材质又要多次采样、多次混合这两件事叠在一起足以让原本 60 帧的 PC 场景在同一颗移动 GPU 上掉到 40 帧。这篇文章适合已经在做 VR 项目、被帧率坑过的人看也适合刚接触 Unity VR 优化、想搞清楚“为什么玻璃这么费”的新手。我会把原理、工具用法、实测数据、替代方案和踩坑记录全部摊开讲尽量给到可以直接抄作业的程度。1. 一帧里的三笔账Overdraw、屏幕覆盖率与像素填充率1.1 VR 对像素开销的“双倍惩罚”机制先算一笔硬账。Pico 4 的单眼分辨率为 2160×2160双眼合计是 4320×2160接近 933 万像素。LCD 屏刷新率是 90Hz意味着 GPU 每秒至少要处理 8.4 亿个像素的着色工作量。Quest 2 的单眼是 1832×1920双眼 3664×192090Hz 下每秒约 6.3 亿像素。这还没算透明物体的多层绘制。把这串数字翻译成实际感受你每往屏幕上多叠一层半透明材质GPU 就得把整块区域再重新算一遍。就像搬家时你本来只需要搬一趟箱子结果每个箱子外面还要套三个纸壳车次直接翻四倍。在 PC 上GPU 功率高、带宽大多叠几层无所谓但在 XR 一体机上芯片功耗和带宽都被锁死Overdraw 每多 1 倍真机发热和掉帧就肉眼可见地加剧。还不止如此。VR 渲染普遍用 Single Pass Instanced左右眼各渲染一次到各自的 Render Target中间切换 View 和投影矩阵。这意味着所有三角形、所有 Fragment Shader 的执行次数都要乘以 2。如果某个透明物体在一只眼睛里覆盖了屏幕 30% 的面积实际片元处理量就是 60% 的屏幕空间——两个眼睛加起来。这就是为什么屏幕覆盖率这个指标在 VR 里这么关键。1.2 帧预算拆解到底留了多少余量给透明物体做 VR 优化你得先有一张预算表。以 72Hz 为例一帧的硬性预算是 13.9ms90Hz 对应 11.1ms120Hz 的设备只有 8.3ms。这里我特意说“硬性预算”因为实际上你不能真的用满——一体机还要给追踪、双倍缓冲和系统 UI 留时间安全线通常是预算的 75% 到 80%。实测一个典型场景的帧时间分布大概是这样的渲染阶段预算占用说明不透明场景4.5ms静态网格、光照贴图、阴影阴影与深度1.2ms平行光阴影、级联透明物体2.0ms粒子、玻璃、水、UI 半透明层后处理1.5msMSAA 解析、色调映射其他1.0ms束、屏幕空间效果如果你的透明物体只占屏幕 10%2ms 够用。但当玻璃柜占屏幕 30% 时透明阶段可能直接涨到 5ms 以上整帧就被顶出预算。所以优化透明玻璃的核心不是把玻璃删掉而是把它的屏幕覆盖率和单像素成本同时压低。2. 屏幕覆盖率VR 场景的“伪性能指标”为何致命2.1 覆盖率不是 Draw Call但它比 Draw Call 更隐蔽很多人优化性能第一反应是抓 Draw Call看到 Batches 从 300 降到 120 就觉得很开心。但在 VR 一体机上Draw Call 在 300 以内通常不是主要瓶颈真正的瓶颈是像素填充率和带宽。屏幕覆盖率恰恰是决定填充率的一个核心变量。Coverage 的定义很简单一个物体在屏幕上投射的像素面积占总屏幕面积的百分比。一个大玻璃窗可能只有 1 个 Draw Call但覆盖了屏幕 25% 的面积。配合折射、反射、模糊多层处理它可以通过 1 个 Draw Call 干出相当于 4 个不透明物体的像素工作量。在 Frame Debugger 里你可以打开 Overdraw 视图用颜色区分描绘次数白、绿、黄、红。红色区域通常意味着那个像素被重复绘制了 5 次以上。我见过一个咖啡厅场景地面和墙面都正常但玻璃展柜区域一片通红覆盖率接近屏幕的 35%整帧因此多花了 3.7ms。这就引出一个很有用的判断原则在 VR 里屏幕覆盖率超过 15% 的透明物体就必须单独评估它的着色成本。不要看它有几个 Draw Call要看它覆盖了多少像素、每个像素执行了几次 Fragment Shader。2.2 怎么用 Frame Debugger 和 RenderDoc 量化覆盖率量化覆盖率有两种常用工具路径。第一种Unity 自带 Frame Debugger。打开 Window Analysis Frame Debugger逐 Draw 回放在 Overdraw 模式下看颜色分布。你不需要精确到像素只要看大面积的红黄区域集中在哪几个物体上再用鼠标点击那个 Draw 的事件右侧会显示 Mesh、Material、Pass 等信息。这套操作适合快速定位“哪一摊东西在烧像素”。第二种RenderDoc。它对 Unity 的支持很成熟Windows 和 Android 都能抓帧。抓完一帧后进 Texture View 查看 Render Target再切换到 Overlay 模式里的“Triangle List”或“NaN”只是辅助真正有用的是 Mesh Viewer 里的 Vertex/Fragment Shader 统计以及 Event Browser 里每个 Draw 的 Pixel Shader Threads 数量。这个数值几乎等于覆盖率×多次绘制的放大系数。实操里我一般这样组合用先用 Frame Debugger 刷一遍评估哪些物体是大面积透明再用 RenderDoc 对特定 Draw 看 PS Threads 数值算出它在两个眼中的总像素负担最后把结果回填到上面那张预算表里判断要不要动手优化。这套流程在真机上跑一遍不超过二十分钟比靠玄学猜高效得多。3. 透明玻璃为什么是 Overdraw 大户3.1 一块普通玻璃表面上看只有一层实际画了三层很多初学者以为玻璃就是“一个半透明材质”实际上典型的 PBR 玻璃渲染路径是这样的先要画一层不透明背景场景里玻璃后面的物体再画玻璃本身的漫反射和镜面反射接着做折射采样屏幕颜色最后可能还要叠加边缘发光、脏迹贴图和菲涅尔效果。就拿一个最常见的玻璃 Shader 来说// 典型玻璃 Shader 的 Pass 结构伪代码 Pass 0: ZWrite Off, Blend SrcAlpha OneMinusSrcAlpha { // 采样主纹理 // 采样立方体贴图 Reflection Probe 做反射 // 采样 GrabPass _RefractionTex 做折射 // 计算 Fresnel混合反射和折射 } GrabPass { _RefractionTex }GrabPass 本身就是隐形的杀手。它会把整个屏幕内容抓进一张纹理相当于额外执行一次全屏拷贝和采样。虽然 Unity 在部分平台上可以做优化但在移动端 VR 一体机上这张 GrabPass 纹理往往就是单眼屏幕分辨率的 RGBA32带宽消耗非常可观。更麻烦的是如果你在场景里放了四块玻璃四块都需要抓屏哪怕用了同一个 GrabPass 名字Unity 也可能只在第一块玻璃时抓一次。但如果你每个玻璃用的材质不同、名字不同就会抓好几次。我在项目里见过同一帧里 GrabPass 被抓了三次的情况帧时间直接多了 1.8ms纯属白烧的电量。3.2 透明物体的排序和混合每个像素都在做算数除了采样多透明混合本身也贵。半透明物体的标准混合公式是最终颜色 源颜色 × 源透明度 目标颜色 × (1 - 源透明度)。这看起来只是几个乘加运算但如果一个像素被画了 5 层透明物体每个像素就要做 5 次混合计算而且这些计算是按像素串行执行的没法像不透明物体那样通过 Early-Z 直接丢弃。VR 场景里还有一个常见灾难多个透明物体排序错误。假设你有一块玻璃窗户窗外又是一个半透明遮罩再往前是玩家的武器、粒子特效。渲染顺序一旦错乱Alpha 混合结果就是错的视觉效果直接崩掉。为了保证正确性开发团队往往会给透明物体指定 Render Queue结果又引入更多 Pass、更多采样。我的建议是在 VR 里尽量把透明物体限制在两层以内。超过两层优先把中间层改成不透明。玩家在头显里看的是动态画面没人会停下来逐像素检查玻璃后面的玻璃前面的一层雾是否正确。3.3 折射与反射好看的东西都贵真正让玻璃变“贵”的是折射和反射。折射一般需要采样屏幕空间颜色要么 GrabPass要么用 Unity 的 Opaque TextureCamera Opaque Texture要么用 _CameraDepthTexture 做视差扰动。屏幕空间采样意味着你的 Shader 必须在前一帧或本帧的不透明渲染完成后才能执行这打乱了透明物体的执行顺序还可能造成一帧延迟。反射通常用 Reflection Probe。实时更新 Reflection Probe 在 VR 里简直是在烧 GPU——它意味着你要额外渲染一次 Cubemap每个面渲染一次场景一共 6 次一次可能比你主画面还费。即使是真机上的 Pico 4跑 512 分辨率的实时反射探针也要占用约 1ms 的 GPU 时间而且每帧更新会让帧时间抖动明显。所以我大量采用“静态烘焙 运行时少量更新”的策略场景里的主要反射内容提前烘焙成 Cubemap只有玩家附近的小范围变化才开一个低分辨率实时探针。这个方案在视觉上损失很小但帧时间能省下接近整个透明阶段的预算。4. 实操一次玻璃场景从“红透”到“绿油油”的完整优化4.1 优化前的现场数据一个 440ms 的咖啡厅直接拿我手头一个咖啡厅场景当案例。这个场景有一个大玻璃展示柜约 1.2m × 2.4m、两扇玻璃门、一组带玻璃瓶身的货架、一张玻璃茶几。目标设备是 Pico 490Hz帧预算 11.1ms。首轮真机实测数据指标数据帧时间13.8ms不透明阶段5.1ms透明阶段4.3ms阴影与深度1.2ms束/后处理1.0ms玻璃相关 Draw Call7 个大面积 Overdraw红区屏幕约 28%单帧 GrabPass 次数2 次Frame Debugger 里一眼看过去玻璃区域就是两块大红色块。RenderDoc 看 PS Threads玻璃展柜的 Fragment Shader 执行数是整个场景的 3.1 倍。这不是某个 Shader 写得烂而是机制性的问题玻璃覆盖了屏幕 28% 面积每个像素要做反射采样、折射采样、菲涅尔计算、混合四个成本叠起来帧时间直接被顶出预算 2.7ms。4.2 优化操作清单少渲染、少采样、少混合针对上面这块数据我做了四点修改第一把玻璃展柜的材质从“完整折射 PBR”降级成“平面折射视差模拟”。具体做法是在 Shader 里用 UV 扰动代替真正的 GrabPass 纹理采样不再抓屏。视觉上玻璃背后的物体边缘会有轻微偏移但在 VR 的快速转头场景里几乎感知不到差异。这一条直接省掉 0.8ms。第二反射探针全面离线烘焙。咖啡厅的室内环境基本不变只有玩家身上的光源是动态的。我把反射探针切换成 Baked并给玻璃材质关闭实时探针混合。省掉的实时 Cubemap 渲染一次就是 6 个 Pass肉眼可见地缓解了 GPU 压力。第三调整 Render Queue把玻璃拆成两层不透明框架和半透明镜片。框架用标准不透明材质镜片用半透明材质。这样框架部分能走 Early-Z不会被后面物体重复绘制屏幕覆盖率从 28% 降到 19% 左右。第四限制 GrabPass 只发生一次。两扇玻璃门和展柜统一使用同一个透明材质实例命名同一个 GrabPass 纹理。Unity 会复用同一张抓屏纹理不再重复抓屏。最终单帧 GrabPass 从 2 次降到 1 次而且只在场景切换时抓取。4.3 优化后的 A/B 对比真的能看出差异吗改完以后再上真机同样是在咖啡厅里转着看指标优化前优化后降幅帧时间13.8ms9.6ms30.4%透明阶段4.3ms1.9ms55.8%大面积 Overdraw红区28%7%75%实时反射探针开启关闭—GrabPass 次数2 次1 次—画面主观评价玻璃反射较强、折射真实折射轻微、反射细腻差异不明显帧时间 9.6ms留出 1.5ms 余量给系统 UI。整段优化动用的手段没碰美术资源、没降低分辨率纯粹的渲染路径修改。这是我强烈推荐的方式先改 Shader 和设置实在不行再动分辨率纹理尺寸是最后的选择。为什么因为纹理和分辨率压下去画面清晰度损失最明显VR 里模糊直接引发眩晕宁可丢点反射细节也不能降清晰度。5. 常见问题与排查技巧实录5.1 透明玻璃的 6 个高频问题速查表这里直接给一张表记录我在实际项目里反复遇到的几个问题以及对应的解法。现象根因解决方案玻璃背后物体闪烁Z-fighting玻璃与背景深度冲突对玻璃关闭 ZWrite或多个透明物分开 Render Queue两块玻璃交叠时画面黑块GrabPass 采样顺序错误用 Camera Opaque Texture 代替 GrabPass或合并材质减少抓屏玻璃边缘出现白边Alpha 混合导致边缘像素多次混合开启 Premultiply Alpha或把边缘锐化反射探针更新频繁导致卡顿实时 Reflection Probe 在移动端过度渲染换成 Baked Probe或用低分辨率 128 的实时探针限频更新玻璃太多导致帧时间抖动透明物排序和多次 GrabPass限制玻璃层数统一材质减少抓屏次数从远处看玻璃性能很好靠近就崩覆盖率随距离放大合成像素数飙升给透明物设 LOD远处降级为半透明贴图近处保留完整材质这些问题的共性是透明玻璃在 PC 上用默认设置通常没事但一旦上了真机就立刻暴露移动 GPU 的带宽和填充瓶颈。在开发阶段早一点养成“每帧看 Frame Debugger Overdraw”的习惯能省掉很多现场排查时间。5.2 几个容易忽略的“玻璃”优化死角除了上面那张表还有几个从操作层面容易漏掉的地方。第一个不要给透明玻璃开 MSAA。MSAA 本身是为了抗不透明物体边缘锯齿设计的对透明混合区域并不友好成本却按分辨率指数增加。在 VR 项目里玻璃区域的锯齿问题的核心是屏幕覆盖率和边缘亮度不是像素密度。可以尝试用 TAA 或 FXAA 替代但注意移动端 FXAA 也不要全屏用最好只对玻璃区域做 Stencil 标记后再后处理。第二个粒子系统默认渲染队列是 Transparent大量粒子会跟玻璃抢排序和 Overdraw。我的做法是把粒子拆成不透明 Render Queue 和透明 Render Queue 两批或者限制粒子数量别让它对着玻璃脸冲。第三个如果你用 URP记得检查 Camera Opaque Texture 是否打开。很多项目为了一个水面反射打开了 Opaque Texture结果全场景所有透明物体都被迫额外采样一次。这个开关一旦开启哪怕场景里没有玻璃也会凭空多出一笔带宽开销。实测影响大约在 0.4ms 到 0.9ms 之间视分辨率而定。6. 写在最后的经验总结6.1 玻璃在 VR 里保命的三大纪律做了一年多 VR 一体机优化我对透明玻璃的态度经历了从“尽量秀技术”到“能省就省”的转变。总结出三条靠得住的纪律纪律一能不用真折射就不用。屏幕空间折射的成本等于一次全屏采样加多次混合这在 VR 双眼里是致命的。视觉赚头很小性能亏空巨大属于典型的“好看但不值”。纪律二混合层数控制在两层以内。超过两层就考虑拆分、合并或改成不透明层。VR 玩家不会去细看玻璃叠玻璃他们只会觉得头晕。纪律三反射探针离线烘焙优先于实时更新。静态场景的 Cubemap 烘焙一遍够用一辈子为了让反射动起来去开实时探针不如给材质减 0.5ms。6.2 后续可以继续扩展的三个方向这个系列做到第五篇透明玻璃这块算是吃得比较透了。我自己后续想继续深挖的方向有三个一是动态折射水面和玻璃结合的优化那个坑比普通玻璃更深二是半透明粒子和玻璃交叠时的 Overdraw 控制尤其是有大量粒子在室内场景时三是利用 Stencil 做区域化后处理把全屏 Pass 限定到玻璃覆盖的局部区域进一步压低覆盖率消耗。最后再分享一个小技巧改完玻璃材质后别急着看帧率数字先在真机上以正常速度转三圈头感受有没有眩晕、有没有闪烁。帧率是硬指标但舒适度才是 VR 项目的生命线。一块折射漂亮但让人头晕的玻璃不如一块安静、稳定、干净的玻璃。