Lightmap

墙面和灯都不动时，运行时反复追踪间接光没有必要。Lightmap把表面光照烘进专用UV，采样时复用结果。它省下积分，却把质量要求转到UV覆盖、边距、方向编码和资产重烘焙上。

静态表面光照表示

Lightmap 把静态表面的烘焙光照保存到纹理。运行时通过独立的光照 UV 采样。它常用第二套 UV 通道，具体通道编号由资产与Shader接口约定。

它适合：

静态环境的间接光和软阴影；
移动端和低端设备；
需要稳定画面且光照变化少的场景。

主要限制：

几何和灯光变化后需要重烘焙；
占用纹理内存和流送带宽；
UV2 需要不重叠、足够 Padding 和稳定 Texel Density；
动态物体不能直接使用静态表面的 Lightmap。

Directional Lightmap

非方向性 Lightmap 每个纹素保存烘焙法线下的光照量，编码可以是辐照度或已含材质项的颜色，不能由文件名判断。只有一个方向积分值时，运行时缺少随法线重新积分所需的方向信息。Directional Lightmap 会额外保存主导光方向或方向性信息，运行时根据表面法线调整结果。

例如 Unity 6000.0 的 Directional Mode 额外保存主导方向与该方向的贡献比例，运行时可据此调整法线贴图响应。两侧相反方向同时来光时，一个主导方向仍无法恢复完整分布；方向编码是压缩近似。额外纹理同时增加存储、读取和烘焙成本。

运行时查询

以下HLSL机制片段约定纹理为线性浮点RGB辐照度，已包含间接可见性，未乘材质反照率，因而读取无需额外HDR解码。宿主提供 Texture2D<float4> Lightmap、线性采样器和当前物体的 scaleBias；采用RGBM等编码时，必须替换为该格式的解码函数。

hlsl

float2 uv = lightmapUV * scaleBias.xy + scaleBias.zw;
float3 irradiance = Lightmap.Sample(LinearClamp, uv).rgb;
float3 diffuse = baseColor * irradiance / 3.14159265;

若数据已保存漫反射出射颜色，就不能重复乘反照率或除π。方向性Lightmap另保存方向约束，用于法线响应。

烘焙边界与失效

光照 UV 的每个图表对应一块表面。图表边缘需向外扩张有效颜色，否则双线性和 mip 采样会混入邻图表。基础层留 $p$ 个纹素，缩到第 $m$ 级后只剩约 $p/2^m$ 个；允许访问的最粗 mip、压缩块大小和扩张方式应一起确定，具体隔离策略见纹理图集。

一个图表在2048图集中占256纹素宽，UV尺度是0.125；其左边缘在512处时偏移是0.25。运行时仍需区分内容区域与保护边，不能直接把包含边距的外框当成有效UV范围。

烘焙清单至少记录几何变换、材质反照率、自发光、参与的光源、UV和光照编码。修改任一影响积分的输入都会使对应结果失效。烘焙若已包含直接光，运行时再叠同一盏直接光会双算；混合光照需明确哪些贡献由贴图、实时灯和阴影遮罩分别负责。

光照贡献的归属

假设某表面的间接辐照度为2，直接辐照度为3，反照率0.5。贴图只保存间接项时，运行时分别得到0.5*2/π和0.5*3/π，合计2.5/π。若贴图保存总辐照度5，却仍叠加同一盏直接灯3，结果变成4/π。错误来自贡献重复，并非UV或纹理格式。

非方向贴图把各入射方向积分成一个数；两个相反方向等强来光可以得到相同总值，却在法线转向时产生不同变化。主导方向编码只保存压缩后的方向约束，需要依照特定引擎的解码公式求响应，不能从一个RGB值唯一还原原始光场。

验证方法

显示UV2与图集索引，检查重叠、Padding、纹素密度和最低mip。移动灯光或几何时标记烘焙失效，与未变化的参考场景比较接缝与能量。

本页按明确的辐照度格式核对了UV地址和Lambert单位关系，引用的Unity方向格式已核读。实际场景烘焙、压缩误差、资源流送与目标引擎运行尚未验证。

参考资料

Unity 6000.0：Store light direction with Directional Mode，双纹理语义与运行成本。