自由学习记录(101)
https://docs.unity3d.com/6000.2/Documentation/Manual/visual-effects-lens-flares.html
Unity 会自动完成图集打包,无需手动启用。条件与查看方式如下:
生成条件
-
场景中至少有一个实时光源并启用 Cast Shadows。
-
在 URP 或 HDRP 中项目的 Shadows 设置里有 Shadow Atlas Resolution(例如 1024、2048)。
-
渲染时管线会把所有需要的阴影深度图自动分块到一张 RenderTexture 中。
是否需要手动开
-
不需要。只要实时阴影开启,Shadow Atlas 就会在该帧渲染时生成。
-
你不能在 Inspector 里创建或保存它,它是 GPU 的临时渲染目标。
查看方法
-
URP:菜单 Window > Analysis > Render Doc 或 Frame Debugger。在 Frame Debugger 中展开 Draw Calls,查找 “ShadowMap” 或 “Shadow Atlas” 的 RenderTarget,即可看到这张图集。
-
HDRP:同样使用 Frame Debugger 或 RenderDoc,可以找到
Shadow Atlas
、Cached Shadow Atlas
等名字的 RenderTexture。 -
运行时你可以通过调试脚本用
RenderTexture.active
+ReadPixels
读取,但这是开发调试手段,不是正常资源导出。
Baked Shadow Angle
只在 baked 光照(光照贴图或混合光模式)下起作用,用于控制方向光(Directional Light)在生成静态阴影时阴影边缘的柔化程度。
核心要点:
-
适用对象:仅限
Light
类型为 Directional 且Mode
设为 Baked 或 Mixed 的光源。 -
单位:角度(度)。常见范围 0–10°。
-
作用:在烘焙过程中,Unity 的光照系统会模拟太阳光的“角度大小”。
-
角度越小 → 阴影边界越锐利。
-
角度越大 → 阴影边界越模糊、过渡更宽。
-
-
原理简述:相当于在光照贴图计算时,把光源视作一个有角直径的平行光盘,而不是理想的无穷远点光。角度越大,光源越“粗”,半影区扩大,烘焙出的光照贴图会生成更柔和的 penumbra。
限制与提示:
-
仅影响 光照贴图 中的阴影,不影响实时阴影。
-
较大角度会增加烘焙时间,因为需要更多采样来生成平滑过渡。
-
与 Lightmap Resolution、Indirect Lighting 等参数配合调节,以避免锯齿或噪点。
简述:Baked Shadow Angle
= 控制静态太阳光阴影“软硬度”的角度参数。
Filtering blurs the map to minimize noise. This can result in gaps in a shadow where one object meets another.
Use the five tabs at the top of the panel to view settings for the lights, 2D lights, Reflection Probes
, light probes
, and static emissive materials in the current Scene
. The editable parameters are the most commonly-used fields for each component type.
5个常见的光照贴图问题及其修复技巧
我最近编写了一份Progressive Lightmapper(渐进光照贴图器)故障排除指南,以帮助开发者在Unity编辑器中充分利用起Baked Global Illumination(烘焙全局光照)。在这里,我解析了五个最常见的光照贴图问题及其解决方案,并附有图像和 Unity 手册中页面的链接。如需完整指南, 请访问论坛。
如果某些条件不满足,渐进式光照贴图器可能无法为场景生成光照。这些条件包括但不限于:
- 对象未被标记为GI Contributor
- 场景内没有烘烤好的光照
- 着色器问题
要修复这个问题,我建议尝试下方的修复方法。
按照以下步骤将您想要光照贴图的对象标记为 GI 贡献者 :
选择你的 GameObject。
导航到 Mesh Renderer 组件。
展开 照明 标题。
选中“ 贡献全局照明” 复选框。
这样做将启用下面的 接收全局照明 参数。它包含两个选项:
- 光照贴图:适用于静态光照贴图对象 - GameObject 将接收并将 GI 贡献给光照贴图。
- 光探测器:适用于不适合光照贴图的小道具和物体 - 游戏对象将从光探测器接收 GI,并将 GI 贡献给周围的光照贴图。
5 common lightmapping problems and tips to help you fix them
Take the example of the robot shown in this section. If the metal parts of this character always reflect the sky, then it will look very strange when inside the hangar where the sky is not visible. This is where reflection probes are helpful
X“”xxxxxxxxxxxxxxx
在 URP(Universal Render Pipeline)里,“Decal” 不是一个单独的组件,而是一种需要管线支持的渲染功能。
Renderer Feature 是 URP 提供的扩展点,用来在渲染流程中插入额外的 pass。Decal 正是通过这种方式实现的。
逻辑关系
1. Renderer Data asset
Project Settings指定的 URP Asset 里,每个 Universal Renderer 都有一个 Renderer Data 。
它定义了这个 Renderer 的渲染流程,比如 Forward/Deferred、是否启用 SSAO、Decal 等。
2. Decal Renderer Feature
Unity 提供的一个内置 Renderer Feature,用于在渲染管线中添加“贴花”绘制 pass。
只有把它添加到 Renderer Data 里,URP 的渲染流程才会在适当阶段执行 Decal 的绘制。
3. Decal Projector 组件
这是场景中放置的具体物体。它引用材质并定义投射范围。
没有对应的 Renderer Feature,场景里的 Decal Projector 不会被渲染,即使组件本身存在。
所以“locate your Renderer Data asset and add the Decal Renderer Feature”指的是:在 URP 渲染管线的配置文件中启用这个渲染扩展,不是单纯添加一个组件。
xxxxxxxxxxxxxxxx
Unity 的 Component 只是“场景里的数据和行为容器”,并不保证底层渲染管线会处理它。
URP/HDRP 是模块化设计:管线先定义能力 → 组件才能生效。
Decal 的关系可以拆成三层:
1. Renderer Feature
这是渲染管线的插槽,决定是否在渲染过程中增加一个 Pass。
没有这个 Pass,再多组件也无法被 GPU 绘制。
2. Component(Decal Projector)
只保存投射范围、材质参数等数据。
自身不会触发渲染,而是等待管线在对应 Pass 里读取。
3. Script/Shader
材质和 Shader 负责实际绘制。
传统内置管线是“组件自带渲染逻辑”,所以给人感觉组件是最底层。但在 SRP(Scriptable Render Pipeline)里,
渲染能力是可选模块,组件只是前端 UI。如果管线没注册对应的 Renderer Feature,这个组件的数据就没有被消费,自然什么都看不到。
简述:SRP 先开通能力,组件只是参数提供者,所以看起来像“组件依赖渲染特性”,但这是新架构的正常设计。
是。
在 SRP 架构里,渲染管线 Asset 与 Renderer Data 是最高级配置,它们定义了整条渲染流程,组件只是被读取的数据源。
结构顺序可以这样理解:
1. RenderPipelineAsset
位于 Project Settings > Graphics。
决定整个项目在播放和编辑时使用哪条管线(URP/HDRP)。
这里设置的 URP/HDRP Asset 相当于“总入口”。
2. Renderer Data
挂在 URP Asset 里,可有多个变体(Forward Renderer、2D Renderer 等)。
这里定义:Camera stacking、Renderer Features、Shadow Atlas、后处理等。
每个 Camera 指定用哪个 Renderer Data,决定最终 Pass 顺序和特性。
3. Scene Components
Light、Decal Projector、Volume 等只是提供参数。
只有当 Data 中注册了对应 Feature,管线在渲染阶段才会读取并执行。
因此在 SRP 里“管线 → Data → 组件”的依赖是单向的:
Asset/Data 决定功能范围,组件只是填入数据。
这就是为什么启用 Decal、SSA0、Custom Pass 等必须先在 Renderer Data 里打开,再放置对应组件。
Unity 里确实有多种 “Layer” 概念,但它们分属不同系统:
1️⃣ GameObject Layer
位置:Inspector 顶部 Layer 下拉框。
用途:
Physics:碰撞矩阵(Physics Settings > Layer Collision Matrix)。
Camera Culling Mask:相机决定是否渲染某一层。
NavMesh / Raycast:射线检测过滤等。
关键点:完全是逻辑层级,和渲染管线内部无必然关系。
2️⃣ Rendering Layer
位置:Mesh Renderer > Additional Settings > Rendering Layer Mask。
用途:告诉渲染管线“哪些光/特效能影响哪些对象”。
Light Layers:某盏灯只照指定的 Rendering Layer。
Decal Layers:Decal Projector 只投射到匹配的 Layer。
Shadow Caster Filtering:同理,可让阴影只落在特定对象上。
底层:这是 SRP(URP/HDRP)定义的一个 8-bit Mask,只在渲染阶段使用,与 Physics Layer 没任何共享。
使用场景示例
需求 解决方式 说明
角色脚下的血迹贴花不能投射到墙上 给地面 Mesh 设置 Rendering Layer Ground;
Decal 只对 Ground 有效 减少 Overdraw、保持墙体干净
角色手电筒只照敌人,不照背景 敌人 Mesh 勾选 Enemies Layer;
手电 Light Layer 也选 Enemies 单独受光
分别烘焙两组 Shadow Map 灯光和物体通过不同 Rendering Layer 隔离 提高性能或特殊效果
总结
GameObject Layer:逻辑过滤(摄像机、物理、射线)。
Rendering Layer:纯渲染管线过滤(Light/Decal/Shadow 等)。
它们名字都叫 Layer,但系统完全独立,互不影响。
需要使用 Rendering Layer 的典型场景:定向光只照一部分对象、Decal/投射阴影选择性生效、优化性能。
Unity 官方文档里 on Rendering Layers(URP) 有一系列用法。整理如下:
官方介绍的 Rendering Layers 用法
-
让灯光只影响特定对象
Light 有一个 “Rendering Layers” 选项,用来指定它只影响某些 Rendering Layer。对象也要在 Mesh Renderer 的 Rendering Layer Mask 中包含这些 Layer 才能被这盏灯照到。 Unity Documentation+1 -
Decals 与 Rendering Layers 配合
如果启用了 Decal 的 Renderer Feature 的 “Use Rendering Layers”,Decal Projector 可以指定某些 Rendering Layer。只有在对象的 Rendering Layer Mask 包含这些 Layer 时,Decal 才会作用于这些对象。 Unity Documentation+1 -
Shadow Layers / Custom Shadow Layers
灯光的 “Custom Shadow Layers” 属性允许控制 阴影产生者对象(即哪些对象会投射这盏灯的阴影)与光照影响对象不同。你可以让对象被照亮,但不投这盏灯阴影,或相反。 Unity Documentation -
在项目设置里自定义这些 Rendering Layer 名称
在 Project Settings → Graphics → URP Global Settings 中可以改 Rendering Layers 的名字(比如把 Layer1 改为 “Receive Decals”、Layer2 改为 “Enemies” 等),使人更容易管理和理解。 Unity Documentation+1 -
开启 Rendering Layers 的设置
要使用这些功能,需要在 URP Asset 的设定里开启“Use Rendering Layers”。默认可能是关闭的。 Unity Documentation+1
限制 & 性能提示
-
Rendering Layers 在某些平台(例如使用 OpenGL / OpenGL ES 的)不被支持。 Unity Documentation+1
-
Layer 数量过多会显著增加渲染带宽 / 内存带宽消耗,尤其是 Decals 同时开启 Rendering Layers 的情况。 Unity Documentation+1
-
当 Rendering Layer 数量从一个倍数(比如 8)跳到下一个(比如 9)时,性能成本跳得比较明显。控制 Layer 数量在合理范围内。 Unity Documentation
Light probes inside geometry are called invalid probes. URP marks a probe as invalid when it fires sampling rays to capture surrounding light data, but the rays hit the unlit backfaces inside geometry.
官方文档可找到的“底层原理”级别
-
Light Probe(光照探针)
-
数据形式:使用 Spherical Harmonics (SH) 系数存储环境光信息。文档说明了如何从烘焙数据生成 SH 系数,以及运行时如何插值。
-
采样流程:运行时,每个需要探针光照的 Renderer,会根据其包围盒位置,在探针网格(Tetrahedralization)中查找最近的四个探针,并做加权插值。
-
Shader 交互:在 Forward/Deferred 渲染时,会把 SH 系数传入
unity_SHAr
、unity_SHAg
、unity_SHAb
等内置变量,由 GPU 在光照计算中使用。 -
参考:
-
Light Probe Introduction
-
Spherical Harmonics Details
-
-
-
Reflection Probe(反射探针)
-
数据形式:烘焙或实时捕捉的 CubeMap 贴图。
-
混合算法:运行时在相邻探针间做基于权重的球面插值,权重依据探针的包围体和衰减距离。
-
Shader 交互:通过全局变量
_ReflectionProbe
/unity_SpecCube0
等传递给 GPU。Shader 中的UNITY_SAMPLE_TEXCUBE
宏会采样这些贴图。 -
参考:
-
Reflection Probes
-
Box Projection
-
-
想进一步理解可以做的
-
Frame Debugger / RenderDoc
-
打开 Frame Debugger,查看探针数据在哪一步被上传到 GPU、何时与 Pass 绑定。
-
RenderDoc 可以分析真正的 GPU 指令和绑定的 CubeMap/SH 数据。
-
-
参考 Unity SRP (URP/HDRP) 源码
-
例如 HDRP 的
LightLoop.cs
、ProbeVolume
源码(可在com.unity.render-pipelines.high-definition
包里看到)。 -
这些是 C# 层的实现,展示了如何将探针数据打包传给 Shader 常量缓冲。
-
1️⃣ 离线阶段:Light Probe 数据的生成
-
场景烘焙:在 Editor 里点击 Generate Lighting 时,Unity 会用光线追踪(基于 CPU 或 GPU)计算每个 Probe 位置的环境光照。
-
结果存储:每个 Probe 的结果不是“贴图”,而是一组 Spherical Harmonics (SH) 系数,通常是 3 阶(9 个系数 × RGB),描述从任意方向来的间接光颜色分布。
-
存入 Lightmap 数据资产:这些系数被保存在 LightingData.asset 中,构建时会打包进游戏。
2️⃣ 运行时:物体如何找到自己的 SH
-
空间查找:游戏运行时,每个启用 “Light Probes” 的 Renderer(MeshRenderer/SkinnedMeshRenderer)会把自己的世界空间位置交给引擎。
-
四点插值:Unity 使用一个预先生成的 Tetrahedralization(四面体网格)结构,从最近的四个 Probe 中做加权插值,得到该点专属的 SH 系数。
-
结果写入 GPU 常量缓冲:引擎会把插值后的 27 个浮点值(9×RGB)写进 GPU 的全局 uniform 缓冲区,对应内置变量:
unity_SHAr, unity_SHAg, unity_SHAb // 一阶项
-
unity_SHBr, unity_SHBg, unity_SHBb // 二阶项
-
unity_SHC // 余项
3️⃣ Shader 的实时执行
-
什么时候执行:
-
Vertex/Fragment Shader 在每一帧的每个顶点/像素被光栅化时执行。
-
Shader 不会主动“查询探针”,它只是读取 Unity 传进来的全局变量。
-
-
怎样使用 SH:
-
Unity 的标准 PBR/Unlit/自定义 Surface Shader 都可以在光照计算阶段调用
ShadeSH9(float3 normal)
。 -
这个函数会用当前片元(或顶点)的世界空间法线去采样这 9 个系数,得出该方向的间接光颜色。
-
You can check which light probes are invalid using the Rendering Debugger
In the left-side scene in the image above, Virtual Offset isn’t active and dark bands are visible. In the scene on the right side, Virtual Offset is active
因此灯光探测器可能不会遵循墙壁或位于不同照明区域的边界。
Probe 的插值逻辑
-
每个启用 Light Probe 的顶点(或片元)都会在 CPU 端找到自己所在的四面体,并从其中 4 个 Probe 插值出一组 SH 系数。
-
插值完全基于空间位置,没有做“射线可见性”判断,也不考虑墙体遮挡。
2. 薄墙与泄光
-
如果墙很薄,墙内外的顶点在三维空间上距离相近,同一个外侧 Probe 会被选中参与插值。
-
即使你只有一个缺口或单面被删,靠近缺口的内表面顶点依旧可能把外部 Probe 当作邻近点。
-
结果是内部法线在
ShadeSH9
里得到外部环境的亮色,视觉上就是 light leak。
3. “部分顶点”现象
-
是的,并不是整块面都受影响。靠外的顶点或片元采到外部 Probe,靠里的顶点如果被 tetra 分割到别的四面体,可能采到不同的系数,所以泄光区域往往呈渐变。
4. 减轻方法
-
加厚墙体或做双层网格:让内部顶点与外部 Probe 物理距离拉大,插值自动选择更“内部”的四面体。
-
放置更多 Probe:在内外分区布置更密的 Probe,让 tetra 拆分更细,插值更接近真实。
-
Adaptive Probe Volumes Override:手动给体积边界,强制划分不同的光照区域,避免跨墙插值。
-
烘焙 Lightmap:关键区域直接用光照贴图代替 Probe。
结论
Light Probe 完全依赖空间距离做权重,没有视线遮挡测试。
所以任何“薄墙+外侧亮 Probe”都会导致内表面片元得到外部光照,泄光范围取决于 tetra 划分与顶点分布,而不仅是边缘缺口。
有关系。
Adaptive Probe Volume(APV)的 Options Override 会改变场景中物体采样 Probe 的“参考点”和搜索方式,而 Volume 组件就是它的作用范围。
工作链条:
-
Volume 作用域
-
Volume 定义一个空间区域。
-
进入该区域的 Renderer 会使用这里定义的 APV Options 参数,而不是全局默认值。
-
-
Options Override 内容
-
可以指定 Probe 采样的“偏移模式”(Sample Position Mode)。
-
例如从 Renderer Bounds Center、Anchor Override 或 Custom Offset 取点。
-
还可调整插值半径、权重等。
-
-
对单个物体的影响
-
物体进入 Volume 时,引擎在 CPU 端改用这些设置来找到最近的 Probe 四面体。
-
也可以在 MeshRenderer 上手动指定 Anchor Override(一个空对象位置)来进一步控制。
-
APV supports Rendering Layers, allowing you to create up to four different masks and restrict sampling to those specific masks for certain objects. This can be useful to prevent interior objects from sampling exterior probes, or vice versa. Activate and add them using Window > Rendering > Lighting > Adaptive Probe Volumes > Rendering Layers
Once the meshes are split, assign the correct Rendering Layers to them, and specify which ones APV should use in the Adaptive Probe Volume Tab
You don’t need to assign layers to every object in the tent, only to those susceptible to leaking, like the walls or objects near the walls.
When generating lighting, the system will automatically assign layers to the probes during the bake process based on the nearby objects, eliminating the need to manually assign layers per probe.
可以把句子拆成核心信息和修饰成分,逻辑就清晰:
核心动作链
-
You need to assign layers to larger objects
→ 你要给较大的物体指定 Layer。 -
To facilitate this automatic probe assignment
→ 目的:方便系统自动把 Light Probe 分到正确的 Layer。 -
Probes are assigned to the layer they encounter most frequently
→ 规则:每个 Probe 被放到与它接触最多的 Layer。
示例说明
-
在“绿洲帐篷”场景里:
-
Interior Layer 分配给帐篷的墙和顶。
-
这样大部分室内 Probe 在烘焙时会碰到这些面,于是系统自动把它们标为 Interior。
-
拆解方法:
-
句首不定式 “To facilitate …” 是整句的目的。
-
中间是示例,充当原因补充。
-
句尾是总规则。
换句话说,这段话只是在说:给大物体设置正确 Layer → 烘焙时 Probe 自动归到它最常碰到的 Layer → 方便后续按 Layer 管理光照。
Once this is done, click Generate Lighting and observe that leaking is eliminated for the tent, thanks to the separate interior and exterior masks.
APV streaming enables you to use APV-based lighting in large worlds. APV streaming bakes APV data that’s larger than the available CPU or GPU memory, and loads it at runtime when it’s needed. At runtime, as the camera moves, URP loads only APV data from cells within the camera’s view frustum
这是 Unity Rendering Debugger 窗口的左侧功能列表。它是 URP/HDRP 渲染调试工具,Unity 官方文档把这些面板称为 debug panels。每一项都可以在运行时查看或修改渲染状态,用于开发与性能调试。主要分区和官方说明大致如下:
面板 | 官方用途(简要) | 典型使用场景 |
---|---|---|
Display Stats | 显示帧率、GPU/CPU 时间、渲染线程状态等实时统计。 | 性能分析、帧率调优。 |
Frequently Used | 收集常用的调试项,便于快速切换。 | 团队自定义常看参数,快速开关。 |
Rendering | 控制渲染路径的核心选项,如是否启用后处理、透明度排序、渲染模式。 | 检查某个 Pass、禁用/启用特定效果时观察画面差异。 |
Material | 强制替换场景中所有材质为特定 Debug Shader(例如显示法线、Albedo、UV)。 | 查找丢失贴图、检查法线方向、调试材质问题。 |
Lighting | 查看或覆盖光照设置,如环境光、光照贴图、阴影。 | 诊断烘焙光照、光探针或阴影错误。 |
GPU Resident Drawer | 监控 GPU 驱动的剔除/绘制(GPU Occlusion Culling、GPU Driven Rendering)。 | 检查 GPU Instance、验证剔除效果。 |
Render Graph | 仅 HDRP:显示 Render Graph 依赖关系、Pass 执行顺序与耗时。 | 高级管线优化、了解 Render Graph 的节点结构。 |
Volume | 查看当前相机实际激活的 Volume 组件和覆盖参数。 | 调试后处理、雾效、曝光等 Volume Override 的实时影响。 |
官方文档入口
Unity Manual:
-
Rendering Debugger
-
各子面板的说明在 HDRP 或 URP 部分的 Debugging 小节中,例如 Material Overrides、Lighting Debug、Render Graph Viewer。
使用时机
-
开发期调试:验证光照贴图、阴影、后处理效果。
-
性能诊断:排查 GPU/CPU 瓶颈,查看渲染阶段。
-
美术检查:确认贴图分辨率、UV、法线方向。
简言之,这是 Unity 在编辑器和 Play 模式下的实时渲染监控与覆盖工具,并不会出现在最终玩家构建中,只在开发与测试阶段使用。
Adaptive Probe Volume (APV) Streaming
在 Unity HDRP 中,APV 是一种自动布置并插值光照探针的系统。当场景体积很大、探针数量成千上万时,烘焙生成的 SH(Spherical Harmonics)系数数据会非常庞大,直接一次性加载到内存会占用大量 GPU/CPU 资源。
APV Streaming 的作用就是分块加载和卸载这些探针数据,只在当前相机或玩家附近保留需要的探针系数。这样可以在巨型开放世界、多人在线场景等情况下节省内存和 I/O。
-
分块(Cell)烘焙
-
烘焙时,Unity 将探针网格划分成固定大小的 Cell(例如 32³ 体素)。
-
每个 Cell 生成独立的光照数据文件(通常在
LightingData
资源中)。
-
-
运行时流式加载
-
游戏运行时,HDRP 根据相机位置动态决定哪些 Cell 需要加载。
-
远离相机的 Cell 会被卸载,以降低内存占用。
-
这与 Texture Streaming 的思路类似,但对象是探针的 SH 系数。
-
-
交互细节
-
需要在 Lighting Window > Adaptive Probe Volume 面板启用 Streaming。
-
可以设置 Streaming Radius、预加载距离等参数。
-
Unity 会在后台调度磁盘到内存的异步读取。
-
典型使用场景
-
开放世界 / 大型室外地图:城市、森林、沙漠等超大空间。
-
分段式室内关卡:例如一栋巨大建筑的多个楼层,玩家只在某一层活动。
-
内存受限的平台:移动端或主机,避免一次加载全部探针数据。
官方参考
-
Unity 2022+ HDRP Manual
Adaptive Probe Volumes
文档中 “Streaming” 部分详细描述了 Cell 生成、运行时加载策略及参数。
总结
APV Streaming = “为超大场景的全局光照探针做按需加载”。
如果你的场景规模小、一次性加载数据完全可行,就无需启用;
当探针总数巨大、Lighting Data 文件动辄上百 MB 时,就应考虑开启 Streaming 来减少初始加载时间与运行时内存。
在 Unity HDRP 的语境里,Sky Occlusion 并不是一个独立“天空组件”,而是全局光照管线里的一项可选数据通道,用来描述天空光(环境光)在经过场景遮挡后的可见度。它的目的,是让环境光(天空穹顶的散射光)在到达物体时自动考虑遮挡因素,从而避免出现“洞里仍被天空直射得很亮”的不真实效果。
工作思路(简化版)
-
场景烘焙/实时计算
-
HDRP 在生成 Lighting 数据时,会为每个体素或每个探针点计算来自天空的可见比例(通常称为 sky visibility 或 ambient occlusion from sky)。
-
这个比例值在 Shader 中会作为一张贴图或一个系数传入。
-
-
着色器使用
-
材质在做全局光照(Environment Lighting)时,会把这张 Sky Occlusion 数据乘到天空反射或环境辐照度上。
-
结果是:处于洞穴、建筑内侧、悬挑下方的表面会自动变暗,看起来“天空光被遮挡”了。
-
-
实时管线结合
-
如果场景启用了 Ambient Occlusion (AO)、Adaptive Probe Volume (APV) 或 Light Probe,Sky Occlusion 的数值会与这些数据融合,达到统一的环境光衰减效果。
-
可能让你“似曾相识”的原因
-
Ambient Occlusion (AO):
局部环境光遮蔽,计算邻近几何的遮挡。Sky Occlusion是更“宏观”的同类概念,专门指向天空光。 -
Bent Normal / Indirect Occlusion:
在 PBR 里也会用一条“弯曲的法线”表示天空最可见的方向,本质目标相近。 -
Light Probe / APV:
它们的 SH 系数里同样可以储存“天空可见度”,Unity 在 HDRP 里就是把这些信息集成进 Probe 数据。
什么时候值得关注
-
室外/室内混合的大场景:比如洞穴、城市街道下的拱廊,需要环境光正确衰减。
-
高动态范围的天空照明:当天空 HDRI 很亮时,缺少 Sky Occlusion 会让阴影区域不自然地发亮。
-
使用 Adaptive Probe Volumes:Probe 烘焙时可以输出 sky visibility channel,Sky Occlusion 就是直接利用它。
官方文档入口
HDRP 手册章节:
Lighting – Sky Occlusion
其中说明了数据来源、开启位置(通常在 Lighting > Environment 或 APV 设置中)以及 Shader 中如何访问。
一句话概括
Sky Occlusion = “天空光遮挡系数”
它让环境光照更真实,是 HDRP 环境光管线中与 Ambient Occlusion 类似、但针对“天空光”专门设计的全局遮挡数据。
在 Unity 的光照体系里,Sky Occlusion 并不是一个孤立的“另一个烘焙方案”,而是基于天空光的可见度遮蔽:
它只计算来自天空的环境光/反射探针的贡献有多少会被周围几何体挡住。所以你觉得“有点像别的功能”是正常的——它确实和多种常见方案在效果层面有重叠。下面按用途拆开比较,帮助你在工作流中做取舍:
1. 概念定位
功能 | 目标 | 数据来源 |
---|---|---|
Sky Occlusion | 估计天空可见比例,减少环境光和反射强度 | 基于天空方向的光照采样 |
Ambient Occlusion (SSAO / GTAO) | 局部接触阴影与间隙遮蔽 | 屏幕空间深度 |
Reflection Probe / Light Probe | 捕获全局环境颜色、反射 | 预烘焙或实时反射 |
-
重叠感来源:Sky Occlusion 影响的是“环境光”通道,就像 Light Probe 提供环境光,但又像 AO 抑制光线。
-
不同点:它只关心天穹的可见性,而不管点光/面光等直接光。
2. 典型使用场景
-
大尺度户外:
森林、城市街区等地方,如果只靠 Reflection Probe 或 Light Probe,天空光可能太“满”;Sky Occlusion 让被山体、楼体遮蔽的区域环境光自动降低。 -
动态破坏/可破坏几何:
无需重新烘焙 Light Probe,只要遮挡关系变化,就能即时调整天空光衰减。 -
次要场景优化:
不想全场开启 SSAO,但又希望有大气感的全局阴影。
3. 与常见替代方案对比
方案 | 视觉风格 | 性能 | 维护成本 | 备注 |
---|---|---|---|---|
Sky Occlusion | 柔和、仅影响环境光 | 低 | 低 | 对天空可见度敏感 |
SSAO/GTAO | 局部细节阴影 | 中-高 | 低 | 更适合近距离缝隙 |
Light Probe Density | 全局平均 | 低 | 高(烘焙) | 需要频繁重烘焙 |
Ray-traced AO | 最真实 | 高 | 中 | 仅HDRP且硬件要求高 |
4. 实际工作流建议
-
纯室外、昼夜循环:
Sky Occlusion + Reflection Probe 是最简组合;SSAO 可按需补充近景细节。 -
半室内(洞穴入口、街巷):
Sky Occlusion 负责天空贡献;配合 Light Probe Grid 保证灯光一致。 -
高保真室内/写实项目:
仍以 SSAO/GTAO 为主;Sky Occlusion 可以不开或只在户外门口区域局部启用。
简结
Choose Sky Occlusion when you mainly need “how much of the sky is visible” to drive environment light and reflection brightness, not when you need micro-contact shadows.
如果你觉得“效果重叠”,可以把它看作是对天空环境光的动态权重:
-
需要实时、低成本地控制天空光 → 用 Sky Occlusion
-
需要细节接触阴影、近距离缝隙 → 用 SSAO/GTAO
-
需要整体色彩匹配 → 加 Light Probe / Reflection Probe
这样就能在项目中精确划分各自的角色,而不是“选一个替代另一个”。
To update the lighting data, you must also bake the APV after you enable or disable sky occlusion. Once the sky occlusion is baked, the scene lighting will respond to the ambient probe updates. In URP, the ambient probe is updated in real-time only when using the Color or Gradient Mode, not the Skybox mode. This means you’ll probably have to manually animate a color to match the animated sky visuals
A single interpolated probe is used for lighting objects: — Objects cannot transition well from darkness to light and stand out. — It can cause problems for big objects.
Each pixel is individually lit: — This ensures smooth transitions. — Volumetric effects work well using APV because the APV grid is easy to sample at any location
你的理解很接近核心,只是 Unity 里的 “GI” 这个词在概念与具体实现之间同时存在,所以才会看到既像“大方向”又像“具体开关”的用法。可以从三个层面拆开来看:
1. GI 作为渲染学概念
Global Illumination = 全局光照
-
指代所有二次光照与漫反射/反射间接光的计算,不限定算法。
-
物理层面就是:光线在场景表面多次弹射并影响其他物体的亮度和颜色。
-
这是一个学术/图形学的总称,没有特定实现。
2. Unity 的 GI 功能模块
Unity 把概念包装成一个可开关的系统,所以会有 “Lighting → Global Illumination” 的开关。
-
包含 Baked GI(烘焙光照)与 Realtime GI(实时 Enlighten)两大类。
-
当文档或界面写 “Switch GI” 或 “Enable GI” 时,指的是是否启用 Unity 的全局光照计算流程:
-
Baked:离线计算光照并存入 lightmap / light probe
-
Realtime (Enlighten):运行时动态更新光照贴图
-
所以 “Switch GI is not supported” 就是:不能在运行时切换“是否启用 Unity 的全局光照系统”。
3. Probe 在 GI 体系中的位置
Light Probe / Adaptive Probe Volumes 是 存储和插值间接光照数据的采样点,属于GI 的数据载体:
-
它们不负责计算二次光,只是存储并提供给动态物体采样。
-
Baked GI 计算完成后,把环境间接光存进 probe。运行时动态物体通过 probe 得到光照。
-
所以可以说 Probe 是 Unity GI 的子系统,但 probe 本身并不等于 GI。
4. 为什么会看到 “GI 开关”
因为 Unity 的 Lighting 窗口、Light 组件、甚至一些 Shader Keyword 中,都会出现 Enable Global Illumination
、Realtime GI
等选项,这指的是开启或关闭 Unity 的 GI 计算和数据更新,而不是指“是否存在全局光照概念”。
总结
-
GI:图形学大概念 + Unity 的整套全局光照系统。
-
Probe:GI 系统下的数据采样点,用于动态物体的间接光照。
-
面板上的 GI 开关:控制 Unity 的 GI 模块(Baked/Realtime)的启用,而不是“是否允许漫反射”这种单一效果。
因此你看到的 “Switch GI is not supported” 就是在说:不能在运行时切换 Unity GI 系统本身,但 probe 等子功能依然属于 GI 体系的一部分。
这里的 “Switch GI is not supported” 并不是在说 Light Probe 不能切换,也不是在说 你用了 Light Probe 就不能改成 APV。
它真正想表达的是 运行时不能动态切换 Unity 的 GI 计算模式。可以从几个角度理解:
1️⃣ GI 模式是项目级别的离线设置
Unity 有两大主流 全局光照 (Global Illumination) 实现:
-
Baked GI(离线烘焙:lightmap / light probe / reflection probe)
-
Realtime GI (Enlighten)(运行时更新光照贴图)
你在 Lighting Settings 里选择 Baked 还是 Realtime,或者使用 Adaptive Probe Volume (APV),本质上都是“选择一种烘焙/存储方案”。
这些数据是离线生成的,因此不能像脚本那样在游戏中“一键切换”。
2️⃣ Light Probe 与 APV 是同一大体系的两种烘焙数据结构
-
Light Probe Group:手动布点,存储 Spherical Harmonics 系数。
-
Adaptive Probe Volume:自动网格采样、可流式加载。
它们都属于 Baked GI 的数据载体。
你可以在编辑器里替换方案(比如删除 Light Probe,改用 APV,重新 Bake),但运行时不能说:当前场景一键从 Light Probe 切成 APV,因为这需要重新烘焙和重新生成数据。
3️⃣ 运行时仍可“切换光照场景”
注意文档里提到的 Lighting Scenario Asset:
“…allows for switching between different lighting, e.g., from day to night…”
这指的是在多个预烘焙数据集之间切换(白天/夜晚两套 lightmap 和 probe 数据)。
这是允许的,因为每套数据都在编辑器中预先 Bake 好,运行时只是加载不同的数据集,并没有改变 GI 算法。
总结一句话
“Switch GI is not supported” 的真正含义是:
运行时不能改变 GI 的计算方式或重新生成烘焙。
但你完全可以在项目设置阶段选择 Light Probe 或 APV,或在运行时在几套预烘焙数据之间切换。
Light Probe ≠ 被锁定,只是说不能“实时改成另一种 GI 算法”。
https://www.youtube.com/watch?v=veEu6KB-3bQ
在 Unity 的 Lighting Settings 面板里,
Realtime Global Illumination
和 Baked Global Illumination
的确可以同时勾选,这并不冲突——因为它们处理的是 两套不同的全局光照通路,而且可以混合工作。理解时可以分三层来看:
1️⃣ 两种 GI 的核心区别
Realtime GI | Baked GI | |
---|---|---|
计算方式 | 运行时实时更新光照贴图 (Enlighten) | 事先烘焙成 Lightmap / Light Probe / Reflection Probe |
用途 | 适合动态光源、会变的物体 | 适合静态场景、不可移动的物体 |
性能 | 占用 CPU/GPU 进行持续运算 | 一次离线计算,运行时几乎无成本 |
2️⃣ 可以同时开启的原因
Unity 允许把场景分成 静态区域 和 动态区域:
-
静态物体:使用 Baked GI 生成的 lightmap 或 light probe。
-
动态物体:可以从 Realtime GI 获得环境间接光照,也可以叠加烘焙数据。
例如:
-
一个城市夜景:
-
建筑物墙体使用烘焙光照(Baked GI)。
-
广告牌的动态灯光或日夜交替的天光则实时更新(Realtime GI)。
-
Unity 的 Mixed Lighting(如 Shadowmask 模式)就是这种“混合”策略的体现。
3️⃣ Lighting Settings 的角色
Lighting Settings Asset
是一个场景级的配置文件,里面保存:
-
Lightmapper 选择(CPU / Progressive GPU)
-
采样数、反弹次数、滤波方式
-
是否启用 Realtime GI、Baked GI、Shadowmask 等
它就像烘焙与实时光照的“配方”。
你按这个配方点击 Generate Lighting 时,Unity 会:
离线计算并生成 lightmap、probe 等资源(Baked GI 部分)。
记录实时 GI 的参数,运行时由 Enlighten 或 GPU 实时求解。
总结
-
可以同时开:表示场景里既支持离线光照贴图,也允许实时全局光照运算。
-
Lighting Settings:不是最终光照结果,而是指令与参数集,告诉 Unity 如何烘焙、如何在运行时计算与组合这两套光照体系。
A ray-tracing tool, such as Maya or Blender, can take the time to accurately calculate the values for each frame pixel of a reflective surface. This process takes far too long for a real time renderer, which is why shortcuts are often used.
As a dynamic object moves through the scene, it can select the nearest reflection probe and use that as the basis of its reflections. You can also set up the scene to blend between probes.
To add a Reflection Probe component, right-click the Hierarchy window and select Light > Reflection Probe
当你在一个 明亮的环境里 透过玻璃看向 几乎全黑的室内 时,确实通常会觉得玻璃更像一面“半透明的镜子”,而不是直接看见里面的黑暗。原因主要有以下几点:
1. 亮度差导致的“镜面主导”
-
玻璃本身总会反射一部分外侧的光线(普通窗玻璃的反射率大约 4–8%)。
-
当外部环境非常明亮而室内几乎没有光时,反射光的亮度远大于穿透进来的透射光。
-
结果是你眼睛接收到的主要是自己这边环境的反射,就像一面浅色的镜子。
2. 人眼适应
-
你的瞳孔和视觉系统会对外部亮度进行曝光适应。
-
因为外面更亮,眼睛会收缩瞳孔以避免过曝,从而进一步降低了你对室内微弱光线的感知。
3. 玻璃的光学特性
-
普通平板玻璃没有防反射镀膜时,会保留一层清晰的镜面反射。
-
如果是双层或夹层玻璃,反射层次更明显,尤其在夜晚的城市窗户里常见这种“镜子效应”。
换句话说:
在“外亮内暗”的条件下,你首先看到的是自己一侧的环境的反射,而不是纯黑的室内。
如果想真正看清黑暗房间,需要:
-
让房间内部有一定照明,或
-
让外部环境变暗(例如夜晚关掉室外灯),
这样透射光才能和反射光接近,玻璃才恢复“透明”的感觉。
https://gmarlowe.medium.com/the-story-behind-the-queen-song-cool-cat-4f1ba85c8122
Optimize performance for mobile, XR & web games (Unity 6 edition) | Unity
Optimize your game performance for consoles and PCs in Unity (Unity 6 edition) | Unity
Screen space lens flare Setting up lens flares for multiple lights can be time consuming. Unity 6 introduces a new post-processing technique, the Screen Space Lens Flare override (SSLF). This technique can generate flares from any bright surface, such as a bright specular highlight or an emissive mesh. In contrast, the lens flare (SRP) effect is limited to generating flares specifically from lights. Screen space lens flare uses a post-production technique.
combine SSLF with a Lens Flare (SRP) component for more control
Let’s look at the SSAO properties
— Method: This property defines the type of noise the SSAO effect uses
— Falloff Distance: SSAO does not apply to objects farther than this distance from the Camera. A lower value increases performance in scenes that contain many distant objects.
SSAO is a post-processing technique the details of which are covered later in this guide
In URP’s Decal Projector implementation there is no automatic dynamic batching of multiple decals into one draw call. Each projector is treated as an independent renderable. Here’s how it actually works:
How URP renders decals
-
Renderer Feature pass
When you add the Decal Renderer Feature to your URP Renderer Data, Unity injects an extra render pass after opaque geometry.
Every Decal Projector component that overlaps the camera’s frustum registers a draw call in that pass. -
Per-projector draw call
Each Decal Projector is essentially a cube mesh (internally a 6-sided volume) that renders a special decal shader.
Different transform, texture, or material → separate draw call.
There’s no internal “merge into one big mesh and draw once” step.
Performance implication
Ten bullet-hole decals = roughly ten draw calls in the decal pass.
That’s not catastrophic on modern hardware, but dozens or hundreds will scale linearly and can become a measurable cost—especially on mobile.
Ways to optimize
-
Atlas & Material sharing
All decals that share the same material (same shader + same texture atlas) can at least benefit from SRP Batcher.
This doesn’t collapse draw calls, but reduces state changes. -
Manual mesh decal
If you know the impact points won’t move, you can bake a single combined mesh (or dynamically merge quads) and draw it once.
This is common for bullet holes when you want hundreds of impacts. -
GPU instancing
Decal Projector itself isn’t set up for instancing, but you could build a custom instanced decal system (compute/vertex shader that projects from data buffer). -
Lifetime culling
Pool decals and limit the max count (e.g. keep only the most recent N impacts).
Summary:
URP’s built-in Decal Projector does not batch multiple bullet-hole decals into a single mesh or single pass draw. Each projector = one draw call. If you need dozens or hundreds, consider texture atlasing with shared material for SRP Batcher benefits, or implement your own instanced/mesh-based decal solution.
核心结论
• 一个 Render Pass ≠ 一个 Draw Call。同一 pass 里可以有任意数量的 draw call。
• SRP Batcher、GPU Instancing、Mesh 合并三者是不同的机制,目的和约束也不一样。
1️⃣ Pass 与 Draw Call 的关系
-
Render Pass:指一段 GPU 管线配置(shader program + fixed-function states)被执行的阶段。
-
Draw Call:CPU 提交给 GPU 的一次“画这个网格”的命令,携带当前对象的变换矩阵、材质常量等。
在“Decal Pass”中,Unity 会依次提交每一个 Decal Projector 的 draw call。
也就是说,这 10 个弹坑都跑在同一个 pass 里,但每个都是一次独立的 draw。
2️⃣ SRP Batcher 的作用
SRP Batcher 并不合并网格,也不会把所有东西塞进一个 draw。
它做的是最小化状态切换(state change):
-
只要使用相同 shader variant(同一 SubShader/Pass)和相同的 material property layout,
SRP Batcher 就能在 CPU 端把这些对象排队,一次设置 GPU 管线状态,
然后连续提交多个 draw call,而不用为每个对象重新绑定常量缓冲。 -
这样仍然是 N 个 draw call,只是 CPU→GPU 的状态切换开销小很多。
这里说的 state change 包括:
-
GPU Program 切换(不同 shader variant)
-
Render Target、Blend、Depth/Stencil、Rasterizer 等固定功能状态
-
常量缓冲 / Descriptor Set 的重新绑定
3️⃣ Mesh 合并与 GPU Instancing
方式 | 机制 | 关键特征 |
---|---|---|
Mesh Combine | 在 CPU 端把多个网格顶点合并成一个大网格,只需 1 draw call。 | 适合完全静态、共享材质的对象;每次修改顶点都要重建网格。 |
GPU Instancing | CPU 一次提交 draw,GPU 在同一管线内绘制多个实例(instance),每个实例可有自己的 transform/少量参数。 | 仍然 1 draw call,但 GPU 根据 instance ID 区分不同物体;顶点数据共享。 |
SRP Batcher | 不合并顶点,也不要求 instancing,只减少管线状态切换。 | N draw calls,但 CPU overhead 低。 |
如果你“把多个 mesh 合成一个然后一起处理”,那是 Mesh Combine 的思路。
如果你“一个网格文件 + N 个实例数据”并用UNITY_INSTANCING
绘制,那是 GPU Instancing。
SRP Batcher 和这两者是并列的优化手段,而不是同一个东西。
4️⃣ 在 Decal Projector 场景下
-
Unity 内置的 Decal Projector 没有自动 GPU instancing,也不会自动 mesh 合并。
-
你可以:
-
共享材质 → SRP Batcher 减少 state change。
-
自定义 instanced decal system → 用一份立方体/四边形网格 + instance buffer,真正 1 draw call 画所有弹坑。
-
静态烘焙 → 把长期存在的弹坑顶点合并进环境 mesh。
-
一句话总结
同一 Render Pass 可以提交多次 draw call;SRP Batcher 只优化状态切换,不合并 draw。
把多个 mesh 合成一个是 mesh combine;一网格多实例是 GPU instancing;这两者和 SRP Batcher 是不同概念。