MENU

文章目录

• 2026 年 03 月 22 日 • 已有 7 只咪围观过 • -学海无涯-

项目主要是移动端，恶补ing..

总览与适用范围

1. 总览

UE 移动端渲染的整体框架

UE 的移动端渲染可以理解为三层选择：平台/图形 API（Android / iOS；Vulkan / OpenGL ES / Metal）→ 渲染器路径（Mobile Forward / Mobile Deferred）→ 具体功能开关（阴影、反射、后处理等）。在 UE 5.5 的“移动侧”更新中，官方明确强调 Mobile Forward 增强（包括矩形区域光、胶囊阴影、体积雾、Niagara 粒子灯、以及移动端 SSR 等）。 1

从“渲染管线”角度，移动端一帧通常仍然遵循：可见性（InitViews/剔除）→ 阴影深度（ShadowDepths）→（可选）深度预通过（PrePass）→ BasePass（输出颜色/或写入移动 GBuffer）→ 光照/阴影合成 → 半透明 → 后处理。移动端的具体 pass 结构，和 Mobile Forward / Mobile Deferred 的分叉，在 UE 的移动渲染分析文章中有较清晰的 RenderDoc 截帧与流程拆解（FMobileSceneRenderer）。 2

移动端“延迟着色”的引入，本质上是为了把“每个物体都要按灯算一遍”的成本，部分转换为“先写 GBuffer、再按屏幕算光”的成本，从而更适合“灯多/局部灯多”的场景；但它也会显著增加 Render Target、带宽与内存压力。 3 2 4

与 PC/主机渲染相比的关键差异

移动端相比 PC/主机，差异不在“概念”，而在“默认策略 + 可用硬件特性 + 可持续功耗”。

1) 硬件架构更偏 TBDR（Tile-Based Deferred Rendering）/片上 tile memory，强调“减少系统内存读写、减少过度绘制、减少不必要的 pass 依赖”。 5
2) 带宽与功耗是长期瓶颈：移动 GPU 想一直维持高性能更难，通常需要你主动把“每像素的读写/采样/分支/后处理”压下去，否则很快触发热降频。 6 7 8
3) 功能层面：PC/主机常见的“高端动态光影与反射体系”（例如大规模动态阴影、复杂 GI/反射）在移动端要么是阉割版、要么是高端机/实验性路径。UE 5.5 对移动端新增特性明显集中在“Mobile Forward 画质补齐 + 移动 SSR 打通”。 1 9 10
4) Shader 与 RT（Render Target）策略更保守：移动端的“每像素 texture bandwidth”很宝贵（含 GBuffer 写入、后处理读写、阴影/反射采样）。Arm 的优化建议里直接把“纹理带宽”作为 fragment shader 关键瓶颈之一。 8

注：原 Deep Research 在线图像轮播占位符已移除；Markdown 导出不支持该交互组件。

为什么移动端在灯光、阴影、反射上限制更多

移动端“贵”的根因，通常不是某个功能“算不出来”，而是算得出来但算不久/算不稳/算不齐：

  • 带宽（Bandwidth）：
    灯光/反射/阴影经常意味着额外 RT、额外采样、额外读写（ShadowMap、GBuffer、SceneColor/Depth/Normal）。纹理读写一多，fragment shader 就容易“喂不饱”，性能直接被带宽卡死。 8 5
  • Overdraw（过度绘制）：
    透明、粒子、UI、复杂半透明叠加，会把“每像素的着色次数”乘上去；Forward 路径下尤其典型，因为光照计算往往发生在物体被绘制时。Apple 直接把“最小化 overdraw、减少不必要依赖与 load/store”作为性能优化核心主题之一。 5 2
  • Shader 复杂度与纹理采样：
    高光/法线/清漆/多层材质/SSR/PPR 都会明显增加 ALU 和采样，且采样常常就是带宽。 8 2
  • 分辨率与后处理：
    大多数后处理按像素成本线性或近似线性随分辨率增长；SSR、Bloom、TAA、色调映射都属于“屏幕空间”类，分辨率一上去，成本就非常直接。 2 3 11
  • 热降频与电池：
    Android 官方把“热状态”视为应用潜在性能上限，并建议监控 thermal headroom 并动态下调工作负载。长时间运行（例如 10–20 分钟）比短跑 benchmark 更能暴露“灯光/反射太重导致掉帧”的真实问题。 6 7

影响移动端画面与性能的核心瓶颈（你在项目里应该怎么理解）

  • 带宽：像素越多、RT 越多、采样越多 → 越容易被卡。 8
  • Overdraw：透明/粒子/叠层 UI/大量重叠几何 → “同一像素重复算”。 5 2
  • Shader 复杂度：材质指令数、分支、函数、清漆/复杂 BRDF、SSR/PPR → “每次算得更贵”。 8 11 2
  • 纹理采样：法线、粗糙、金属、AO、反射 cubemap、阴影贴图、后处理链 → “更贵 + 更吃带宽”。 8 3
  • 分辨率：屏幕空间技术成本与像素数强相关。 3 11
  • 后处理：MobileHDR 打开后，后处理链条通常明显更重，但也能显著提升观感（Bloom、Tonemapper、Color Grading 等）。 2 1
  • 热降频/电池：持续高功耗 = 掉频 = 帧率/稳定性下降。 6 7

2. 说明适用范围

引擎版本与“你应该默认相信什么”

  • 以 UE 5.5 的官方发布描述为“功能引入依据”（例如移动 SSR、矩形区域光等），并以 5.5.4 Hotfix 作为版本落点：5.5.4 属于 hotfix，主要是修复类发布。 1 12
  • 由于部分移动功能和“渲染路径/设备 profile/图形 API”强绑定，任何“是否可用”都必须拆到 Mobile Forward vs Mobile Deferred、以及 Vulkan vs OpenGL ES vs Metal 来谈。 3 4 13

目标平台与图形 API

  • Android：Vulkan / OpenGL ES（GLES）都需要考虑，但 Google 明确把 Vulkan 作为 Android 的主要低层图形 API，并说明 OpenGL ES 仍支持但不再积极发展新特性；同时 Vulkan 的优势包括更低 CPU 开销、更现代的特性（含 bindless、光追等）。 14 7
  • iOS：图形 API 为 Metal；移动端渲染架构高度 TBDR，强调减少系统内存流量与 overdraw。 5
  • UE 在移动端提供 Mobile Forward / Mobile Deferred，并且还提供“桌面渲染器上移动端”的实验路径（通常是 Android Vulkan / iOS 高端机）。 1 3

“正式可用 / 实验性 / 不推荐 / 兼容性差”的标记规则

为方便你在项目落地做决策，下文统一使用四级标记：

  • 官方支持（可量产）：功能在 UE 5.5 的官方移动更新中被明确列入移动渲染能力，或在移动相关文档/配置体系中长期稳定存在，且不依赖“桌面渲染器跑在手机上”。 1 3
  • 理论可行但不推荐：能跑，但成本或风险大，常见于“多一次整场景渲染”“重后处理链”“重阴影/重反射”类。 3 11 15
  • 某些设备可跑但不稳定：通常与高端机、特定 GPU/驱动、特定 API（多为 Vulkan/Metal）绑定；或者 UE 明确标为 Experimental（例如移动端 Lumen）。 9 10 3
  • 基本不适合量产：依赖 SM6 / 桌面级渲染器 / 大量 RT 与带宽，且在移动端缺乏官方“稳定覆盖”的预期。以 Android 为例，Arm 甚至指出 UE 默认并不官方支持 Android SM6，因此诸多桌面级特性（如 Nanite/VSM 路线）天然不该作为常规移动量产依赖。 16 17

移动端灯光体系

3. 把“灯光”拆开逐项讲（重点）

先给你一个“移动端灯光”的底层心智模型

移动端灯光要先分清两件事：

1) 光照来自哪里：

  • 静态（烘焙）：Lightmass → Lightmap（含方向性可选）+（可选）Volumetric Lightmap（给动态物体采样间接光）。 18 19 20 21
  • 动态（实时）：Directional 的 CSM 是移动端最常见的动态阴影方案；局部灯（点/聚光）通常受数量限制，且阴影支持更苛刻。 2 21 22 3

2) 你用哪条移动渲染路径：

  • Mobile Forward：更“省 RT/GBuffer”，但局部灯数量与特性约束更明显；UE 5.5 在 Mobile Forward 上加了很多画质特性补齐（矩形区域光、胶囊阴影等）。 1 2
  • Mobile Deferred：更容易承载“多灯/更复杂反射/更接近桌面 blending 的反射捕捉器”等，但 GBuffer 与带宽成本更高，并且在 OpenGL ES 上可能需要额外开关（r.Mobile.AllowDeferredShadingOpenGL）。 3 4 13
关键落地建议：
你在移动端做灯光，不是“能不能做”，而是“把实时部分压缩到极少数关键灯 + 把大部分质量放到烘焙/材质/后处理补偿”。

各类灯光与移动端支持：工程化对照表

下面表格以“默认移动渲染器（Mobile Forward / Mobile Deferred）”为主，不把“桌面渲染器跑在手机上”当作常规量产方案（会在替代方案/风险里单列）。 1 3 "Mobile Rendering and Shading Modes for Unreal Engine")

表内“量产级别”统一用：
S（官方支持可量产） / A（能跑但谨慎） / B（部分设备/不稳定） / C（基本不量产）
灯光类型量产级别是否支持支持条件（常见硬门槛）渲染原理概述（移动端视角）性能成本主要来自哪里常见画面问题推荐替代方案低/中/高端设备建议
Directional Light（平行光）S支持常用于“主光 +（可选）CSM 动态阴影”；动态阴影通常用 CSM；级联数在移动端有上限与项目设置限制。 2 "剖析虚幻渲染体系（12）- 移动端专题 Part 1（UE移动端渲染）") 22 "Use Cascaded ShadowsUnreal Engine 4.27 Documentation")移动端通常“最多 1 个关键方向光”（太阳），配合 CSM 做近距离实时阴影；其余间接光依赖 Lightmap/Skylight/反射。 2 3ShadowDepths（渲染阴影贴图）：级联数 × 阴影分辨率 × 投影到阴影里的三角形数；带宽：采样 ShadowMap；shader：每像素阴影过滤。 15 2 22阴影锯齿/闪烁、Peter-panning（阴影飘）、阴影漏光、远处阴影突然消失（距离/级联配置）。 22 "Use Cascaded ShadowsUnreal Engine 4.27 Documentation") 23远景用烘焙阴影+近景 CSM；对不重要物体关闭接收 CSM（Receive Mobile CSMShadows）；用 Modulated Shadows（仅 Stationary 方向光）做“便宜阴影”。 22 2低端：1 级联/低距离/少投射体；中端：2 级联默认；高端：可试 3–4 级联但要控距离与投射集合。 22 2
Point Light（点光）S/A（无阴影时可量产）支持（但限制多）移动端局部灯数量通常受“每物体/每像素最多影响灯数”限制，常见上限 4；默认不建议开点光阴影。 21 24 2Forward：多为“附加局部灯”在 BasePass/ForwardLighting 里做简化计算；Deferred：可承担更多点光（历史上可到 8 movable 点光的演示）。 3 2GPU/Shader：每像素对每盏灯计算；overdraw：forward 下被遮挡的像素也可能算；CPU：灯影响的物体列表/批次。 15 25 2光照“断层”（超过灯数上限后灯不生效）、亮斑不稳定、不同机型衰减/高光差异。 21 24 26用 Emissive 假光、用 Light Function/IES（若目标路径支持）做“少灯更像”；把点光改成聚光（阴影成本通常更低）。 1 15 24低端：尽量 0–1 个近景点光；中端：控制在 2–4 且无阴影；高端：可考虑移动 Deferred + 更多点光但要控半径与叠加区。 21 3 25
Spot Light（聚光）S/A（有阴影时谨慎）支持UE 在移动端支持聚光照明；移动端“可动聚光阴影”历史上默认关闭，需要显式开启相关 cvar/项目设置；并受“可见阴影聚光数上限”约束。 3 2 13Spot shadow 通常用 2D shadow map；在移动端实现会把聚光阴影与 CSM 共享采样/图集等资源以省开销。 2 3ShadowDepths：额外 shadow map 渲染；带宽：额外阴影采样；shader：聚光衰减+阴影过滤；CPU：受影响物体/批次。 15 3 2设备上不出阴影（开关/Quality/Permutation 问题）、阴影糊/抖、阴影被 atlas 挤压导致分辨率变化。 3 2 23用无阴影聚光 + 烘焙阴影贴图/Decal/顶点 AO；用少量“关键聚光”强调主体，其余用 Emissive/反射捕捉器补观感。 2 1 3低端：基本不做聚光阴影；中端：允许 1–2 个关键聚光（尽量不投影或低分辨率）；高端：可做少量聚光阴影但要做设备分级。 3 6 15
Sky Light（天光）S支持常与 Reflection Capture/Reflection Environment 共同决定环境镜面；Stationary/Static 更常见，移动端通常依赖捕捉的 cubemap。 3 23Skylight 贡献 IBL（漫反射环境光 + 镜面环境反射）；移动端反射多来自 cubemap（Skylight/Reflection Capture），并可能混合 Lightmap。 3 2带宽/采样：环境 cubemap 采样；shader：BRDF 计算；内存：cubemap 分辨率/数量。 2 3“画面发灰/没方向感”、室内漏光（Skylight 过强）、反射不对（捕捉器布置/材质粗糙度问题）。 27 2 28用烘焙 AO/顶点 AO 强化接触；用分区 Reflection Capture；室内用局部 cubemap/盒体捕捉器。 27 2 3低端：Skylight 静态 + 低分辨率反射；中端：合理分区捕捉；高端：可配合移动 SSR 做局部提升。 3 1 2
Rect Light / Area Light（矩形区域光）S（5.5 起明确支持）/A（需谨慎验证）支持（UE 5.5 明确列为 Mobile Forward 新增能力）UE 5.5 官方说明 Mobile Forward 支持“rectangular area lights”。注意：这不等价于“桌面端所有 area light 特性全量”，通常仍需做设备验证与材质/阴影策略收敛。 1多数实时引擎里的“Rect Light”本质是对面光源的近似（影响高光形状/衰减），而非真正面面积积分；移动端会更偏近似以控成本。 1 3shader：更复杂的高光形状/采样；若叠加阴影/体积雾，成本迅速上升；overdraw：forward 下被遮挡像素也可能算。 25 5 1画面“高光很怪/过亮”，不同机型高光一致性差；在低端机上可能造成明显掉帧或被 device profile 直接降级。 26 6 1如果目标只是“窗户亮边/软高光”：用 emissive + 反射 cubemap；用条形灯贴图（Decal）或高光假表面。 2 1低端：尽量不用；中端：只放 1–2 个关键 rect light；高端：可用但要严格 profiling。 6 15 1
Emissive 作为假光照S支持（材质级）需要材质管线允许 Emissive；移动端常用 Unlit/Emissive“画亮”，并用后处理 Bloom 提升“像在发光”。 2 1不参与真实光照传递，但可以“直接把颜色加到最终结果”并配合 Bloom/Color Grading 形成观感；也可做假高光/边缘光。 2 1很便宜：主要是材质自身的 ALU/采样；若 Bloom/TAA 开启则把成本转移到后处理。 3 6“像贴图在发光但不照亮场景”、夜景缺少间接光感觉；过强时会曝光/色调映射失控。 2 6用烘焙（把发光贡献 bake 进 lightmap）、用局部假光（少量点/聚光无阴影）、用反射捕捉器增强镜面。 18 3 2低/中/高端都建议大量使用（是移动端的“画质性价比核心”）。 2 6

Static / Stationary / Movable：移动端支持与差异（你必须会的“落地规则”）

  • Static：直接光 + 间接光都进烘焙（Lightmap），运行时最省 GPU，但灵活性最低；移动端想要稳定 30/60fps，Static 通常是基本盘。 18 29 2
  • Stationary：一般用于“灯不动但要影响动态物体一些效果”的折中；它比 Static 复杂得多（需要把静态部分与动态部分组合），社区回答也强调 Stationary 的实现复杂度更高。 24 3
  • Movable：完全实时，移动端最贵；如果再叠加阴影，则成本通常呈“乘法上升”。 15 6 2
一个非常工程化的结论：
在移动端，你要把 Movable 当作“稀缺资源”。把“光会动”当作玩法需求，而不是默认美术需求。

Lightmass / 烘焙 / Lightmap / Indirect Lighting / AO：移动端最核心的“主力方案”

Lightmap 是移动端“长期稳定画质”的底座：UE 文档摘要明确指出 Lightmap 主要用于“静态网格的 baked/precomputed lighting”。 18
Lightmass（Epic Games 体系内的预计算光照工具）负责生成：

  • 直射阴影 + 反弹光（GI/Indirect）+ AO（可选）等静态光照信息。 29 18

方向性 Lightmap（Use Lightmap Directionality）：移动端可以选择是否让 Lightmap携带方向性（允许结合每像素法线获得更立体的凹凸感）。官方移动性能建议摘要明确说：开启会更真实但更贵；关闭会更“平”但更便宜。 21 2

Volumetric Lightmaps（给动态物体“采样间接光”）：

  • UE 的发布日志介绍了：Volumetric Lightmaps 用砖块与采样点覆盖 Lightmass Importance Volume，并在 GPU 上插值到任意位置，从而让角色/粒子等动态物体能获得低成本的预计算光照“落地感”。 19
  • 社区在“移动端不工作”的排查中也确认 Volumetric Lightmaps 在移动端可用，并解释了常见误解：它采样的是间接光颜色而不是静态阴影投影；如果你想让静态墙体阴影影响动态物体，需要用动态 CSM 阴影（例如把投影阴影的墙变成 Movable 以走 CSM）。 20 22

压缩与内存：Lightmap 的压缩开关会显著影响包体与运行时内存。CPU Lightmass 文档摘要直接指出：禁用 lightmap 压缩可减少压缩伪影，但会让内存与磁盘体积增加约 4×。 18

动态光、逐像素光、逐顶点光、附加光数量限制（移动端“最容易踩坑”的那条线）

移动端的局部灯（点/聚光）通常有“数量上限”与“每物体可影响灯数上限”。典型案例：项目设置里很多人看到“最多 4 个 Movable 点/聚光影响”的限制，并在论坛询问是否能强推更高，说明这个限制在真实项目里非常常见。 21 24
在 UE 的移动端渲染拆解中也明确提到：Forward 路径下局部灯总数通常不能超过 4。 2

为什么移动端局部灯贵：从底层解释

  • Forward 下：每个像素在绘制每个物体时就要把“会影响它的灯”算一遍；如果还有 overdraw，被遮挡像素也会算，浪费非常直接。 25 5 2
  • Deferred 下：把光照从“物体空间”转移到“屏幕空间”，可以更好地处理多灯（尤其是很多小灯），但以 GBuffer 的额外 RT/带宽为代价。 3 2 4

移动端阴影类型与支持情况：CSM、距离场阴影、接触阴影、VSM 等

这里先给“结论式地图”，后面在支持矩阵里再汇总：

  • CSM（Cascaded Shadow Maps）：移动端方向光动态阴影主力。移动端可调“级联数上限”，默认常为 2；并且“Far Cascades + Dynamic Cascades 的总数不能超过移动端 MaxCascades 设置”。 22 2
  • 按物体接收 CSM 的开关：receive_mobile_csm_shadows（移动端专用）可以让某些组件不接收 CSM，从而减少着色成本。 22
  • Spotlight 阴影（移动端）：历史上“可动聚光阴影”需要显式开启，且受可见数量/分辨率/atlas 约束。 3 2
  • Point Light 阴影（移动端）：在移动端渲染拆解中给出很直接的原因：点光阴影需要立方体阴影贴图，而“一次 pass 渲染立方体阴影”的技术需要桌面级特性（例如几何着色器/SM5 能力），因此移动端默认不支持/不推荐。 2
  • 胶囊阴影（Capsule Shadows）：UE 5.5 官方明确把它列为 Mobile Forward 新增支持能力之一（常用于角色、性能相对可控）。 1
  • 虚拟阴影贴图 VSM（Virtual Shadow Maps）：它是面向“电影级资产、开放世界、大量动态阴影与 Nanite”设计的桌面体系；且往往与更高 Shader Model/桌面渲染路径绑定。移动量产中通常不把它当默认选项，而是视作“桌面渲染器/高端实验路径”的内容。 16 17

移动端反射体系

4. 把“反射”拆开逐项讲（重点）

先把“移动端反射”分成三类输入源

移动端反射几乎总是以下三类混合（区别在“真实度 vs 成本 vs 覆盖范围”）：

1) 反射捕捉器（Reflection Capture）/反射环境（Reflection Environment）：离线/静态 cubemap 为主，成本可控，是量产基石。 27 2 3
2) 屏幕空间反射（SSR / 移动端 SSR / PPR）：只反射“屏幕里看得到的东西”，质量提升明显但有缺失与稳定性问题；UE 5.5 明确宣布移动端 SSR 在 Mobile Forward 与 Deferred 均可用。 1 3 11
3) 真实平面反射（Planar Reflection）/ SceneCapture 类：画质强但通常意味着“再渲染一次场景”或额外 RT，移动端很容易爆。 3 15 28

反射方案对照表（支持、原理、代价、风险、项目适配）

同样用 S/A/B/C 四级标记。

反射方案量产级别是否支持支持条件（常见硬门槛）原理（移动端视角）主要性能消耗点画质优缺点兼容性风险替代方案推荐项目类型
Reflection Capture（反射捕捉器）S支持放置 Sphere/Box Capture；移动端可启用“捕捉器压缩”以节省内存/带宽（默认可用 ETC2 等）。 2 28预先捕捉环境为 cubemap，运行时按材质粗糙度/法线做 IBL 镜面反射；移动端常为“每物体取最近捕捉器”，可能缺少视差校正。 27 2 3内存：cubemap 分辨率×数量；带宽：像素采样 cubemap；加载：反射贴图驻留。 2 8优点：稳定、覆盖全局、成本可控；缺点：与真实几何不一致、动态物体不更新、室内外过渡需要精心布置。 27 2不同机型纹理格式/压缩差异、某些 GPU（如 Mali + OpenGL）可能出现反射异常案例需要专项测试。 26 14结合 Skylight；增加 capture 分区；在关键平面叠加移动 SSR/PPR。 3 1全类型项目（写实/二次元/休闲）都应作为默认底座。 1 2
Sphere / Box Reflection CaptureS支持Sphere 更适合局部、Box 更适合室内盒状空间；需要按房间/走廊分区布置，避免跨区污染。 27 2同上，但用不同形状定义影响范围；移动端由于可能缺少视差校正，Box 的“空间感”不一定等于桌面。 27 3同 Reflection Capture（内存/带宽/采样）。 8 2常见问题：墙角反射“漂”、房间切换时反射跳变、金属过强导致“像镜子贴图”。 27 2 28设备 profile 造成分辨率/压缩差；capture 过多导致内存上涨。 2 18用更少 capture + 更好的材质粗糙度分布；关键镜面平面用 PPR/Planar。 11 1 28室内、角色换装大厅、赛车车库等“局部环境反射强”的场景。 27 2
Reflection Environment（反射环境）S支持依赖 Reflection Capture 与 Skylight；移动 deferred 可支持更高级的“按像素 blending”。 3 2把捕捉器反射作为环境镜面项参与 BRDF；高端路径可做多 cubemap 混合提高过渡质量。 3主要还是 cubemap 的内存/带宽。 8 2优点：稳定；缺点：动态遮挡/动态物体反射缺失。 27 3Forward vs Deferred 的一致性差；OpenGL ES 下高级 blending/数组纹理能力可能受限。 3 13 14用移动 SSR 做局部补足；对二次元项目可用“高光+环境贴图”解决大多数需求。 1 2大多数项目默认开启（写实越依赖）。 1 2
Skylight 对反射的影响S支持Skylight 捕捉/指定 cubemap；移动 deferred 明确支持“Skylight support for reflection”。 3 2Skylight 的 cubemap 是反射的重要来源，尤其当场景 capture 不够密时。 3 27cubemap 采样与 BRDF；间接影响曝光/色调映射。 2 6室内泛蓝/泛灰、反射过统一、金属“脏”。 2 27设备差异相对小，但需要做室内外分区与不同 capture。 27 2室内用 Box Capture 强化；写实项目配合轻量 SSR。 1 11全类型项目。 2
SSR（移动端 SSR）A（高端机量产可用，需分级）UE 5.5 起支持UE 5.5 官方确认“SSR now work in both Mobile Forward and Deferred”；通常要求 Mobile HDR，且移动端 SSR 很多实现依赖 TAA 稳定画面。 1 30 2屏幕空间基于 SceneColor/Depth（以及可能的法线/粗糙）追踪反射；移动端常用更受限/更高性价比的形式（例如 PPR）。 11 3 2带宽：读 SceneColor/Depth/可能的中间 buffer；shader/compute：追踪/投影/修补孔洞；分辨率：越高越贵。 11 3 8优点：细节真实、接触反射自然；缺点：屏幕外缺失、边缘断裂、法线粗糙导致噪点/闪烁。 11 31不同 GPU 对精度/半精度、纹理格式、TAA 链路影响大；需要 device profile 分级与真机覆盖。 6 2 26反射捕捉器 + 关键平面 PPR；对低端直接关闭 SSR，用材质/后处理假高光。 2 11 1写实室内/车漆/水面等“需要接触反射”的项目（高端机优先）。 1 3
Planar Reflection（真实平面反射：再渲染一次）B/C理论可行但很贵平面反射通常意味着“按反射视角再渲染一次场景”；在移动端容易直接把 GPU/带宽打满。 3 15 28用反射相机渲染反射纹理，再投射到平面；画质接近镜子。 3最贵点：额外一次（或近似一次）场景渲染；额外 RT；额外带宽；额外过度绘制。 3 5优点：镜面正确且屏幕外也有；缺点：成本爆、容易掉帧/发热。 3 6机型差异极大；一旦动态物体多就更难控。 6 15用 PPR/移动 SSR 替代；或用静态 cubemap 伪反射。 11 2 3仅极少数“镜子是核心玩法/卖点”的高端机项目或 Demo。 6 3
Pixel Projected Reflection（PPR）/ MobilePPRA（强烈建议在“平面反射需求”里优先于 Planar）支持（移动友好反射）需要 Mobile HDR；通过 cvar 控制 r.Mobile.PlanarReflectionMode 与 r.Mobile.PixelProjectedReflectionQuality；并依赖特定 Planar Reflection Mode（MobilePPR 等）。 3 2 28PPR 是受限的 SSR：把反射限定在“平面/解析反射区域”，用“反向投影/数据散射”替代昂贵的逐像素 ray-march，获得更好的性能/质量比。 11 3 2主要成本：额外中间 buffer + 投影 pass + 反射 pass；仍是屏幕空间，成本随分辨率上升。 11 3 8优点：比全 SSR 更稳、更便宜；缺点：只适合平面、对粗糙/非平面有限制、仍会有缺失/孔洞。 11 3依赖 Mobile HDR 与设备性能分级；项目设置/模式不对时“看起来像没反射”。 28 2 6反射捕捉器作为全局底，PPR 只用在水面/地面/镜面地砖等关键平面。 11 27 2写实室内地面、水面、车展台等“可用平面近似”的项目。 3 11
Scene Capture Cube / 2D（动态捕捉）C基本不量产（移动端动态更新非常贵）本质是额外相机渲染；Cube 等于 6 次（或近似 6 次）视角渲染。 3 15运行时更新反射贴图/RT。超高 GPU + 带宽：多次渲染 + RT；还可能引入同步/依赖。 5 15优点：动态真实；缺点：基本不可控。兼容性不仅是机型，还常常是“发热后必崩”。 6 15改为离线 bake cubemap；或用反射捕捉器静态。 27 2仅 Demo/少量展示镜面物体的高端体验。
Cubemap 伪反射（材质采样）S支持只要材质允许采样 cubemap；常用于“车漆/金属/玻璃”的稳定反射观感。 2 27把环境 cubemap 当作镜面近似输入，结合粗糙度/法线做 BRDF。 2 3便宜：主要是 cubemap 采样；成本随采样次数/LOD 变化。 8 2容易“假”，反射与场景不一致；但可通过粗糙度与艺术调参掩盖。 27 2风险小、兼容性好。与反射捕捉器/Skylight 一起使用。 27 2全类型项目（尤其二次元/风格化）。
Lumen / 硬件光追 / 软件光追 / RT Reflections 与移动端B/C（视为实验/高端特化）UE 文档摘要：移动端 Lumen 为 Experimental（高端 Android）“Using Lumen on Mobile”摘要表述：UE 5.4+ 在高端 Android 设备上提供 Lumen 实验支持；“Lumen Technical Details”摘要也写到 Lumen 支持 Android Vulkan 并可用于 Mobile Renderer。 9 10Lumen 是动态 GI/反射体系，通常依赖更高计算/带宽与更复杂的场景表示；移动端仅在特定高端条件下尝试。 9 10很昂贵：计算 + 带宽 + 内存；且对稳定帧率/热降频非常敏感。 6 8 9画质上限高，但移动端往往要降质量/降距离；也可能遇到“看起来没 GI/没反射”的配置坑。 9兼容性风险大（设备、驱动、API、机型分级）。 9 6 26量产建议：以烘焙 GI + 反射捕捉器 +（可选）PPR/SSR 为主。 2 1 3仅高端写实、且愿意做严格设备白名单/动态调度的项目。 6 9

“哪些反射方案适合量产、哪些只适合演示”的一句话结论

  • 量产默认组合：Reflection Capture（分区） + Skylight + 材质正确的粗糙度/金属度分布。 27 2 3
  • 高端机增强：在关键平面启用 PPR/移动 SSR 做接触反射提升（并用 device profile 分级）。 1 11 2
  • 演示/非量产常见坑：动态 SceneCapture（尤其 Cube）、全场景 Planar Reflection、多处镜面大面积实时反射。 3 15 6

材质与观感补偿

5. 材质与灯光/反射的关系（反射重点）

BaseColor / Metallic / Roughness / Specular / Normal / AO：对移动端光照的实际影响

移动端的光照与反射很大一部分由“材质参数”决定，尤其是：

  • Metallic 与 Roughness：决定你看见的是“漫反射”为主还是“镜面反射”为主，以及反射的清晰度/能量分配。反射捕捉器/Skylight/SSR 的观感差异，往往首先是粗糙度分布差异。 2 3 27
  • Normal：决定高光与反射的细节破碎度；移动端若关闭方向性 Lightmap，会让法线在“纯烘焙环境光”下显得更平。 21 2
  • AO：在移动端常被用作“廉价的接触感与间接遮蔽补偿”；因为真实 SSAO/GTAO 要额外屏幕空间计算。 3 2
  • Emissive：不照亮环境，但可与 Bloom/色调映射结合，成为移动端“灯光感”的性价比核心。 1 2

为什么很多“反射问题”本质上是材质问题（重点）

移动端最常见的“反射看起来不对”，通常不是反射系统坏了，而是：

1) 粗糙度过低/过统一：
把大量表面做成“接近 0 粗糙度”的镜面，会把反射捕捉器的缺陷、SSR 的缺失边界、cubemap 的不一致全部暴露。先把 roughness 做出合理分布，反射质量会“立刻像是提升了一档”。（这是工程经验，但它与“捕捉器反射是近似、屏幕空间反射有缺失”这两个事实强相关。） 27 11 2
2) 法线尺度/细节频率不对：
过强法线会导致高光碎裂、SSR/PPR 更噪；过弱法线让反射像贴图。 11 2
3) 金属度误用（把非金属当金属）：
常见于新手：把塑料/木头做成金属，导致过强镜面能量，反射“假得很明显”。（PBR 误用会把移动端近似反射的缺陷放大。） 2 27
4) 材质路径不兼容导致“移动端 fallback”：
移动端材质有功能限制（例如纹理采样器数量、部分表达式/着色模型不可用），一旦触发 fallback，观感可能与 PC 预览差很多。移动渲染分析里明确提到 ES3.1 下纹理采样器数量有限、可用着色模型更少。 2

移动端材质性能：指令数、采样数、分支、透明、双面、Clear Coat 等

移动端成本一般优先看“fragment shader 是否被带宽喂不饱”：

  • Arm 的 fragment shader 优化建议明确指出：纹理会消耗大量内存带宽，带宽过量会导致 fragment shader 无法获得足够数据。 8
  • 透明/Masked 材质在移动端非常贵（overdraw + late-z + blending），移动渲染分析也强调透明/Masked “极其耗性能，建议尽量不透明”。 2 5
  • 采样器数量：移动端硬件限制会让你在复杂材质上更容易踩到上限（例如 ES3.1 常见限制 16 个采样器）。 2
常见工程策略：
用“Fully Rough / 降精度 / 合并贴图通道 / 减少层数 / 避免依赖纹理读取（dependent texture read）”来换稳定帧率。 2 8 5

PBR 在移动端的常见误区（专门列出）

  • 误区：把“写实”理解成“到处镜面”。正确做法是粗糙度做分布、金属度做物理正确，否则反射系统的近似会被放大成“假”。 27 2
  • 误区：用大量实时灯去补材质问题。移动端局部灯昂贵且受上限约束，先把材质、烘焙与反射捕捉器做对，再用少量灯点睛。 21 15 2
  • 误区：透明材质想要像桌面一样“又便宜又好”。透明在移动端基本是“成本炸弹”，且反射/灯光模型可能受限（例如需要特殊的 Lighting Mode 才能在某些平台生效）。 28 2 5

如何用材质假装更高级的灯光或反射效果

  • 用 Emissive + Fresnel 做边缘光/假高光；再用 Bloom 把“亮”扩散成“在发光”。 1 2
  • 用“局部环境贴图（局部 cubemap）”叠加在关键材质上（例如车漆/玻璃），绕开 SSR 的缺失与捕捉器过渡问题。 27 2
  • 对二次元/风格化：把“高光形状”当作美术贴图/曲线控制，而不是追求物理正确反射，这在移动端通常更稳定、更便宜。 2 8

6. 后处理与观感补偿

Bloom、Tonemapper、Exposure、Color Grading、AA、屏幕百分比：如何影响灯光/反射观感

  • UE 5.5 官方移动更新中提到 Mobile Forward 新增的“更高画质特性”，很多都需要配合 Mobile HDR/后处理链才能真正体现在观感上（例如 Bloom 对 Emissive 的“发光感”贡献非常大）。 1 2
  • PPR/移动 SSR 这类屏幕空间反射，本质上与 SceneColor/Depth 强耦合，后处理链（尤其 TAA）会影响稳定性与噪点/闪烁。社区关于移动屏幕空间反射的讨论也明确提到“移动 SSR 需要 TAA”的设定提示。 30 11 3
  • 曝光（Auto Exposure）/色调映射（Tonemapper）会决定高光是否“糊成一团”或“亮不起来”；移动端若关闭某些后处理，会直接改变灯光层次感。 2 6

哪些后处理移动端性价比高，哪些代价大（工程口径）

  • 高性价比（常用）：Bloom（适度）、Color Grading（LUT/轻量参数）、基础 Tonemapper。它们对“氛围感、发光感、整体色彩统一性”的提升很直接。 1 2
  • 代价偏大（谨慎）：屏幕空间 AO（尤其 GTAO）、SSR/PPR（取决于质量档位与分辨率）、复杂 DOF、复杂体积效果叠加。移动端渲染分析明确指出：移动设备因 dependent texture read、带宽与 RT 解析等限制，后处理在移动上更耗甚至会“卡住渲染管线”。 2 5 8
  • 体积雾（Volumetric Fog）：UE 5.5 提到 Mobile Forward 支持体积雾，但它通常不应在低端机默认开启，而应做分级。 1 6

当不能上真实反射/动态光时，如何补偿

  • 用烘焙 GI（Lightmass）解决“暗部发黑/没反弹光”的大问题。 18 29 2
  • 用反射捕捉器分区 + 材质合理粗糙度，解决“金属像塑料/反射空”的大问题。 27 2
  • 用 Emissive + Bloom/Color Grading，解决“灯光不够戏剧化/不够亮”的问题。 1 2
  • 用 PPR 在少数关键平面上提升“接触反射”，而不是全场景 Planar 反射。 11 3 6

性能成本框架与支持矩阵

7. 讲性能成本时的统一框架（含分级与底层原因）

统一成本拆解：你在 Profiling 时要对应到“哪一类瓶颈”

CPU 开销（偏 CPU 瓶颈）

典型来源：

  • Draw call 提交与状态切换、灯光影响物体列表构建、阴影投射体遍历。Arm 的 Vulkan vs OpenGL ES 对比强调：Vulkan 更低 CPU overhead，且多线程更友好；这在“多灯、多阴影、多 pass”项目里尤其关键。 7 14
  • 动态灯光阴影的 CPU 成本往往与“灯数 × 受影响物体数 × 物体分裂程度”相关；论坛给出公式化描述：CPU 侧 ~ NumberOfLights NumberOfMeshesAffected NumberOfSeparateObjects。 15

GPU 计算开销（偏算力瓶颈）

典型来源：

  • 逐像素光照（多灯叠加）、阴影过滤、SSR/PPR 追踪或投影计算。 25 11 2

带宽开销（偏带宽瓶颈）

典型来源：

  • 多 Render Target（GBuffer/后处理链）、高分辨率 ShadowMap、SceneColor/Depth 多次读写。Apple 强调“尽量减少系统内存流量”；Android AGI 文档也把 texture memory bandwidth 作为可观测瓶颈。 5 8 14

Render Target / 深度 / GBuffer / Shadow Map（偏带宽 + 内存）

  • Mobile Deferred 的 GBuffer 会增加 RT 数量与读写。 2 3
  • ShadowMap（CSM/Spot shadow）对 RT 与带宽同样敏感，且阴影深度 pass 还会额外消耗几何处理。 15 22

Shader Complexity（偏算力 + 带宽）

  • Arm 指出纹理带宽与 fragment shader 性能强相关；移动渲染分析也强调 dependent texture read、采样器限制、半精度/全精度选择会直接影响性能与瑕疵风险。 8 2

Overdraw（偏 overdraw 瓶颈）

  • 透明、粒子、UI 会直接把片段着色次数倍增；Apple 把“最小化 overdraw”作为核心最佳实践之一。 5 2

纹理内存与反射贴图内存（偏内存瓶颈）

  • Reflection Capture cubemap 数量与分辨率直接影响内存；Lightmap 压缩开关影响包体与运行时内存（禁用压缩可增到约 4×）。 2 18

分辨率变化对反射/阴影成本的影响

  • SSR/PPR/后处理按像素成本增长；CSM 的阴影分辨率与级联数增加也会增长。 11 22 2

热降频与长时间运行

  • Android 官方指出设备只能维持高性能有限时间，建议监控 thermal headroom 并主动降负载；这意味着你必须把“高端灯光/反射”当作“可动态降级”的质量档，而不是固定开关。 6 14

功能成本分级（相对概念 + 为什么如此）

说明：以下分级是“在移动端普遍场景下”的相对概念；真实成本仍取决于分辨率、材质复杂度、场景几何、灯影响范围、设备 GPU 与驱动。 6 8 15
  • 很便宜：Emissive（不带复杂采样）、静态反射捕捉器采样（少量）、静态 Lightmap（压缩开启、分辨率合理）。 2 18 27
  • 较便宜：1 盏无阴影 Directional（仅直接光）、少量无阴影局部灯（≤4，半径小）、基础 Bloom/Color Grading。 21 1 2
  • 中等：Directional + 1–2 级联 CSM（距离短）、少量聚光阴影（数量极少）、PPR 低质量档（关键平面）、移动 Deferred（但控制 GBuffer 与后处理）。 22 3 11 13
  • 昂贵：3–4 级联 CSM、多个阴影聚光、移动 SSR（较高质量/高分辨率）、体积雾叠加、多 RT 后处理链。 22 1 11 6
  • 很昂贵：真实 Planar 反射（再渲染一次）、动态 SceneCapture（特别是 Cube）、移动端 Lumen（实验/高端）、桌面渲染器跑在手机上（实验路径）。 3 9 16

8. 支持矩阵（灯光/阴影/反射/后处理汇总）

说明：矩阵以“移动渲染器（Mobile Forward/Deferred）”为主要对象；“Desktop Renderer on Mobile”单独列为实验路径。 1 3
功能名移动端是否支持是否推荐量产主要代价（偏向）主要风险推荐替代方案适合项目类型低/中/高端建议
平行光 Directional支持推荐CSM/阴影贴图（GPU+带宽）阴影锯齿/漏光/距离断层烘焙远景 + 近景 CSM；关闭部分物体接收 CSM全类型低端 1 级联；中端 2 级联；高端 3–4 但控距离 22 2
CSM（移动）支持推荐（但要控）ShadowDepths（GPU）+ 采样（带宽）cascades 超限/距离不当降级级联数/距离；烘焙阴影写实/中重度项目低端短距离低级联 22 2
Receive Mobile CSMShadows（按组件）支持强烈推荐（优化手段）降低 shading cost（省 GPU）关闭后“看起来没影”只关次要物体全类型全档位建议用 22
点光 Point（无阴影）支持（受上限）推荐（少量）每像素多灯（GPU/overdraw）超上限灯不生效Emissive 假光；改聚光多数项目低端尽量不用；中端≤4 21 2
点光阴影通常不支持/不推荐不推荐立方体阴影贴图（极贵）基本不可控用方向光 CSM/聚光阴影/烘焙少数 Demo不建议 2 15
聚光 Spot（无阴影）支持（受上限）推荐（少量）每像素光照（GPU）超上限/Shader permutationEmissive/Decal 假投影室内/舞台光低端少用 2 21
聚光阴影（Movable）支持（需开启）谨慎ShadowDepths + 采样（GPU+带宽）配置/质量档导致不出阴影降阴影数/分辨率；改烘焙写实重点灯高端机分级 3 2
Skylight支持推荐cubemap 采样（带宽/内存）室内漏光/发灰分区 capture；烘焙 AO全类型全档位建议 3 27
Rect Light（5.5 Mobile Forward 新增）支持（5.5 明确）中高端谨慎量产shader 更重（GPU）设备差异/发热掉帧emissive + cubemap写实/展示低端避免 1 6
Capsule Shadows（5.5 Mobile Forward 新增）支持（5.5 明确）推荐（角色类）较省（相对）形体逼真度有限贴花/顶点 AO角色主导项目低中端也可 1
Lightmass Lightmap（静态）支持强烈推荐包体/内存（带宽/内存）UV/压缩伪影/漏光合理密度；必要时关压缩（代价大）全类型全档位核心 18 29
Use Lightmap Directionality支持按项目取舍更贵但更立体（GPU）低端压力关闭方向性 + 材质补偿风格化/低端低端可关 21 2
Volumetric Lightmaps支持推荐（有动态角色时）内存/插值（中等）误解导致“看似没效果”配合 CSM/烘焙角色/动态物体中高端更适配 19 20
Reflection Capture（含压缩）支持强烈推荐cubemap 内存/带宽布置不当跳变分区布置/压缩全类型全档位核心 2 28
Mobile SSR（5.5 打通）支持（5.5）高端分级推荐带宽+计算（昂贵）缺失/闪烁/精度差PPR/反射捕捉器写实/车漆/水低端关 1 11 30
PPR（Pixel Projected Reflection）支持推荐用于平面中等到昂贵（屏幕空间）开关/模式不对无效capture + 仅关键平面 PPR水面/地面中高端 3 11 28
Planar Reflection（真实再渲染）理论可行不推荐很昂贵（额外渲染）掉帧/发热PPR/SSRDemo基本避免 3 6
后处理链（Mobile HDR）支持推荐但要克制带宽/RT（中等到昂贵）低端掉帧只保留 Bloom/ColorGrading全类型低端精简 2 5
Lumen（移动端）Experimental不推荐常规量产很昂贵（全链路）兼容性与稳定性风险大烘焙 + capture + PPR高端写实特化白名单+动态降级 9 6
Desktop Renderer on Mobile（Vulkan Desktop 等）Experimental不推荐很昂贵/不为移动优化包体/兼容/性能风险用 Mobile Forward/DeferredDemo/实验极少数高端 3 16

项目决策、排错、优化与学习路径

9. 项目决策树（简版，但可直接落地）

写实项目

  • 目标：稳定 30fps（广覆盖）
    选择：Mobile Forward + 静态 Lightmass（高质量烘焙）+ Reflection Capture 分区 + 少量无阴影局部灯 + 近景短距离 1–2 级联 CSM。 2 22 18
  • 目标：45–60fps（中高端）
    在上面基础上：关键平面加 PPR；或在高端机开移动 SSR（必须 device profile 分级 + TAA 与质量档联动）。 1 11 6

二次元/风格化项目

  • 方向：减少真实动态光依赖，把“体积感/高光形状/边缘光”交给材质与后处理（Emissive + Fresnel + Bloom）。
  • 灯光：1 个 Directional（可无阴影或短距离阴影）+ 合理 Skylight + 捕捉器；局部灯尽量少、尽量不投影。 2 1

俯视角项目

  • 俯视角天然利好：遮挡关系稳定、镜头不易贴地，CSM 距离可压得很短；反射多用 capture 即可。 22 27

开放世界项目

  • 关键矛盾：阴影覆盖距离与稳定性。
  • 建议：Directional + 分级 CSM（低端短距离、少级联；高端更远一些但控投射集合）；远景依赖烘焙/贴图阴影；尽量避免多处实时反射。 22 15 6

室内场景项目

  • “反射捕捉器分区”是底座：Box Capture 按房间/走廊布置；关键地面/水面用 PPR。 27 11 2

竞速/射击/卡牌/休闲分类（快速策略）

  • 竞速（车漆反射敏感）：capture + 高端 SSR/PPR 分级；局部灯少而精。 1 11
  • 射击（性能/稳定优先）：Directional + CSM 短距离；大量 emissive/贴花/后处理做氛围。 22 2
  • 卡牌/休闲（成本最敏感）：尽量 Unlit/简化 Lit；以烘焙与材质假光为主。 2 8

10. 排错手册（≥30 条，表格）

说明：下表覆盖灯光、阴影、反射、材质、配置、平台差异与驱动差异。验证步骤优先用“真机 + profile + 逐项关开 + 设备分级”。 6 2 26 28 22
现象根因归类如何验证如何修复如何避免再次出现
手机上反射几乎没有/很弱配置/反射捕捉器缺失场景里是否放了 Reflection Capture；材质金属/粗糙是否合理布置 Sphere/Box Capture；合理粗糙度；启用 capture 压缩制作规范：每个室内区必须有 capture；材质审核粗糙度分布 27 2
预览有反射，打包到 Android 没反射平台差异/配置真机查 Mobile HDR、Planar Reflection Mode、相关 cvar开启 Mobile HDR；设置 MobilePPR；设置 r.Mobile.PixelProjectedReflectionQuality>0用 device profile 固化开关；真机回归测试 28 2 3
PPR/Planar Reflection 在 iOS/Android ES3.1 不工作配置/材质模式检查材质透明 Lighting Mode；检查 Mobile HDR调整水材质 Lighting Mode（必要时用更昂贵的模式）；确认 Mobile HDR建立“水材质移动端模板”并锁定参数 28 6
反射边缘断裂/屏幕外缺失功能限制（SSR/PPR）观察物体离开屏幕后反射是否消失用 capture 兜底；限制 SSR 只用于关键区域；提高粗糙度掩盖默认反射以 capture 为主，SSR/PPR 只加分 11 27
某些 Mali + OpenGL 机型反射异常/破碎驱动/GPU 差异只在特定 GPU/特定 API 复现；切 Vulkan 对比优先 Vulkan；对该机型降级反射（关闭 SSR/降低 cubemap 分辨率）建立 GPU 白名单/黑名单；上线前覆盖 Mali/Adreno/Apple 26 14 6
烘焙后物体发黑资源/Lightmap UV/密度Lightmap Density/Lighting Static Mesh Info 检查修 UV2；提高关键物体 Lightmap 分辨率；检查光照重要体积资源规范：UV2 无重叠、合理留白、密度分级 18 32
烘焙阴影有明显块状压缩伪影压缩设置/带宽取舍对比开启/关闭 Compress Lightmaps关键场景可禁用压缩（代价：内存/包体约 4×）；或提高分辨率+优化 UV默认开启压缩；只对极少数关键地图禁用并单独评估 18
动态角色在静态阴影下“漂浮”功能限制（静态阴影不投到 Movable）查看 Volumetric Lightmap 是否开启；角色是否只采样间接光用 Volumetric Lightmaps；或用 CSM 给角色接收/投射近景阴影标准做法：动态角色必须用 VLM + 近景 CSM 19 20 22
Volumetric Lightmap 看起来“没效果”常见误解观察间接光颜色是否变化，而不是静态阴影投影正确认知：VLM 提供间接光；静态阴影不影响 Movable培训规范：区分“间接光采样”与“阴影投射” 20 19
动态光在手机上不生效配置/灯数上限检查是否超过移动端局部灯上限；查看 Project Settings 动态灯数降低局部灯数量；缩小半径；改用 emissive/烘焙灯光规范：局部灯必须有预算表与半径上限 21 2
点光/聚光超过 4 个时部分灯“消失”功能限制（上限）把灯逐个禁用，观察是否轮换控制在上限内；改用移动 deferred（高端）；合并灯/用 emissive设计阶段就锁定“每屏幕最大灯数” 21 2
阴影锯齿严重分辨率/级联/滤波调整 CSM 级联数、距离、分辨率；看 aliasing缩短阴影距离；提高关键级联分辨率；减少级联数但提高近景质量根据镜头设定“阴影距离预算” 22 23
阴影闪烁/爬行精度/级联切换/偏移观察相机移动时阴影边缘抖动调整 shadow bias；优化级联分布；减少远距离阴影统一项目 shadow bias 标准；锁定移动端质量档 22 2
远处阴影突然消失配置（CSM distance）对比不同 shadow distance（Mobile）增加动态阴影距离（谨慎）；或改为烘焙远景阴影镜头设计阶段定“阴影最远可见距离” 23 22
Far CSM 不生效配置（MaxCascades）检查 Num Dynamic Cascades + Far Cascades 是否超 MaxCascades提高移动端 MaxCascades 或减少总 cascades统一 shadow cascade 预算与上限 22
某些物体接收阴影成本过高过度接收 CSM开启/关闭 receive_mobile_csm_shadows 对比 GPU对小物体/远景关闭接收 CSM资源导入规则：小物体默认不接收 CSM 22
聚光阴影在移动端不出配置（Permutation/开关）检查是否开启 movable spotlight shadow 相关设置开启相应 cvar/项目设置；控制可见数量建立“移动端灯光开关清单”并锁版本 3 2
水面反射在编辑器有，手机上没有配置/材质/模式检查 Mobile HDR、Planar Reflection Mode、材质透明 Lighting Mode按移动端要求设置；必要时改材质 Lighting Mode移动水材质模板 + 真机验证 28 2
透明材质反射表现差功能限制/透明成本对比不透明版本；查看透明 Lighting Mode尽量用不透明假玻璃；必要时使用更贵的透明模式并限用UI/特效规范：透明层数预算、限制大面积透明 28 5 2
Android 与 iOS 观感差别大平台差异（TBDR/精度/纹理格式）同一场景跨平台截图对比；检查半精度模拟统一色调映射与后处理；对 Android 做 device profile 分级建立“Android Vulkan/Android GLES/iOS Metal”对照测试矩阵 5 14 2
Mobile Previewer 与真机不一致工具限制以真机为准；对比 Mobile Previewer“指定 device profile”用 UE 5.5 的 Android profile capture/半精度模拟功能辅助，但最终以真机验收流程上规定“预览仅用于迭代，验收必须真机” 1
开启 SSR 后明显掉帧带宽/屏幕空间计算GPU profile 看后处理/反射 pass降 SSR 质量/分辨率；只在高端机开启SSR 默认只在高端档位启用 11 6 1
SSR 噪点/闪烁严重TAA/精度/粗糙度观察是否随帧抖动；检查是否启用 TAA启用 TAA（若移动 SSR 依赖）；提高 roughness；降低强镜面面积材质规范：移动端避免大面积粗糙度=0 的镜面 30 11 27
PPR 看起来“像没开”配置/模式检查 r.Mobile.PlanarReflectionMode 与 r.Mobile.PixelProjectedReflectionQuality设置正确模式（MobilePPR 等），并确保 Mobile HDR 开启把相关 cvar 固化到 DefaultEngine.ini + device profile 3 2 28
反射 capture 过多导致内存上涨/加载慢内存瓶颈统计 capture 数量与分辨率；查看纹理内存合并 capture 区域；降低分辨率；开启压缩制作规范：capture 必须有“最大数量/分辨率”限制 2 8
包体变大（Lightmap/反射贴图）资源/压缩策略对比关压缩/高分辨率 lightmap 的差异开启 lightmap 压缩；控制 lightmap 密度；压缩 capture资源审查：Lightmap Density + lightmap 统计 18 32
发热后帧率明显下降热降频记录运行时间与 thermal headroom；观察掉帧与温度相关性动态降级：降分辨率/关 SSR/降阴影距离/降特效接入 Android Thermal API 思路做质量自适应（至少做“长跑测试”） 6 14
Vulkan 比 OpenGL ES 更不稳定（闪退）驱动/设备差同机型切换 API 对比对问题机型回退 GLES；或做 Vulkan 白名单设备分级：Vulkan 默认、但保留 GLES fallback（或反之） 14 6
OpenGL ES 画质功能缺失API 能力差异检查是否使用了需要 Vulkan/Metal 的特性对 GLES 降级：关移动 deferred/关高级反射从立项就决定 GLES 目标与功能上限 14 13 2
移动 deferred 在 OpenGL 预览不工作工具/预览限制观察 Mobile Preview（OpenGL）是否无法显示 deferred不用 OpenGL 预览判定 deferred；以真机为准；需要时开启 r.Mobile.AllowDeferredShadingOpenGLQA 流程：deferred 必须 Vulkan/Metal 真机验证 4 13
GI/间接光“看起来没了”配置/项目状态检查是否关闭 static lighting；检查烘焙是否有效重建光照；确认 lightmap/VLM；不要误指望移动端实时 GI项目策略：移动端 GI 默认走烘焙；实时 GI 仅实验高端 18 9 6
场景太灰/没对比Skylight/曝光/色调映射调整曝光、Skylight 强度、Color Grading用局部对比 LUT；加 AO/顶点 AO；减少 Skylight 漏光美术规范：室内外分区 capture + 曝光策略 2 6 27
高光异常（某些机型特别亮/特别暗）精度/驱动差异/材质同材质在不同 GPU 对比；切半精度/全精度对关键材质启用全精度；降低高光能量；做机型分级关键材质必须跨 Mali/Adreno/Apple 回归 2 6 26
动态阴影不显示（打包后）配置/质量档检查 Directional 是否 Movable；检查动态阴影距离设置正确 mobility 与距离；检查 device profile 是否把阴影质量设为 0出包前真机 checklist：阴影开关、质量档、profile 全检查 23 22 6
阴影成本突然升高投射体过多/级联过大GPU profile 看 ShadowDepths；统计投射网格减少投射体、简化阴影网格、缩短距离阴影投射体规范：树叶/小件默认不投射 15 22
多灯导致 CPU 也卡CPU 侧灯-物体组合爆炸观察 RenderThread/GameThread 与灯相关开销减灯、减受影响物体、减对象分裂；批处理灯预算不仅看 GPU，也要看 CPU 组合规模 15 7
反射 capture 切换时“跳变”明显布置问题走到 capture 边界观察跳变调整 capture 影响范围与重叠策略；移动 deferred 提升 blending（高端）关卡规范：capture 分区必须覆盖且边界在不显眼处 27 3
车漆反射像“贴纸”材质粗糙/法线/捕捉器降低镜面强度、调整 roughness 纹理；检查 capture做真实 roughness 分布；加局部 capture；高端加 SSR车漆材质作为专项：必须真机标定 27 1 6
夜景灯光“像没有照亮”功能限制（发光不照场景）关掉 post，看 emissive 是否只是贴图亮用烘焙把灯光贡献 bake 进 lightmap；少量真实灯补关键区域夜景策略：静态 GI + emissive + bloom 优先 18 1 2
Lumen 在移动端无效/不一致实验性/兼容性检查是否 Android Vulkan 高端机；是否开启实验路径回退烘焙方案；只在白名单启用；提供开关不把 Lumen 作为移动端默认依赖 9 6

11. 优化清单（上线前“TA 检查表”）

技术美术上线前检查项（建议你做成 Jira/飞书 checklist）

  • 渲染路径：Mobile Forward/Deferred 是否符合项目定位；Android 是否 Vulkan 为默认；OpenGL ES 是否作为 fallback。 14 13 1

  • 灯光预算：

    • 方向光是否唯一主光；CSM 级联数、距离、投射体集合是否在预算内。 22 15
    • 点/聚光数量是否不超过移动端上限；是否有“同屏最大影响灯数”规范。 21 2

  • 阴影预算：

    • 哪些物体必须接收 CSM，哪些必须关闭 receive_mobile_csm_shadows。 22

  • 反射预算：

    • Reflection Capture 是否按室内外/房间分区；数量与分辨率是否受控；是否启用压缩。 28 27 8
    • SSR/PPR 是否仅高端档位启用，且有 TAA/分辨率联动策略。 1 30 11

  • 烘焙与 Lightmap：

    • Lightmap UV2 是否合格；密度是否分级；是否存在“禁用压缩导致内存暴涨”。 18 32

  • 材质规范：

    • 透明/Masked 是否严格限制层数与覆盖面积；采样器数量是否逼近上限；是否大量 dependent texture read。 2 8 5

  • 长时间稳定性：

    • 至少做 20–30 分钟真机“长跑”，记录帧率曲线与热状态；必要时做动态降级。 6 14

设备分级建议（工程做法）

  • 低端：关 SSR/PPR、短距离 CSM、少局部灯、强烘焙、材质 Fully Rough 倾向。 2 22
  • 中端：少量 PPR（关键平面）、2 级联 CSM、局部灯 ≤4（无阴影）。 11 21 22
  • 高端：可尝试移动 SSR（谨慎）、更多后处理、少量聚光阴影，但必须受热策略约束。 1 6

性能 profiling 流程（推荐顺序）

1) 先确定是 CPU bound 还是 GPU bound（并锁定代表性场景）。 21 6
2) GPU bound：先看 ShadowDepths / 后处理 / 透明过度绘制 / SSR(PPR) / BasePass。 15 2 11
3) CPU bound：看 draw call、灯影响组合、阴影投射体遍历、PSO/管线创建（尤其 Vulkan）。 7 1 15
4) 热问题：用 Android Thermal API/头寸指标确认是否“热导致掉帧”。 6

12. 学习路径（入门→进阶→高级→项目实战）

入门阶段（你应该在 1–2 周内掌握）

必学知识点：

  • Mobile Forward vs Mobile Deferred 的区别（为什么 deferred 更适合多灯，但更吃 RT/带宽）。 2 4
  • Lightmap/Lightmass 的基本工作流：UV2、密度、重建光照、压缩影响。 18 32
  • Reflection Capture 的布置与材质粗糙度对反射观感的决定性影响。 27 2

容易混淆概念：

  • “反射捕捉器”≠“实时反射”；“Emissive 发光”≠“照亮环境”。 27 1

练习：

  • 做一个室内房间：只用静态光照 + capture 分区，目标是在低端机保持稳定帧率。
    达到水平：
  • 能把“画面黑/灰/反射假”通过烘焙与材质解决到“可上线质量”。 29 2

进阶阶段（你开始能做“分级与取舍”）

必学知识点：

  • CSM 级联数、距离、投射体与性能的关系；会用 receive_mobile_csm_shadows 做局部优化。 22
  • 局部灯上限与“为什么移动端多灯贵”的底层原因。 21 25 5
  • PPR 基本原理与启用条件（Mobile HDR、PlanarReflectionMode、质量档）。 3 11 28

练习：

  • 做一条走廊：2–3 个局部灯（无阴影）+ 1 个主方向光（短距离 CSM）+ 走廊分区 capture + 地面 PPR。
    达到水平：
  • 能稳定完成“中端机 45fps/高端机 60fps”的画质分级策略。 6 14

高级阶段（你能从“管线与硬件”解释并解决问题）

必学知识点：

  • 带宽、RT load/store、overdraw、texture sampling 的硬件视角（TBDR、tile memory）。 5 8
  • Vulkan vs OpenGL ES 的 CPU overhead 与稳定性取舍，如何做设备白名单/黑名单。 14 7 6
  • 真机热稳定：学会用 thermal headroom 判断“为什么 10 分钟后掉帧”。 6

练习：

  • 做一套 device profile：低/中/高三档，动态调整阴影距离、SSR 开关、分辨率比例。
    达到水平：
  • 能指出问题更偏：算力/带宽/内存/overdraw/shader，并给出可执行的降级路径。 6 8

项目实战阶段（你能带团队上线）

必学知识点：

  • “灯光与反射预算表”制度化：每关/每镜头/每玩法场景有明确预算。 15 6
  • 资产制作规范：Lightmap UV、材质层数、透明叠层、capture 布置规范。 32 2 27
  • 回归测试体系：跨 GPU/跨 API/长跑热测试。 6 26 14

练习：

  • 选一个真实关卡，做“从 PC 观感迁移到移动端”的完整落地：保留核心卖点，明确砍掉哪些特性。 9 1
    达到水平：
  • 能在立项阶段给出“可上线的灯光与反射方案”，并在中后期把风险收敛到可控范围。

移动端灯光与反射设计总原则

1) 移动端永远先定“默认底座”：静态 Lightmass（含 VLM）+ 反射捕捉器分区 + 合理材质粗糙度，是最稳的量产骨架。 18 19 27 2

2) 把实时当作“高端增强层”，而不是默认层：移动 SSR/PPR、聚光阴影、体积雾、矩形区域光，都应做 device profile 分级，并默认可被热策略降级。 1 6 3

3) 每个“贵”都能追到一个底层原因：

  • 多灯 → forward 下 overdraw 乘法；deferred 下 GBuffer/带宽上升。 25 4
  • 阴影 → ShadowDepths 额外几何 + 采样带宽。 15 22
  • 反射 → cubemap 内存/带宽；SSR/PPR 读写 SceneColor/Depth。 8 11 27

4) 先修材质，再谈反射：一半以上的“反射问题”是粗糙度/金属度/法线/透明模式导致的“近似被放大”。 27 2 28

5) 用最少的阴影达成最大叙事：Directional CSM 只给玩家近景信息；远处阴影交给烘焙、贴图、AO、构图与色调。 22 18 2

6) 把“长时间稳定帧率”当成第一 KPI：移动端性能不是一次跑满，而是持续不掉；热降频是移动上线的真实敌人。 6 14

7) 对高端实验路径保持清醒：
移动端 Lumen、桌面渲染器跑手机、SM6 相关路线（Nanite/VSM 等）要么是 Experimental，要么依赖特定设备与修改；不要把它们当作移动量产的默认依赖。 9 16 17

8) 最终以真机为准：UE 5.5 虽增强了 Mobile Previewer，但移动端依旧是“设备/驱动/精度/格式”的组合问题；项目流程必须以真机覆盖与 device profile 分级收敛风险。 1 6 26

重建参考链接

  1. Unreal Engine 5.5 is now available
  2. 剖析虚幻渲染体系（12）- 移动端专题 Part 1（UE移动端渲染）
  3. Mobile Rendering and Shading Modes for Unreal Engine
  4. Using the Mobile Deferred Shading Mode in Unreal Engine
  5. Harness Apple GPUs with Metal - WWDC20
  6. Thermal API | Android game development
  7. Use Vulkan for graphics | Android game development
  8. Android Game Development Kit overview (AGI / texture bandwidth / shader profiling)
  9. Using Lumen Global Illumination on Mobile in Unreal Engine
  10. Lumen Technical Details in Unreal Engine
  11. Mobile Rendering | Unreal Engine 4.27 Documentation
  12. 5.5.4 Hotfix Released
  13. Unreal Engine Console Variables Reference
  14. Features and APIs Overview | Android 15 graphics
  15. Guidelines for creating game with dynamic lights only and good performance
  16. Mali and Unreal Engine’s Nanite: Enabling the future of mobile graphics
  17. Virtual Shadow Maps in Unreal Engine
  18. CPU Lightmass Global Illumination in Unreal Engine
  19. Volumetric Lightmaps in Unreal Engine
  20. Volumetric Lightmaps not working on mobile
  21. Performance Guidelines for Mobile Devices in Unreal Engine
  22. Use Cascaded Shadows | Unreal Engine 4.27 Documentation
  23. Lighting for Mobile Platforms | Unreal Engine 4.27 Documentation
  24. How to increase mobile Max Moveable Spotlight / Point Lights?
  25. What is the cost of dynamic point lights?
  26. Broken reflections on Android Mali
  27. Reflections Captures in Unreal Engine
  28. Rendering Settings in the Unreal Engine Project Settings
  29. Stationary Light Mobility in Unreal Engine
  30. Screen Space Reflections on mobile require TAA (forum discussion)
  31. Planar Reflections in Unreal Engine
  32. Understanding Lightmapping in Unreal Engine

turn 占位符到链接映射

Unreal Engine
返回文章列表 打赏
本页链接的二维码
打赏二维码
添加新评论