当前位置：首页 > news >正文

Unity XR中Point Light不生效的根源与解决方案

news 2026/5/25 8:32:53

1. 这个问题不是Bug，是XR渲染管线的“默认契约”

在Unity XR项目里调试点光源（Point Light）时，你大概率会遇到这种场景：场景里明明拖了一个亮度拉满、范围设到10的Point Light，Inspector里参数一切正常，运行后却像没放灯一样——模型完全不受影响，阴影不投，高光不亮，连最基础的漫反射都看不到。更让人困惑的是，把XR插件一关，或者切回Standalone平台，灯立刻就亮了。这时候很多人第一反应是“Unity XR插件出bug了”“是不是版本兼容问题”，甚至开始翻GitHub上成百上千条issue。我去年在给一家医疗AR培训系统做光照优化时，也卡在这个问题上整整三天，最后发现根本不是插件缺陷，而是Unity在XR模式下主动关闭了传统前向渲染中对点光源的逐像素计算支持——这不是疏漏，是设计使然。

核心关键词已经浮出水面：Unity XR、Point Light、不生效、前向渲染、URP/HDRP、光照剔除、GPU Instancing。这个问题横跨渲染管线、XR SDK集成、Shader编译逻辑三个层面，但绝大多数开发者只盯着“灯为什么不亮”这个表象，忽略了Unity在XR环境下为保障60fps+稳定帧率所做出的底层取舍。它本质上是一份“性能与效果的契约”：当你启用XR插件（无论是Oculus Integration、XR Plugin Management还是OpenXR），Unity会自动将渲染路径切换为前向+多视图（Multi-View）模式，并强制禁用所有非方向光（Directional Light）的逐像素光照计算，因为点光源和聚光灯的衰减计算、阴影映射、多次采样在双目渲染中开销呈指数级增长。实测数据显示，在Quest 2上开启一个中等强度的Point Light并启用实时阴影，单帧GPU耗时会从8ms飙升至23ms，直接跌破交互安全线。所以，Unity不是“忘了支持”，而是用明确的失效行为告诉你：“这里需要你手动接管”。

适合谁来读？如果你正在用Unity开发VR/AR应用，尤其是使用URP（Universal Render Pipeline）或HDRP（High Definition Render Pipeline）配合XR Plugin Management，且遇到了光照异常、模型发灰、材质无高光等问题，这篇文章就是为你写的。它不讲泛泛而谈的“检查Light组件是否启用”，而是带你钻进渲染管线底层，看清XR模式下光照被“静音”的真实原因，并给出三套可立即落地的解决方案——从修改管线配置到手写Shader替换，再到架构级规避策略，每一步都有参数依据和实测数据支撑。

2. 根源拆解：XR模式下Point Light被“静音”的四层技术断点

要真正解决问题，必须穿透Unity编辑器表面的Inspector面板，看到渲染管线内部的数据流断点。我通过Frame Debugger、RenderDoc抓帧和Unity源码片段交叉验证，确认Point Light在XR模式下失效并非单一环节故障，而是四个相互耦合的技术断点共同作用的结果。下面按数据流向逐层展开，每个断点都附带验证方法和关键参数依据。

2.1 断点一：XR插件强制覆盖渲染路径，禁用前向附加通道（Forward Add Pass）

在Standalone平台，Unity默认使用前向渲染（Forward Rendering），其光照计算分为两个Pass：Base Pass（处理方向光+环境光）和Additive Pass（逐个处理点光源、聚光灯）。而当XR插件激活后，Unity会通过XRSystem.SetRenderingMode()强制将渲染路径切换为Forward+Multi-View，此时Additive Pass被完全绕过。验证方法很简单：在XR运行状态下打开Frame Debugger（Window → Analysis → Frame Debugger），展开每一帧的Draw Call列表，你会发现所有标记为“ForwardAdd”的Pass全部消失，只剩下“ForwardBase”和“ShadowCaster”。这意味着所有非方向光的逐光源计算逻辑在GPU指令生成阶段就被编译器剔除了。

这个决策的底层依据来自OpenXR规范对多视图渲染的要求。标准前向渲染中，每个点光源需独立执行一次完整的光照计算（含世界坐标转换、衰减函数、BRDF采样），而在双目渲染中，同一光源需为左眼、右眼各算一遍，且视角矩阵不同，无法复用中间结果。Unity选择彻底禁用Additive Pass，而非尝试优化，是因为实测表明：即使仅开启一个点光源，其带来的Draw Call数量翻倍和顶点着色器压力激增，已足以让中端XR设备掉帧。我在Quest 3上用相同场景对比测试：关闭XR时ForwardAdd Pass耗时1.2ms；开启XR后该Pass被移除，但若强行通过自定义Render Feature注入类似逻辑，GPU耗时直接跳到4.7ms，且伴随明显卡顿。

2.2 断点二：URP/HDRP的Lightweight Render Pipeline Asset中，点光源剔除阈值被设为零

如果你使用的是URP（Unity 2021.3+），问题会进一步叠加。URP的渲染配置由UniversalRenderPipelineAsset控制，其中有一个关键参数：Additional Lights Per Object（每个物体允许接收的额外光源数）。在XR构建时，Unity会自动将此值重置为0。你可以在Project窗口中找到你的URP Asset，Inspector里展开“Lighting”区域，看到该字段显示为0且呈灰色不可编辑状态。这就是为什么即使你手动在场景中添加了Point Light，所有使用URP Lit Shader的物体都无视它——管线在物体可见性判断阶段就将其剔除了。

这个重置行为由XRSystem.ApplyPipelineSettings()触发，其逻辑在Unity内部SDK中固化。我反编译了com.unity.xr.management@4.3.0的DLL，找到相关代码段：当检测到XRDisplaySubsystem处于active状态时，会调用pipelineAsset.SetAdditionalLightsPerObject(0)。这并非bug，而是URP团队为XR场景预设的保守策略：避免开发者误配导致性能雪崩。但问题在于，这个值无法通过常规方式覆盖。你可能会尝试在Runtime中用C#脚本修改：GraphicsSettings.renderPipelineAsset = myURPAsset; myURPAsset.additionalLightsPerObject = 4;，但实测无效——因为XR子系统会在每一帧开始前重新覆写该值。

2.3 断点三：GPU Instancing与Multi-View冲突，导致点光源数据无法正确传入Shader

XR设备普遍依赖GPU Instancing实现双目渲染（Single Pass Instanced模式），即一次Draw Call同时渲染左右眼图像。这要求所有Shader变体必须支持Instancing宏（如#pragma multi_compile_instancing），且光源数据需通过UnityPerDrawCBUFFER传递。但Unity内置的Standard Shader和URP Lit Shader中，点光源的衰减参数（_LightPosition,_LightColor等）默认存储在UnityPerVisibleLightCBUFFER中，该Buffer在Instancing模式下无法为每个实例提供独立数据副本。结果就是：Shader收到的光源位置永远是第一个实例（通常是左眼）的坐标，右眼视角下的光照计算完全错乱，最终被渲染器判定为无效而丢弃。

验证方法：在URP项目中创建一个自定义Shader Graph，添加“Light Position”节点，连接到Albedo输出。运行XR模式，你会看到左右眼画面中光源位置明显偏移——左眼正常，右眼光源漂移到屏幕外。这证明数据传递已断裂。更隐蔽的问题是，当多个物体共享同一Mesh时（如大量Instanced Tree），UnityPerVisibleLight中的光源索引会因实例ID混乱而指向错误内存地址，触发GPU驱动的静默失败（Silent Fail），表现就是灯光彻底消失。

2.4 断点四：XR阴影系统默认禁用点光源阴影，且无UI提示

最后一个常被忽略的断点是阴影。即使你通过某种方式让Point Light参与光照计算，它的阴影依然不会出现。原因在于XR阴影系统（XRShadows）的设计哲学：只支持方向光阴影。其底层实现基于单张深度纹理（Depth Texture）和正交投影，而点光源阴影需立方体贴图（Cubemap）或六面体阴影贴图（Omni Shadow Map），这对移动XR设备的显存和带宽是灾难性的。Unity在XRSystem.EnableShadows()中硬编码了检查：if (light.type != LightType.Directional) return;。

这个限制没有在Editor中任何地方提示。你可能在Light组件里勾选了“Enable Shadows”，设置Shadow Type为“Hard Shadows”，但Frame Debugger里永远看不到Shadow Caster Pass。我曾以为是Shadow Distance参数太小，把值从50调到200，结果毫无变化。直到用RenderDoc抓取GPU命令队列，才看到所有vkCmdDrawIndexed调用中，点光源相关的阴影绘制指令根本未被提交。这是纯粹的架构级禁用，不是配置疏漏。

提示：以上四个断点并非孤立存在。断点一（禁用ForwardAdd）是总开关，断点二（URP剔除阈值）是URP特有强化，断点三（Instancing数据错乱）是硬件层约束，断点四（阴影禁用）是功能级裁剪。解决时必须按顺序处理，否则修复了A却因B失效，徒劳无功。

3. 三套实战方案：从配置调整到Shader重写，适配不同项目阶段

面对这四层断点，不存在“一键修复”的银弹。解决方案必须匹配你的项目阶段、技术栈和性能预算。我将提供三套经过生产环境验证的方案，按实施难度和效果强度排序：方案一（配置级）适合快速验证和轻量项目，方案二（Shader级）适合中大型URP项目，方案三（架构级）适合对画质有极致要求的AR/VR应用。每套方案均包含完整操作步骤、参数依据、实测性能数据及避坑指南。

3.1 方案一：绕过断点一与断点二——启用URP的“Additional Lights in Forward Base”模式

这是最快落地的方案，核心思路是放弃传统的Forward Add Pass，转而将点光源计算合并到Forward Base Pass中。URP 12.1.0+版本引入了Additional Lights in Forward Base选项，允许在Base Pass中一次性处理最多4个额外光源（含点光源、聚光灯），完美规避断点一（Additive Pass被禁用）和断点二（URP剔除阈值为0）。

操作步骤：

确保URP版本≥12.1.0（Window → Package Manager → Universal RP，升级至最新版）
在Project窗口中选中你的UniversalRenderPipelineAsset
Inspector中展开“Lighting”区域
勾选“Additional Lights in Forward Base”（注意：此项仅在URP Asset Inspector中可见，不在Project Settings里）
将“Additional Lights Per Object”值设为所需数量（建议从2开始测试，最高支持4）
重启Editor（关键！URP Asset修改需重启才生效）

原理与参数依据：
启用此选项后，URP编译器会生成新的Shader变体，在Forward Base Pass的Vertex/Fragment Shader中插入额外光源的计算逻辑。其衰减函数采用优化后的近似公式：atten = 1.0 / (1.0 + c1 * d + c2 * d²)，其中d为距离，c1/c2由光源Range参数自动计算。相比标准衰减，此公式减少一次除法运算，GPU周期节省约12%。实测在Quest 3上，开启2个点光源时，Forward Base Pass耗时仅增加0.8ms（从3.2ms→4.0ms），远低于Additive Pass的2.1ms开销。

避坑指南：

必须重启Editor：这是URP的硬性要求，不重启会导致设置不生效且无报错提示。
Shader兼容性：此模式仅对URP Lit Shader及其子类（如SimpleLit、Unlit）有效。若你使用自定义Shader Graph，需在Graph设置中勾选“Use Additional Lights in Forward Base”。
性能红线：超过4个额外光源时，URP会自动降级为“Forward Add”模式，此时断点一再次生效，灯光仍不亮。因此，此方案本质是“有限度支持”，适合主场景1-2个关键点光源的项目。

3.2 方案二：攻克断点三——手写Instancing兼容的Point Light Shader

当方案一无法满足需求（如需3个以上点光源，或需精确控制衰减曲线），就必须直面断点三：GPU Instancing下的数据传递问题。我的做法是绕过URP内置光照系统，用Custom Render Feature注入自定义Pass，并编写专为XR优化的Point Light Shader。该方案已在工业AR巡检系统中稳定运行18个月，支持单帧8个动态点光源。

核心Shader代码（简化版，用于URP）：

// PointLightInstanced.hlsl #include "Packages/com.unity.render-pipelines.universal/ShaderLibrary/Core.hlsl" #include "Packages/com.unity.render-pipelines.universal/ShaderLibrary/Lighting.hlsl" // 自定义CBUFFER，支持Instancing CBUFFER_START(UnityPerPointLight) float4 _PointLightPosition[8]; // 支持8个光源 float4 _PointLightColor[8]; float4 _PointLightParams[8]; // x: range, y: invSqrRange, z: unused, w: unused CBUFFER_END // Instancing数据 UNITY_INSTANCING_BUFFER_START(InstanceData) UNITY_DEFINE_INSTANCED_PROP(float4, _InstanceColor) UNITY_INSTANCING_BUFFER_END(InstanceData) // 主函数 half4 Frag(Varyings input) : SV_Target { half4 color = half4(0,0,0,0); float3 worldPos = input.positionWS.xyz; // 遍历所有点光源 for (int i = 0; i < 8; i++) { float3 lightDir = _PointLightPosition[i].xyz - worldPos; float distSqr = dot(lightDir, lightDir); float rangeSqr = _PointLightParams[i].x * _PointLightParams[i].x; // 距离衰减 + 角度衰减（简化版） if (distSqr < rangeSqr) { float atten = 1.0 / (1.0 + 4.0 * sqrt(distSqr) / _PointLightParams[i].x); float3 lightColor = _PointLightColor[i].rgb * atten; color.rgb += lightColor * DiffuseBRDF(input.normalWS, normalize(lightDir), _LightColor0.rgb); } } return color; }

集成步骤：

创建Custom Render Feature（Assets → Create → Rendering → Universal Render Feature）
编写C#脚本继承ScriptableRendererFeature，在AddRenderPasses()中注入自定义Pass
Pass中通过CommandBuffer.DrawMeshInstancedProcedural()提交光源数据，关键代码：

// 将场景中所有激活的Point Light数据打包到GPU Buffer List<Light> pointLights = FindObjectsOfType<Light>().Where(l => l.type == LightType.Point && l.enabled).ToList(); Vector4[] positions = new Vector4[pointLights.Count]; Vector4[] colors = new Vector4[pointLights.Count]; Vector4[] paramsArr = new Vector4[pointLights.Count]; for (int i = 0; i < pointLights.Count; i++) { positions[i] = pointLights[i].transform.position; colors[i] = pointLights[i].color; paramsArr[i] = new Vector4(pointLights[i].range, 1.0f/(pointLights[i].range*pointLights[i].range), 0, 0); } // 上传到GPU pointLightBuffer.SetData(positions); colorBuffer.SetData(colors); paramsBuffer.SetData(paramsArr);

在URP Asset的Renderer中添加该Feature

实测数据：
在Quest 3上，8个点光源全开时，自定义Pass耗时2.3ms，比URP原生方案（若能启用）低37%。关键优势在于：所有光源数据通过StructuredBuffer传递，完全规避了UnityPerVisibleLight的Instancing兼容问题，左右眼光照完全一致。

避坑指南：

Buffer大小限制：Quest系列设备对StructuredBuffer大小敏感，单Buffer不超过64KB。8个光源的4个Vector4数组共占用512字节，安全冗余充足。
动态光源更新：必须在ScriptableRenderFeature.Create()中注册Camera.onPreCull事件，确保每帧更新光源数据，否则会出现“灯光漂移”。
与URP阴影冲突：此方案不处理阴影，若需阴影，必须单独实现Shadow Caster Pass，成本极高，通常建议用烘焙阴影替代。

3.3 方案三：架构级规避——用Light Probe Group + Reflection Probe替代动态点光源

当项目进入后期优化阶段，且对画质一致性要求极高时，我推荐彻底放弃动态Point Light，转向基于探针的光照方案。这不是妥协，而是XR领域的最佳实践。Apple Vision Pro官方Demo、Microsoft Mesh应用均采用此架构，其核心价值在于：将光照计算从Runtime转移到Bake阶段，彻底消除GPU Runtime负担。

实施流程：

布设Light Probe Group：在场景关键区域（如设备操作台、用户站立区）放置Light Probe Group。密度原则：每0.5m³空间至少1个Probe，复杂几何体边缘加密至0.2m。使用Lighting → Generate Lighting烘焙。
添加Reflection Probe：对金属/光滑材质区域（如AR眼镜镜片、工业设备外壳），在对应位置放置Realtime Reflection Probe，设置Box Projection和Blend Distance为0.3m，确保反射精度。
材质替换：将所有使用Lit Shader的材质，切换为URP/Lit的Light Probe变体（Shader Graph中启用“Use Light Probes”）。
动态光源模拟：对于需“点亮”的交互对象（如按钮、指示灯），不使用Point Light，而用Emission属性控制。例如，按钮按下时，通过脚本修改材质_EmissionColor，值域0-5，视觉亮度等效于Point Light Range=3的效果。

原理与优势：
Light Probe Group在Bake时会采样场景中所有静态光源（包括烘焙的Point Light），生成球谐函数（Spherical Harmonics）系数，Runtime中仅需3次dot乘法即可还原间接光照，GPU耗时恒定0.02ms。Reflection Probe则提供高质量镜面反射，其CubeMap在GPU中以纹理形式缓存，访问成本极低。实测数据：某AR手术导航系统采用此方案后，GPU平均帧耗从14.2ms降至9.8ms，且光照无任何闪烁或延迟。

避坑指南：

动态物体光照：Light Probe对快速移动物体效果差。解决方案是结合Light Probe Proxy Volume（LPPV），为移动角色创建代理体积，提升插值精度。
Bake时间管理：首次Bake可能耗时数小时。建议用Progressive Lightmapper并启用Lightmap Streaming，分区块烘焙。
美术协作：必须与美术团队约定“光源即资产”原则——所有Point Light仅用于Bake，Runtime中删除。我在项目启动会上用一张对比图说服了美术总监：左边是动态Point Light在Quest 2上的噪点画面，右边是Light Probe烘焙的平滑过渡，差异一目了然。

4. 终极排查链路：从现象到根因的完整诊断手册

即使掌握了上述方案，实际开发中仍会遇到“明明按步骤做了，灯还是不亮”的情况。这时需要一套结构化排查链路，像外科医生做手术一样精准定位。我将整个过程拆解为5个递进式步骤，每个步骤包含验证工具、预期现象、失败原因及修复动作。这套链路已在12个XR项目中验证，平均定位时间从4小时缩短至22分钟。

4.1 步骤一：确认XR运行时状态与渲染管线绑定

验证工具：Unity Editor Console + XR Plugin Management Window
操作：

运行项目，打开Window → XR → XR Plugin Management
查看“Active Loaders”区域，确认目标平台（如Oculus、OpenXR）状态为“Active”
同时在Console中输入Debug.Log(GraphicsSettings.renderPipelineAsset);，确认输出非null且为你的URP Asset

预期现象：

XR Plugin Management显示绿色Active标识
Console输出类似UniversalRenderPipelineAsset (Instance ID: 12345)

失败原因与修复：

若XR Plugin Management显示“Not Active”，说明XR Subsystem未初始化。检查XR Plug-in Management → Platforms → [Your Platform] → Initialize XR on Startup是否勾选。
若Console输出null，说明URP Asset未正确分配。在Project Settings → Graphics中，将Scriptable Render Pipeline Settings指向你的URP Asset。

注意：此步骤失败率高达63%，多数人误以为是光照问题，实则是XR管线根本未加载。

4.2 步骤二：用Frame Debugger验证Forward Add Pass是否存在

验证工具：Window → Analysis → Frame Debugger
操作：

运行项目，打开Frame Debugger
展开当前帧，搜索关键词“ForwardAdd”
若无结果，再搜索“ForwardBase”，展开其Draw Call，查看Shader中是否包含_AdditionalLightsCount关键字

预期现象：

XR模式下：无“ForwardAdd”条目；“ForwardBase”Draw Call的Shader中_AdditionalLightsCount值为0
非XR模式下：存在多个“ForwardAdd”条目，且_AdditionalLightsCount>0

失败原因与修复：

若XR模式下_AdditionalLightsCount>0，说明URP Asset的“Additional Lights in Forward Base”已启用，但灯仍不亮，则问题在断点三或四。
若非XR模式下也无ForwardAdd，说明Light组件本身被禁用或层级被遮挡，检查Light的Enabled勾选框及Culling Mask设置。

4.3 步骤三：检查Shader变体编译与Instancing兼容性

验证工具：Shader Variant Collection + RenderDoc
操作：

在Project窗口中创建Shader Variant Collection（Assets → Create → Rendering → Shader Variant Collection）
将URP Lit Shader拖入Collection，勾选multi_compile_instancing和additional_light_per_vertex
Build项目，用RenderDoc抓取一帧，查看Pipeline State → Vertex Shader → Constants中UnityPerDrawBuffer内容

预期现象：

Shader Variant Collection中，multi_compile_instancing变体编译成功（无红色警告）
RenderDoc中UnityPerDrawBuffer包含unity_ObjectToWorld等Instancing专用矩阵

失败原因与修复：

若Shader Variant Collection报错“Instancing not supported”，说明Shader中缺少#pragma multi_compile_instancing。需在Shader Graph中勾选“Enable Instancing”，或在HLSL中手动添加。
若RenderDoc中UnityPerDraw为空，说明Mesh Renderer未启用GPU Instancing。在Inspector中勾选Renderer → Enable GPU Instancing。

4.4 步骤四：验证点光源数据是否正确上传至GPU

验证工具：Custom Debug Script + RenderDoc Memory View
操作：

创建调试脚本，每帧打印Light.transform.position和Light.color
在RenderDoc中，定位到自定义Pass的Draw Call，查看Constant Buffers → Buffer 0的十六进制数据
对照脚本输出，验证GPU中存储的光源位置是否与脚本一致

预期现象：

脚本输出与RenderDoc中Buffer数据完全匹配（如脚本输出[1.2, 0.5, -2.1]，Buffer中对应偏移处为3F99999A 3F000000 BEA66666）

失败原因与修复：

若数据不匹配，常见原因是CommandBuffer.SetBufferData()调用时机错误。必须在ScriptableRenderFeature.AddRenderPasses()中，于CommandBuffer.DrawMeshInstancedProcedural()之前调用。
若Buffer中全为0，说明FindObjectsOfType<Light>未找到激活光源。检查Light组件是否在Awake()中被脚本禁用，或Layer被Culling Mask排除。

4.5 步骤五：终极验证——用纯Shader输出验证光照计算

验证工具：Custom Fullscreen Shader + Unity UI
操作：

创建Fullscreen Shader，代码中直接返回_PointLightColor[0].rgb
将其应用到Canvas的RawImage上
运行XR模式，观察RawImage是否显示光源颜色

预期现象：

RawImage显示纯色（如白色表示光源Color为(1,1,1)），证明光源数据已成功传入GPU
若显示黑色，说明数据传递链路断裂；若显示正确颜色但模型仍不亮，则问题在光照计算逻辑（如法线未归一化、BRDF公式错误）

失败原因与修复：

此步骤失败率最低（<5%），一旦发生，基本可锁定为Shader数学错误。重点检查：normalize()调用、dot()参数顺序、衰减公式的分母是否为零。
我曾在一个项目中因sqrt(distSqr)未加max(distSqr, 0.0001)保护，导致距离为0时产生NaN，整个Shader输出全黑。

提示：这套排查链路的价值在于，它把模糊的“灯不亮”转化为可测量的布尔值（存在/不存在、匹配/不匹配、正确/错误）。每次排查只需5分钟，5步走完，必能找到根因。不要跳过任何一步，看似繁琐，实则省去数小时盲目试错。

5. 我踩过的坑与经验总结：那些文档里不会写的细节

写了这么多技术细节，最后想分享几个血泪教训——这些是我在交付7个商业XR项目过程中，反复踩坑后总结出的“反常识”经验。它们不写在Unity官方文档里，但能帮你少走半年弯路。

第一个坑：别信“URP版本越新越好”。去年我升级URP到14.0.0，发现所有点光源突然失效，查了三天才发现是14.0.0中Additional Lights in Forward Base的默认行为变更：它现在要求光源必须标记为LightMode = "UniversalForward"，而旧版URP自动处理。解决方案不是降级，而是在Light组件的Advanced区域，手动设置Light Layer为Default，并确保Light Mode下拉菜单中显示UniversalForward。这个细节在Release Notes里用小号字体写着，但没人会注意到。

第二个坑：Quest设备的“阴影距离”是假参数。在URP Asset中设置Shadow Distance = 100，你以为能投很远的影子，其实Quest系列GPU会强制截断为min(100, 30)。我用RenderDoc验证过，当设置超过30时，深度纹理分辨率自动从1024x1024降到512x512，画质暴跌。正确做法是：把Shadow Distance设为25，然后用Shadow Near Plane（设为0.1）和Shadow Resolution（设为High）来提升近处阴影精度。这招让我们的AR维修指导系统阴影边缘锐利度提升了3倍。

第三个坑：Light Probe的“质量”取决于烘焙时的相机位置。很多人把Probe Group布满场景就完事，结果动态物体光照忽明忽暗。真相是：Light Probe的球谐系数在Bake时，会以Main Camera的初始位置为参考原点进行采样。如果Camera起始位置在天花板，Probe会过度采样上方光源，导致地面物体光照不足。解决方案：烘焙前，把Main Camera拖到用户典型视线高度（1.6m），面向主要工作区，再点击Bake。我们医疗项目因此减少了70%的光照调试时间。

最后一点个人体会：在XR领域，光照不是“效果”，而是“交互语言”。一个按钮点亮时的柔和辉光，比任何UI文字都更能告诉用户“你可以点这里”；设备故障时的红色脉动光，比警报声更早触发用户注意。所以，当纠结于“要不要用点光源”时，先问自己：这个光是否承载了交互意图？如果是，那就值得投入方案二的Shader开发；如果只是“让场景好看”，方案三的Light Probe才是专业选择。技术服务于体验，而不是相反。

我在Quest 3上实测过，用方案二的自定义Shader实现4个点光源，配合方案三的Light Probe做环境光，整帧GPU耗时稳定在8.9ms，电池续航比纯动态光源方案延长了41%。这组数据背后，是上百小时的RenderDoc抓帧、Shader调优和真机测试。希望这些细节，能帮你避开那些我曾经深陷的泥潭。

查看全文

http://www.jsqmd.com/news/882447/