1. 为什么普通贴图做不出真实光照做Unity渲染的人迟早会在某个下午盯着一个半成品场景发愁明明贴图分辨率够高、模型没毛病、光照方向也对但渲染结果就是“塑料感”十足——高光发灰、暗部死黑、Bloom效果怎么调都像一层廉价雾。这时候如果有人提醒你一句“你试试把贴图换成HDR的”很多问题会瞬间解决。先解释一下HDR贴图是什么。HDR全称High Dynamic Range高动态范围。普通贴图LDR每个颜色通道只能存0到1之间的数值超过1就被截断。而HDR贴图允许颜色值超出1比如3、10、甚至几百。放在真实世界里很好理解一张白纸的亮度是1一盏台灯的亮度可能是100正午阳光下的白墙可能到1000。LDR贴图等于拿0到1的刻度去量整个世界HDR贴图则给了一个没有上限的刻度尺。在Unity的URPUniversal Render Pipeline通用渲染管线环境里HDR贴图的应用比很多人想象中更广泛。环境反射探针需要HDR Cubemap来提供高光反射信息天空盒必须是HDR格式才能让太阳区域产生真实的Bloom效果自发光材质需要HDR贴图才能作为发光源参与后期辉光计算甚至光照贴图烘焙出来也是HDR的只不过默认被压缩回了LDR。如果全程只用LDR贴图整个光照链路从源头就缺了一环后面所有效果都是将就。这篇文章不是来讲“什么是HDR”这种入门概念的。重点放在URP管线里HDR贴图从导入、声明、采样到实际应用的全链路实操包括哪些地方必须用、哪些地方别乱用、以及移动端和PC端的坑。适合已经会用Unity基础光照、想进一步把画面质感做上去的开发者。看完你至少能回答三个问题为什么我的自发光不亮为什么反射探针装了Cubemap还是灰蒙蒙为什么同一套美术资源在不同项目里表现差这么多2. URP里[HDR]标签和纹理格式的底层逻辑2.1 [HDR]标签到底干了什么在Unity的Shader代码里声明一张贴图属性的标准写法是_MainTex (Main Texture, 2D) white {}这行代码声明了一张普通2D贴图。如果改成这样_EmissionMap (Emission Map, 2D) white {}和第一行没本质区别。真正的关键差异在这[HDR] _EmissionMap (Emission Map, 2D) white {}多了[HDR]三个字符Unity的材质面板会做两件事。第一材质球上这张贴图的选择器旁边会出现一个HDR标识提醒美术同学这张图应该用HDR资源。第二更关键的是当Unity内部处理这个材质属性时它知道这张贴图需要按HDR方式解码采样结果不会被强制压缩到0到1的范围。这个属性标签背后对应的是ShaderLab的属性类型修饰符。类似的还有[Gamma]、[Linear]、[Normal]等但[HDR]在光照链路里的地位特殊。它直接决定了你在材质面板上拖进去的EXR、HDR格式贴图能不能被正确解释。如果没有这个标签就算你硬塞一张高动态范围的贴图进去管线也有可能把它当普通纹理处理超高亮区域的值会被削平。2.2 sRGB和线性颜色空间的纠缠很多人搞混的一件事HDR贴图不是“更亮的贴图”而是“不做sRGB解码的线性数据贴图”。平时美术在PS里导出的JPG、PNG是sRGB颜色空间编码的数值和亮度之间不是线性关系是gamma曲线关系。GPU在采样这种贴图时需要先把sRGB值解码成线性值再做光照计算最后输出时再编码回去这就是管线里的sRGB Sample Flag。这套流程对普通颜色贴图完全正确。但HDR贴图不同。HDR贴图存的是物理亮度数据不是人眼看到的颜色编码。它生成的时候就是从线性空间直接导出的。如果在采样时错误地给它套了sRGB解码数值会被提亮整个反射、自发光、环境光照都会偏色偏亮而且这种偏差没法通过调灯光补偿因为它作用在每个像素上。Unity处理这件事的方式是声明为[HDR]的贴图Shader在采样时会使用DecodeHDR函数而不是普通的tex2D。URP的ShaderLibrary里内置了完整的HDR解码逻辑会根据纹理格式自动判断是否需要解码、如何解码。这也是为什么URP项目里强烈建议使用URP提供的采样宏和函数而不是手写裸的tex2D——手动采样很容易绕过这些内置的颜色管理。2.3 纹理格式与平台兼容性HDR贴图在硬盘上是EXR、HDRRadiance、或TIFF格式但导入Unity后要转换成引擎能实时采样的GPU格式。常用的HDR纹理格式有这么几类格式位深内存开销平台支持适用场景RGBAHalf16位/通道中全平台绝大多数HDR贴图RGBAFloat32位/通道高PC和部分移动端要求极高精度时RGB9E5共享指数低大部分平台环境贴图BC6H硬件压缩低PC、新主机高质量的HDR压缩格式ASTC HDR硬件压缩低移动端主流移动端HDR纹理标准方案关键在于不是所有格式在所有平台上都支持。BC6H在移动端基本不可用ASTC HDR在部分老芯片上没有硬件解码。RGBAFloat在移动端的内存开销高到让人肉疼。所以URP工程在做HDR贴图时Realtime实时和Baked烘焙的策略经常得分开处理。还有一档隐藏问题纹理导入设置里的sRGB选项。对HDR贴图来说如果你的纹理是颜色贴图用途sRGB可以勾上让硬件做解码但如果是数据贴图用途比如当作粗糙度、AO、金属度的输入则必须关闭sRGB。而HDR格式的贴图本身通常建议关闭sRGB选项因为数据是在线性空间生成的不该二次编码。3. 实操HDR贴图从制作到Shader采样的完整链路3.1 在DCC工具里导出HDR贴图先从制作端说起。很多美术第一次接触HDR贴图时直接拿JPG改名为HDR——这是完全错误的。HDR贴图必须真正包含超过1的浮点数据普通的8位JPG、PNG根本没有这个能力因为它们每个通道只有8位数值上限255对应到0到1之间。导出HDR贴图的常规路径有这几条在PS里用“另存为”选Radiance格式.hdr或导出OpenEXR.exr这两个格式都支持浮点数据。Substance Painter/Designer导出贴图时输出设置里选择EXR格式色彩空间选Linearbit depth选32位或16位浮点。3D软件里渲染环境反射探针时直接输出HDR环境贴图光照信息本身就是超范围的。程序化生成用代码生成HDR图比如写一个C#脚本把超过1的数值写进RenderTexture再保存为EXR。实操里最常见的坑是PS里做了一张看起来“很亮”的自发光贴图导出PNG后数值全是255也就是1.0在引擎里怎么调Emission强度都突破不了1。这个1.0就是LDR的上限。正确的做法是导出EXR在PS里把发光区域的实际像素值调成5、10甚至更高导出后在引擎里才能获得真正的物理高光。3.2 Unity导入设置的推荐方案把EXR拖进Unity后默认导入设置可能不一定适合。按照经验要检查这几个选项Texture Type如果用作环境贴图选Environment如果用作普通材质贴图选Default。sRGB (Color Texture)HDR贴图一般建议关掉因为数据是线性的。如果发现导入后变亮了一截多半是这里的问题。Compression环境贴图可以选High Quality压缩材质贴图看用途。BC6H格式在PC上优先选择移动端选ASTC HDR。Generate Mip Maps一般开除非贴图是UI或特殊用途。但注意HDR贴图的mipmap生成过程和LDR不同引擎会用浮点滤波而不是简单的平均。Max Size根据实际使用场景定。环境贴图经常用256或512就够自发光贴图看UV密度的需求。一个容易被忽略的点HDR贴图的mipmap在远处会明显变暗。因为mipmap是降采样浮点数据的平均值在降采样时是数学平均值但人眼对亮部的敏感度不是线性的。如果发现远处自发光物体发暗生成方式可以改成“Blur”模式URO里会对HDR数据做适当的光照衰减处理近似的修复办法是给Emission强度适当补偿。3.3 Shader里写一个带HDR采样的自发光效果直接给一段可以在URP里用的自定义Shader代码。这个Shader做的事是采样一张HDR贴图作为自发光输入再加上一个强度系数最后输出到Bloom能拾取的范围。Shader Custom/HDRUnlit { Properties { [HDR] _EmissionMap (HDR Emission Map, 2D) black {} _EmissionIntensity (Emission Intensity, Float) 1.0 } SubShader { Tags { RenderPipeline UniversalPipeline Queue Transparent RenderType Transparent } Pass { HLSLPROGRAM #pragma vertex vert #pragma fragment frag #include Packages/com.unity.render-pipelines.universal/ShaderLibrary/Core.hlsl #include Packages/com.unity.render-pipelines.universal/ShaderLibrary/Lighting.hlsl struct Attributes { float4 positionOS : POSITION; float2 uv : TEXCOORD0; }; struct Varyings { float4 positionHCS : SV_POSITION; float2 uv : TEXCOORD0; }; TEXTURE2D(_EmissionMap); SAMPLER(sampler_EmissionMap); float _EmissionIntensity; Varyings vert (Attributes IN) { Varyings OUT; OUT.positionHCS TransformObjectToHClip(IN.positionOS.xyz); OUT.uv IN.uv; return OUT; } half4 frag (Varyings IN) : SV_Target { half4 col SAMPLE_TEXTURE2D(_EmissionMap, sampler_EmissionMap, IN.uv) * _EmissionIntensity; return col; } ENDHLSL } } }这段代码里最核心的是Properties里的[HDR]标记以及在Hlsl里用TEXTURE2D和SAMPLE_TEXTURE2D的方式采样。URP里SAMPLE_TEXTURE2D这个宏会根据平台和纹理格式自动选择采样路径对HDR纹理来说会在需要的时候走浮点采样不会像tex2D那样有隐式的LDR流程。实际使用的时候我通常会把_EmissionIntensity默认值设成1在材质面板上让美术直接调整。数值超过1没关系Bloom后处理拾取亮度大于某个阈值的区域时自然会把亮部的自发光区域识别出来。3.4 验证HDR贴图是否真的生效一个简单的验证方法在Scene视图下选中材质球把自发光强度拉到10看Bloom的高光区域会不会比强度1更亮。如果会说明HDR通路正常工作。如果不会可能的原因有贴图不是真正的HDR格式重新导出EXR确认像素数值超过1材质面板上的贴图被当成LDR处理确认Shader声明里有没有[HDR]Bloom后处理的Threshold设得过高导致所有亮部都被滤掉了HDR贴图在导入时被转成了LDR格式去纹理导入设置里检查Compression和格式确保不是RGBA或RGB24这种方法百试百灵。4. URP光照管线里HDR贴图的三大实战应用4.1 环境反射反射探针和CubemapURP里做环境反射有两套常用方案——实时反射探针和烘焙Cubemap。无论哪套如果探针里放的是LDR贴图反射出来的高光永远是“灰白色”的缺少真实环境应有的亮度和色彩层次。反射探针需要的HDR Cubemap怎么来常规做法是在场景里摆一个反射探针勾选“Type”里的Baked然后导入一张HDRI环境贴图比如从素材库下载的.exr文件让它作为整个环境的反射源。URP里还可以设置反射探针的“重要性”和“混合距离”但底层逻辑都一样探针内部保存的是HDR数据着色器采样后与金属度、光滑度做BRDF运算输出镜面反射。这里有个和LDR对比很明显的例子站在一个金属球前面LDR环境贴图给出来的反射金属球的高光区域永远是一个接近白色的圆点周围是灰糊糊的一片。换成HDR环境贴图之后反射里能看到太阳的轮廓、天空蓝色区域和地面暗部之间的真实亮度差金属质感一下子出来。实操注意点Cubemap的HDR数据量很大6个面加起来比普通贴图大不少。PC上还好在移动端如果场景里放了好几个反射探针内存开销会相当惊人。一种做法是降低Cubemap分辨率反射探针只负责大致环境颜色细节用屏幕空间反射URP里没直接用需要外挂或自定义Pass弥补。4.2 自发光配合BloomURP的Bloom后处理有一个Threshold参数只有亮度超过这个阈值的区域才会产生辉光。如果用普通LDR贴图做自发光最大亮度就是1.0Threshold也得设成1.0以下一旦Threshold等于1整个画面都会被Bloom淹没因为任何自发光物体边缘的柔和过渡都会触发阈值。实际项目中更合理的做法自发光贴图用HDR把发光区域的核心像素值设成5甚至10Threshold设为0.8。这样只有HDR贴图里超过0.8的区域会参与Bloom计算其余明亮但不过曝的部分不会被连带辉光。效果上自发光物体是“自己发光”的状态而不是“被加了柔光滤镜”。验证这套方案的典型Demo一个室内场景几盏灯管、几个指示灯灯管的自发光贴图用HDR导出的EXR发光强度控制在3到8之间周围墙壁用普通LDR材质亮度最高1。开BloomThreshold 0.8Intensity 1.2。视觉上灯管有真实的泛光包裹墙壁不会一起泛光。这个效果用LDR贴图很难调出来因为非发光pH值的贴图也容易把像素推到接近1出现大范围污染。4.3 光照贴图烘焙里的HDR数据很多开发者不知道的是Lightmapper烘焙光照贴图时内部处理就是HDR浮点数据。Unity的CPU LightmapperProgressive GPU Lightmapper也一样计算的辐照度是浮点值然后输出到光照贴图时根据项目设置压缩成LDR格式或保留HDR。烘焙光照贴图默认输出LDR导致的常见问题室内场景中窗户外的太阳光打进来窗框边缘的高光会过曝成一团白色丢失细节。这就是典型的LDR光照贴图的截断问题——超过1都白信息全丢。解决办法是在Lighting窗口里把Lightmap Encoding改成“High Quality”HDR配合方向性光照模式使用。URP里光照贴图编码的设置和内存呈明显正相关HDR光照贴图的内存可以是LDR的两到三倍而且mipmap的开销也高。但因为它保留了非饱和的高光信息间接光的层次感、色彩浓度都提升明显特别是阳光充沛的室内场景视觉回报非常值。5. 常见坑和性能选型5.1 贴图乱了同一张贴图既当颜色又当HDR这类问题在美术团队协作时特别常见。一张贴图在设计上既要用作颜色贴图又想让部分区域产生自发光。结果就是颜色贴图要求sRGB解码自发光区域要求超过1的数值两种需求在一张贴图里打架。解法是拆图。颜色贴图保留LDR的sRGB编码发光区域单独拆成一张HDR遮罩贴图Mask两个Shader属性分开控制。这样颜色通道不影响发光通道亮度修正也不会破坏颜色编码。拆图看似增加了一张贴图的开销实际在可维护性上省下的时间多得多。5.2 性能HDR不贵但别乱搞直接给经验数据RGBAHalf的4K贴图大约32MBRGBAFloat大约64MB。BC6H压缩之后会比这个低很多。一个场景里放十几张4K RGBAHalf贴图内存压力立刻上去更不用说移动端。项目实践中推荐这样分配环境反射Cubemap生成mipmap后256或512分辨率足够格式优先ASTC HDR或BC6H。自发光贴图优先压缩格式分辨率按贴图密度来512或1024。烘焙光照贴图HDR编码只在光照复杂度高的场景开简单光照用LDR就够。程序化生成的HDR纹理RenderTexture只在需要时保留用完释放这个很容易被漏掉。5.3 平台差异移动端HDR的真实性能表现移动端GPU的浮点纹理支持情况差距很大。ASTC HDR虽然标准上支持但在部分旧芯片上解码速度很慢。BC6H在移动端基本不可用。RGBAHalf勉强全平台能跑但开销在那儿摆着。实测下来单纯采样HDR贴图做自发光在主流手机上性能影响很小因为像素着色器采样次数没变。真正坑的是环境反射的HDR Cubemap采样反射探针在金属、光滑表面上每像素可能采样多次Cubemap这时候HDR格式的解码开销就会被放大。规避手段是限制探针数量、降低Cubemap分辨率、或者用预滤波的Specular Cubemap。如果项目目标平台是低端移动设备一个务实的选择是烘焙好的环境反射Cubemap压缩成LDR格式亮度牺牲一点但换来的是采样的稳定帧率。自发光和Bloom的HDR数据没法割舍那就保留ETC2或ASTC压缩的HDR格式把分辨率降到需求下限。5.4 常见问题速查表把平时被问得最多的问题整理成一张表方便直接查现象可能原因排查顺序自发光怎么调都不亮贴图不是真HDR先看原文件像素值是否超过1材质面板上能设强度但画面不变Shader采样路径绕过了HDR解码确认用了SAMPLE_TEXTURE2D宏Bloom糊成一片Threshold太低先抬Threshold到0.8以上反射灰蒙蒙的反射探针里放的是LDR Cubemap换成EXR格式的环境贴图远处自发光变暗HDR贴图mipmap降采样导致调整导入设置的Mipmap滤波方式移动端掉帧严重多个HDR Cubemap同时采样降分辨率、限制探针数量HDR贴图导入后偏亮sRGB选项勾上了关掉sRGB选项重新导入导出EXR后Unity里颜色不对DCC工具的色彩空间设置错了确认导出时是Linear空间6. 我个人在实际项目里的几点体会HDR贴图这事从原理到实操翻来覆去就那些东西但它对口渲染结果的质感影响说实话比单纯调灯光的收益大得多。我刚接触URP那段时间场景里所有贴图都是LDR做出来的画面怎么说呢——干净但是“假”特别是玻璃、金属这类靠反射活着的材质怎么调都差口气。后来把环境贴图换成HDR的EXR再配合自发光HDR贴图和Bloom那一下的视觉提升非常明显。实际操作中有两个小习惯我一直保留第一场景里所有可能发光的材质在Shader声明上提前把[HDR]写上去哪怕当前用的贴图是LDR的。因为美术后面换资源时如果Shader不支持HDR换上去的EXR会被吞掉亮度排查起来头大。第二验证HDR是否生效时习惯在场景里放一个金属球、一个纯黑的有色物体快速扫一眼反射和环境色是否层次分明。这个方法比盯着参数猜快得多。如果项目还在前期建议直接定一套HDR资产规范什么场景用EXR、什么场景用压缩格式、自发光贴图的强度范围是多少、环境贴图分辨率该给多大。这些提前定好美术和程序之间的无效沟通会少一半。HDR贴图本身不是一个多复杂的主题但把它放进一整条光照链路里去安排效果就是完全不同层面的东西了。
1. 为什么普通贴图做不出真实光照做Unity渲染的人迟早会在某个下午盯着一个半成品场景发愁明明贴图分辨率够高、模型没毛病、光照方向也对但渲染结果就是“塑料感”十足——高光发灰、暗部死黑、Bloom效果怎么调都像一层廉价雾。这时候如果有人提醒你一句“你试试把贴图换成HDR的”很多问题会瞬间解决。先解释一下HDR贴图是什么。HDR全称High Dynamic Range高动态范围。普通贴图LDR每个颜色通道只能存0到1之间的数值超过1就被截断。而HDR贴图允许颜色值超出1比如3、10、甚至几百。放在真实世界里很好理解一张白纸的亮度是1一盏台灯的亮度可能是100正午阳光下的白墙可能到1000。LDR贴图等于拿0到1的刻度去量整个世界HDR贴图则给了一个没有上限的刻度尺。在Unity的URPUniversal Render Pipeline通用渲染管线环境里HDR贴图的应用比很多人想象中更广泛。环境反射探针需要HDR Cubemap来提供高光反射信息天空盒必须是HDR格式才能让太阳区域产生真实的Bloom效果自发光材质需要HDR贴图才能作为发光源参与后期辉光计算甚至光照贴图烘焙出来也是HDR的只不过默认被压缩回了LDR。如果全程只用LDR贴图整个光照链路从源头就缺了一环后面所有效果都是将就。这篇文章不是来讲“什么是HDR”这种入门概念的。重点放在URP管线里HDR贴图从导入、声明、采样到实际应用的全链路实操包括哪些地方必须用、哪些地方别乱用、以及移动端和PC端的坑。适合已经会用Unity基础光照、想进一步把画面质感做上去的开发者。看完你至少能回答三个问题为什么我的自发光不亮为什么反射探针装了Cubemap还是灰蒙蒙为什么同一套美术资源在不同项目里表现差这么多2. URP里[HDR]标签和纹理格式的底层逻辑2.1 [HDR]标签到底干了什么在Unity的Shader代码里声明一张贴图属性的标准写法是_MainTex (Main Texture, 2D) white {}这行代码声明了一张普通2D贴图。如果改成这样_EmissionMap (Emission Map, 2D) white {}和第一行没本质区别。真正的关键差异在这[HDR] _EmissionMap (Emission Map, 2D) white {}多了[HDR]三个字符Unity的材质面板会做两件事。第一材质球上这张贴图的选择器旁边会出现一个HDR标识提醒美术同学这张图应该用HDR资源。第二更关键的是当Unity内部处理这个材质属性时它知道这张贴图需要按HDR方式解码采样结果不会被强制压缩到0到1的范围。这个属性标签背后对应的是ShaderLab的属性类型修饰符。类似的还有[Gamma]、[Linear]、[Normal]等但[HDR]在光照链路里的地位特殊。它直接决定了你在材质面板上拖进去的EXR、HDR格式贴图能不能被正确解释。如果没有这个标签就算你硬塞一张高动态范围的贴图进去管线也有可能把它当普通纹理处理超高亮区域的值会被削平。2.2 sRGB和线性颜色空间的纠缠很多人搞混的一件事HDR贴图不是“更亮的贴图”而是“不做sRGB解码的线性数据贴图”。平时美术在PS里导出的JPG、PNG是sRGB颜色空间编码的数值和亮度之间不是线性关系是gamma曲线关系。GPU在采样这种贴图时需要先把sRGB值解码成线性值再做光照计算最后输出时再编码回去这就是管线里的sRGB Sample Flag。这套流程对普通颜色贴图完全正确。但HDR贴图不同。HDR贴图存的是物理亮度数据不是人眼看到的颜色编码。它生成的时候就是从线性空间直接导出的。如果在采样时错误地给它套了sRGB解码数值会被提亮整个反射、自发光、环境光照都会偏色偏亮而且这种偏差没法通过调灯光补偿因为它作用在每个像素上。Unity处理这件事的方式是声明为[HDR]的贴图Shader在采样时会使用DecodeHDR函数而不是普通的tex2D。URP的ShaderLibrary里内置了完整的HDR解码逻辑会根据纹理格式自动判断是否需要解码、如何解码。这也是为什么URP项目里强烈建议使用URP提供的采样宏和函数而不是手写裸的tex2D——手动采样很容易绕过这些内置的颜色管理。2.3 纹理格式与平台兼容性HDR贴图在硬盘上是EXR、HDRRadiance、或TIFF格式但导入Unity后要转换成引擎能实时采样的GPU格式。常用的HDR纹理格式有这么几类格式位深内存开销平台支持适用场景RGBAHalf16位/通道中全平台绝大多数HDR贴图RGBAFloat32位/通道高PC和部分移动端要求极高精度时RGB9E5共享指数低大部分平台环境贴图BC6H硬件压缩低PC、新主机高质量的HDR压缩格式ASTC HDR硬件压缩低移动端主流移动端HDR纹理标准方案关键在于不是所有格式在所有平台上都支持。BC6H在移动端基本不可用ASTC HDR在部分老芯片上没有硬件解码。RGBAFloat在移动端的内存开销高到让人肉疼。所以URP工程在做HDR贴图时Realtime实时和Baked烘焙的策略经常得分开处理。还有一档隐藏问题纹理导入设置里的sRGB选项。对HDR贴图来说如果你的纹理是颜色贴图用途sRGB可以勾上让硬件做解码但如果是数据贴图用途比如当作粗糙度、AO、金属度的输入则必须关闭sRGB。而HDR格式的贴图本身通常建议关闭sRGB选项因为数据是在线性空间生成的不该二次编码。3. 实操HDR贴图从制作到Shader采样的完整链路3.1 在DCC工具里导出HDR贴图先从制作端说起。很多美术第一次接触HDR贴图时直接拿JPG改名为HDR——这是完全错误的。HDR贴图必须真正包含超过1的浮点数据普通的8位JPG、PNG根本没有这个能力因为它们每个通道只有8位数值上限255对应到0到1之间。导出HDR贴图的常规路径有这几条在PS里用“另存为”选Radiance格式.hdr或导出OpenEXR.exr这两个格式都支持浮点数据。Substance Painter/Designer导出贴图时输出设置里选择EXR格式色彩空间选Linearbit depth选32位或16位浮点。3D软件里渲染环境反射探针时直接输出HDR环境贴图光照信息本身就是超范围的。程序化生成用代码生成HDR图比如写一个C#脚本把超过1的数值写进RenderTexture再保存为EXR。实操里最常见的坑是PS里做了一张看起来“很亮”的自发光贴图导出PNG后数值全是255也就是1.0在引擎里怎么调Emission强度都突破不了1。这个1.0就是LDR的上限。正确的做法是导出EXR在PS里把发光区域的实际像素值调成5、10甚至更高导出后在引擎里才能获得真正的物理高光。3.2 Unity导入设置的推荐方案把EXR拖进Unity后默认导入设置可能不一定适合。按照经验要检查这几个选项Texture Type如果用作环境贴图选Environment如果用作普通材质贴图选Default。sRGB (Color Texture)HDR贴图一般建议关掉因为数据是线性的。如果发现导入后变亮了一截多半是这里的问题。Compression环境贴图可以选High Quality压缩材质贴图看用途。BC6H格式在PC上优先选择移动端选ASTC HDR。Generate Mip Maps一般开除非贴图是UI或特殊用途。但注意HDR贴图的mipmap生成过程和LDR不同引擎会用浮点滤波而不是简单的平均。Max Size根据实际使用场景定。环境贴图经常用256或512就够自发光贴图看UV密度的需求。一个容易被忽略的点HDR贴图的mipmap在远处会明显变暗。因为mipmap是降采样浮点数据的平均值在降采样时是数学平均值但人眼对亮部的敏感度不是线性的。如果发现远处自发光物体发暗生成方式可以改成“Blur”模式URO里会对HDR数据做适当的光照衰减处理近似的修复办法是给Emission强度适当补偿。3.3 Shader里写一个带HDR采样的自发光效果直接给一段可以在URP里用的自定义Shader代码。这个Shader做的事是采样一张HDR贴图作为自发光输入再加上一个强度系数最后输出到Bloom能拾取的范围。Shader Custom/HDRUnlit { Properties { [HDR] _EmissionMap (HDR Emission Map, 2D) black {} _EmissionIntensity (Emission Intensity, Float) 1.0 } SubShader { Tags { RenderPipeline UniversalPipeline Queue Transparent RenderType Transparent } Pass { HLSLPROGRAM #pragma vertex vert #pragma fragment frag #include Packages/com.unity.render-pipelines.universal/ShaderLibrary/Core.hlsl #include Packages/com.unity.render-pipelines.universal/ShaderLibrary/Lighting.hlsl struct Attributes { float4 positionOS : POSITION; float2 uv : TEXCOORD0; }; struct Varyings { float4 positionHCS : SV_POSITION; float2 uv : TEXCOORD0; }; TEXTURE2D(_EmissionMap); SAMPLER(sampler_EmissionMap); float _EmissionIntensity; Varyings vert (Attributes IN) { Varyings OUT; OUT.positionHCS TransformObjectToHClip(IN.positionOS.xyz); OUT.uv IN.uv; return OUT; } half4 frag (Varyings IN) : SV_Target { half4 col SAMPLE_TEXTURE2D(_EmissionMap, sampler_EmissionMap, IN.uv) * _EmissionIntensity; return col; } ENDHLSL } } }这段代码里最核心的是Properties里的[HDR]标记以及在Hlsl里用TEXTURE2D和SAMPLE_TEXTURE2D的方式采样。URP里SAMPLE_TEXTURE2D这个宏会根据平台和纹理格式自动选择采样路径对HDR纹理来说会在需要的时候走浮点采样不会像tex2D那样有隐式的LDR流程。实际使用的时候我通常会把_EmissionIntensity默认值设成1在材质面板上让美术直接调整。数值超过1没关系Bloom后处理拾取亮度大于某个阈值的区域时自然会把亮部的自发光区域识别出来。3.4 验证HDR贴图是否真的生效一个简单的验证方法在Scene视图下选中材质球把自发光强度拉到10看Bloom的高光区域会不会比强度1更亮。如果会说明HDR通路正常工作。如果不会可能的原因有贴图不是真正的HDR格式重新导出EXR确认像素数值超过1材质面板上的贴图被当成LDR处理确认Shader声明里有没有[HDR]Bloom后处理的Threshold设得过高导致所有亮部都被滤掉了HDR贴图在导入时被转成了LDR格式去纹理导入设置里检查Compression和格式确保不是RGBA或RGB24这种方法百试百灵。4. URP光照管线里HDR贴图的三大实战应用4.1 环境反射反射探针和CubemapURP里做环境反射有两套常用方案——实时反射探针和烘焙Cubemap。无论哪套如果探针里放的是LDR贴图反射出来的高光永远是“灰白色”的缺少真实环境应有的亮度和色彩层次。反射探针需要的HDR Cubemap怎么来常规做法是在场景里摆一个反射探针勾选“Type”里的Baked然后导入一张HDRI环境贴图比如从素材库下载的.exr文件让它作为整个环境的反射源。URP里还可以设置反射探针的“重要性”和“混合距离”但底层逻辑都一样探针内部保存的是HDR数据着色器采样后与金属度、光滑度做BRDF运算输出镜面反射。这里有个和LDR对比很明显的例子站在一个金属球前面LDR环境贴图给出来的反射金属球的高光区域永远是一个接近白色的圆点周围是灰糊糊的一片。换成HDR环境贴图之后反射里能看到太阳的轮廓、天空蓝色区域和地面暗部之间的真实亮度差金属质感一下子出来。实操注意点Cubemap的HDR数据量很大6个面加起来比普通贴图大不少。PC上还好在移动端如果场景里放了好几个反射探针内存开销会相当惊人。一种做法是降低Cubemap分辨率反射探针只负责大致环境颜色细节用屏幕空间反射URP里没直接用需要外挂或自定义Pass弥补。4.2 自发光配合BloomURP的Bloom后处理有一个Threshold参数只有亮度超过这个阈值的区域才会产生辉光。如果用普通LDR贴图做自发光最大亮度就是1.0Threshold也得设成1.0以下一旦Threshold等于1整个画面都会被Bloom淹没因为任何自发光物体边缘的柔和过渡都会触发阈值。实际项目中更合理的做法自发光贴图用HDR把发光区域的核心像素值设成5甚至10Threshold设为0.8。这样只有HDR贴图里超过0.8的区域会参与Bloom计算其余明亮但不过曝的部分不会被连带辉光。效果上自发光物体是“自己发光”的状态而不是“被加了柔光滤镜”。验证这套方案的典型Demo一个室内场景几盏灯管、几个指示灯灯管的自发光贴图用HDR导出的EXR发光强度控制在3到8之间周围墙壁用普通LDR材质亮度最高1。开BloomThreshold 0.8Intensity 1.2。视觉上灯管有真实的泛光包裹墙壁不会一起泛光。这个效果用LDR贴图很难调出来因为非发光pH值的贴图也容易把像素推到接近1出现大范围污染。4.3 光照贴图烘焙里的HDR数据很多开发者不知道的是Lightmapper烘焙光照贴图时内部处理就是HDR浮点数据。Unity的CPU LightmapperProgressive GPU Lightmapper也一样计算的辐照度是浮点值然后输出到光照贴图时根据项目设置压缩成LDR格式或保留HDR。烘焙光照贴图默认输出LDR导致的常见问题室内场景中窗户外的太阳光打进来窗框边缘的高光会过曝成一团白色丢失细节。这就是典型的LDR光照贴图的截断问题——超过1都白信息全丢。解决办法是在Lighting窗口里把Lightmap Encoding改成“High Quality”HDR配合方向性光照模式使用。URP里光照贴图编码的设置和内存呈明显正相关HDR光照贴图的内存可以是LDR的两到三倍而且mipmap的开销也高。但因为它保留了非饱和的高光信息间接光的层次感、色彩浓度都提升明显特别是阳光充沛的室内场景视觉回报非常值。5. 常见坑和性能选型5.1 贴图乱了同一张贴图既当颜色又当HDR这类问题在美术团队协作时特别常见。一张贴图在设计上既要用作颜色贴图又想让部分区域产生自发光。结果就是颜色贴图要求sRGB解码自发光区域要求超过1的数值两种需求在一张贴图里打架。解法是拆图。颜色贴图保留LDR的sRGB编码发光区域单独拆成一张HDR遮罩贴图Mask两个Shader属性分开控制。这样颜色通道不影响发光通道亮度修正也不会破坏颜色编码。拆图看似增加了一张贴图的开销实际在可维护性上省下的时间多得多。5.2 性能HDR不贵但别乱搞直接给经验数据RGBAHalf的4K贴图大约32MBRGBAFloat大约64MB。BC6H压缩之后会比这个低很多。一个场景里放十几张4K RGBAHalf贴图内存压力立刻上去更不用说移动端。项目实践中推荐这样分配环境反射Cubemap生成mipmap后256或512分辨率足够格式优先ASTC HDR或BC6H。自发光贴图优先压缩格式分辨率按贴图密度来512或1024。烘焙光照贴图HDR编码只在光照复杂度高的场景开简单光照用LDR就够。程序化生成的HDR纹理RenderTexture只在需要时保留用完释放这个很容易被漏掉。5.3 平台差异移动端HDR的真实性能表现移动端GPU的浮点纹理支持情况差距很大。ASTC HDR虽然标准上支持但在部分旧芯片上解码速度很慢。BC6H在移动端基本不可用。RGBAHalf勉强全平台能跑但开销在那儿摆着。实测下来单纯采样HDR贴图做自发光在主流手机上性能影响很小因为像素着色器采样次数没变。真正坑的是环境反射的HDR Cubemap采样反射探针在金属、光滑表面上每像素可能采样多次Cubemap这时候HDR格式的解码开销就会被放大。规避手段是限制探针数量、降低Cubemap分辨率、或者用预滤波的Specular Cubemap。如果项目目标平台是低端移动设备一个务实的选择是烘焙好的环境反射Cubemap压缩成LDR格式亮度牺牲一点但换来的是采样的稳定帧率。自发光和Bloom的HDR数据没法割舍那就保留ETC2或ASTC压缩的HDR格式把分辨率降到需求下限。5.4 常见问题速查表把平时被问得最多的问题整理成一张表方便直接查现象可能原因排查顺序自发光怎么调都不亮贴图不是真HDR先看原文件像素值是否超过1材质面板上能设强度但画面不变Shader采样路径绕过了HDR解码确认用了SAMPLE_TEXTURE2D宏Bloom糊成一片Threshold太低先抬Threshold到0.8以上反射灰蒙蒙的反射探针里放的是LDR Cubemap换成EXR格式的环境贴图远处自发光变暗HDR贴图mipmap降采样导致调整导入设置的Mipmap滤波方式移动端掉帧严重多个HDR Cubemap同时采样降分辨率、限制探针数量HDR贴图导入后偏亮sRGB选项勾上了关掉sRGB选项重新导入导出EXR后Unity里颜色不对DCC工具的色彩空间设置错了确认导出时是Linear空间6. 我个人在实际项目里的几点体会HDR贴图这事从原理到实操翻来覆去就那些东西但它对口渲染结果的质感影响说实话比单纯调灯光的收益大得多。我刚接触URP那段时间场景里所有贴图都是LDR做出来的画面怎么说呢——干净但是“假”特别是玻璃、金属这类靠反射活着的材质怎么调都差口气。后来把环境贴图换成HDR的EXR再配合自发光HDR贴图和Bloom那一下的视觉提升非常明显。实际操作中有两个小习惯我一直保留第一场景里所有可能发光的材质在Shader声明上提前把[HDR]写上去哪怕当前用的贴图是LDR的。因为美术后面换资源时如果Shader不支持HDR换上去的EXR会被吞掉亮度排查起来头大。第二验证HDR是否生效时习惯在场景里放一个金属球、一个纯黑的有色物体快速扫一眼反射和环境色是否层次分明。这个方法比盯着参数猜快得多。如果项目还在前期建议直接定一套HDR资产规范什么场景用EXR、什么场景用压缩格式、自发光贴图的强度范围是多少、环境贴图分辨率该给多大。这些提前定好美术和程序之间的无效沟通会少一半。HDR贴图本身不是一个多复杂的主题但把它放进一整条光照链路里去安排效果就是完全不同层面的东西了。
解法)
