Unity Shader纹理跨管线实战：URP与Built-in通用优化

做跨管线项目的时候，我遇到过一件非常典型的事：同一个 Shader，在 Built-in 管线里效果正常，切到 URP 之后，主纹理颜色整体发灰、法线方向也反了，折腾了半天才发现问题根本不是出在 Shader 逻辑上，而是纹理声明方式、采样宏和颜色空间处理在两条管线里根本不一样。这也是我写这篇 Unity Shader 纹理总结的起因——很多人以为纹理采样就是一句 tex2D 的事，但真正把它放到 URP / Built-in 通用的场景里，里面值得梳理的细节远超想象。

这篇文章会把纹理从导入设置、采样声明、常见用法到性能优化完整串一遍。无论你是刚接触 Shader 的新手，还是被 SRP Batcher 和平台压缩格式困扰的进阶开发者，应该都能从中找到可以直接抄走的方案。

1. 先说清楚纹理在 Shader 里到底扮演什么角色

1.1 从 UV 到采样：一段最短的"纹理工作链路"

Shader 里使用纹理，本质上是一条极其紧凑的数据链路：顶点着色器把顶点的 UV 坐标传给片元着色器，片元着色器拿着 UV 去纹理对象里查询对应的颜色值，再经过各种计算输出到屏幕。这个查询过程专业上叫采样（Sampling），而在 Unity 里，采样对象并不仅仅是颜色贴图，法线贴图、遮罩贴图、高度图、噪声图、环境贴图，本质上都是同一套机制。

新手最容易困惑的是 UV 和纹理像素的关系。一张 1024×1024 的贴图，横纵方向各有 1024 个像素，但 UV 坐标永远是从 0 到 1 的归一化范围。（0.5， 0.5） 就对应贴图正中心那个纹素（Texel），不管纹理本身是 256 还是 4096。这意味着写 Shader 的时候，所有 UV 运算都可以不关心具体像素尺寸，Tiling、Offset、扭曲、滚动都是在 0~1 的抽象空间里做的，最后才由硬件决定取到哪个纹素。

关于采样，我最想强调的一点是：GPU 采样纹理不是简单的"读一个点"，而是"读取周围一片区域再做混合计算"。这个特性决定了后面所有过滤模式和 Mipmap 的设计逻辑。比如双线性过滤会取相邻 2×2 纹素做加权平均，三线性过滤会在两层 Mipmap 之间再做一次混合。这些机制在确保纹理缩放时画面平滑的同时，也在消耗更多的纹理带宽和计算指令。所以，纹理采样在 Shader 里的成本从来都是双重维度：采样次数 × 每次采样读取的数据量。

1.2 过滤器、Mipmap 和各向异性：决定纹理画质的三个旋钮

在 Unity 里，纹理的 Filter Mode 决定了 GPU 把 UV 换算成纹素时怎么取点。Point（点采样）直接选择最近的纹素，适合像素风、UI 精确显示这类场景；Bilinear（双线性）取周围四个纹素做平均，是最通用的折中选择；Trilinear（三线性）在 Bilinear 的基础上还会跨 Mipmap 层采样做混合，能明显减少远景时纹理闪烁。实际项目里，我一般把 UI 纹理设 Point 或 Bilinear，角色和场景贴图全用 Trilinear，性能差异并不大，但画面平滑度好很多。

Mipmap 是另一个经常被忽略的旋钮。开 Mipmap 之后，Unity 会从原图生成一系列逐级缩小一半的副本，当物体距离摄像机很远、UV 覆盖区域很小时，GPU 就会直接采样较小的层级，既避免了摩尔纹闪烁，又减少了访问大纹理产生的带宽压力。代价是额外的显存占用。比如一张 1024×1024 的 RGBA32 纹理，原图 4MB，带完整 Mipmap 链之后约为 5.33MB，多了三分之一。如果你的纹理总是全屏显示、不会缩放或者只在小范围固定使用，关掉 Mipmap 能省下不少显存。

各向异性过滤（Aniso Level）是给斜视角观察地面、墙面这类场景准备的。默认设置下，双线性过滤在各方向上是均匀的，但当你从很低的角度看一块地板纹理时，透视会让纹理在屏幕空间里"横宽竖窄"，均匀过滤就会让远处部分变得很模糊。各向异性过滤通过沿视线方向增加额外采样来缓解这种模糊。OpenGL 系列平台上这个功能开销不小，移动端我一般控制在 4x 到 8x，PC 端直接 16x 问题不大。

1.3 线性与 sRGB：为什么同一张贴图在两个管线里颜色不一样

颜色空间是"URP / Built-in 通用"话题里最先坑人的地方。Built-in 管线的默认工程可能是 Gamma 空间，而 URP 模板工程几乎是强制线性空间起步。线性空间渲染更符合物理规律，光照衰减更真实，但代价是纹理采样时颜色必须经过一次转换。

关键在于，美术在 Photoshop 里画的贴图是以 sRGB 编码保存的，这种编码本身是 Gamma 2.2 的。如果直接把这种贴图放线性空间工程里采样，就会出现颜色发灰、提亮过度的现象。Unity 的解法是在纹理导入面板里把 Color Space 标成 sRGB，运行时采样时会自动把 sRGB 转成线性值，颜色计算都在线性空间完成后，输出到屏幕前再转回 sRGB。

这套逻辑在 Built-in 和 URP 里是通用的，所以纹理导入时 sRGB 开关不能乱勾。颜色贴图、遮罩贴图一般勾 sRGB；而法线贴图、金属粗糙度这类数据贴图必须取消 sRGB 勾选，否则采样出来的数据会被二次换算，法线方向错误、金属度异常是必然结果。这里有个很容易忽略的点：遮罩纹理里的 R、G、B、A 通道如果存的是 0~1 的权重数据，不是颜色，从严谨角度也应该关闭 sRGB，否则权重值会被 2.2 幂次扭曲，混合权重和美术预期会出现肉眼可辨的偏差。

2. URP 与 Built-in 的纹理代码：一份 Shader 通吃的工程化方案

2.1 属性与 CBUFFER：SRP Batcher 时代的纹理声明变化

在 Built-in 管线里写纹理，最常见的写法是拿 sampler2D _MainTex; 直接声明，再配合 float4 _MainTex_ST; 存 Tiling/Offset。这套写法在 URP 里其实还能编译运行，但它有一个致命问题：无法进入 URP 的 SRP Batcher 加速路径。

URP 的 SRP Batcher 会把材质属性统一放入名为 UnityPerMaterial 的常量缓冲区，使得不同材质只要 Shader 一致就能合并渲染状态，从而大幅减少 CPU 侧的绘制调用开销。如果你的 Shader 仍然用零散声明的 float4 _MainTex_ST，它会被识别为传统路径，材质属性无法合并进同一个 CBUFFER，最终只能走常规的按材质切换状态流程。

要做到兼容，属性声明就必须从"松散的变量"变成"CBUFFER 内成员"。URP 标准写法是这样的：

hlsl复制CBUFFER_START(UnityPerMaterial)
    float4 _MainTex_ST;
    float4 _MainTex_TexelSize;
    half  _Smoothness;
    half  _Metallic;
CBUFFER_END

TEXTURE2D(_MainTex);
SAMPLER(sampler_MainTex);

注意 TEXTURE2D 和 SAMPLER 只是宏，它们在 URP 的 Shader Library 里被解析为 Texture2D 和 SamplerState，在 Built-in 的 CGPROGRAM 环境里也能被解释成对应的老类型。真正需要留神的是：整个 Shader 如果用了 HLSLPROGRAM，那么在 URP 环境需要 include 对应的 URP 核心库，而在 Built-in 环境需要 include UnityCG.cginc。靠预处理宏可以同时兼容两者：

hlsl复制#if defined(SHADER_API_GLES3) || defined(SHADER_API_METAL) || defined(SHADER_API_D3D11)
    // 所有现代平台都走这里
#endif

实际操作中，更稳妥的办法是做一个公共的 TextureCommon.hlsl 文件，把纹理声明、常用函数放进去，然后 URP 和 Built-in 各自的 Shader 文件分别 include 自己依赖的核心库，再 include 公共文件。这样既能享受 URP 的批处理优化，又不会破坏 Built-in 的兼容性。

2.2 采样器怎么写才两头不吃亏：从 tex2D 到 SAMPLE_TEXTURE2D

tex2D 是 Built-in CG 时代流传下来的采样函数。它在 URP 的兼容层里依然能工作，但 URP 官方推荐的写法是 SAMPLE_TEXTURE2D 宏。这个宏在不同平台上有不同的优化实现：在 D3D11 上它会展开为 _MainTex.Sample(sampler_MainTex, uv)，在 GLES2 等老平台会退回到类似 tex2D 的实现。正因为这个宏做到了平台级的差异处理，你要写 URP / Built-in 通用 Shader，就应该尽量统一使用这套宏族。

实际的通用采样流程可以这样写：

hlsl复制half4 fragmentShader(Varyings input) : SV_Target
{
    float2 uv = TRANSFORM_TEX(input.texcoord, _MainTex);
    half4 color = SAMPLE_TEXTURE2D(_MainTex, sampler_MainTex, uv);
    return color;
}

手动 Shader 里我建议的兼容策略是，在公共库中定义一层自己的包装：

hlsl复制#ifdef _USE_SAMPLE_TEX
    #define SAMPLE_TEX(tex, sampler, uv) SAMPLE_TEXTURE2D(tex, sampler, uv)
#else
    #define SAMPLE_TEX(tex, sampler, uv) tex2D(tex, uv)
#endif

为什么要这样绕一圈？因为当你在 Built-in 管线里也使用 HLSLPROGRAM 时，URP 的采样宏可能因为 include 顺序问题无法解析。所以最稳的通用方案不是二选一，而是可切换。实际项目里，大部分情况下 UV 动画、主纹理采样、法线采样这些逻辑完全相同，切换点只集中在声明和宏转换层，做一层抽象就能让业务 Shader 完全复用。

2.3 坐标翻转和宏差异：最容易踩的平台坑

纹理坐标翻转是 Unity 跨平台开发里最经典的历史遗留问题。D3D11 平台上纹理 V 坐标默认从上方开始（UV 原点在左上角），而 OpenGL 平台 V 坐标从下方开始（原点在左下角）。对常规采样来说，Unity 在导入纹理时已经做了统一的预处理，你在 Shader 里拿到的不太会出现上下颠倒。但当你直接操作 RenderTexture 或者读取屏幕缓冲时，情况就不一样了。

Unity 为此提供了 UNITY_UV_STARTS_AT_TOP 宏，通常配合 #pragma target 和平台类型判断使用。例如在写后处理或抓屏效果时，翻转逻辑一般写成：

hlsl复制#if UNITY_UV_STARTS_AT_TOP
    if (_MainTex_TexelSize.y < 0)
        uv.y = 1 - uv.y;
#endif

很多时候你会看到 _MainTex_TexelSize 的 y 分量在 D3D 平台是负数，原因就在这——Unity 用这个符号标记屏幕纹理是否需要翻转。这条经验平时用不到，但一用到 RenderTexture 和 Blit 流程时，不理解它你会被"上下颠倒"折磨一整天。

另一个通用陷阱与平台相关的宏差异就是 SHADER_API_* 系列。URP 推荐用 SHADER_API_MOBILE 来区分移动端平台，而不是自己去枚举 Android 和 iOS，因为这样可以覆盖 Console、Switch 等我也经常容易漏掉的平台。如果 Shader 里确实需要移动端降精度、换采样器策略，用这个宏才是稳妥做法。

3. 纹理导入设置：效果和性能往往在 Project Settings 里定生死

3.1 sRGB 开关与双线性环境：Gamma 和 Linear 的换算关系

线性空间渲染的整个纹理链路，可以简化为三步：纹理里的 sRGB 编码值在采样前被转为线性值，各种光照和混合计算在线性空间完成，最终输出时再做一次 sRGB 编码。由于中间涉及的幂运算不是线性的，任何一个环节漏掉转换，结果正确率都会大打折扣。

在 Unity 导入设置里，你会发现纹理的 sRGB (Color Texture) 开关默认是勾上的。颜色贴图保持勾选，数据类贴图取消勾选，这是最基础的一条原则。但这里有一个容易被忽视的细节：如果项目处于 Gamma 空间，纹理上的 sRGB 开关不会造成"额外"转换，因为整个管线都约定在 Gamma 空间直接计算。可一旦切换到线性空间，这张贴图的处理路径就从"直接采样"变成"采样前先线性化"。有时两个管线颜色不同，不是 Shader 写错了，而是同一张贴图在 Gamma 工程和 Linear 工程里采样后的数值本身就不同。

如果你需要彻底摸清这个问题，可以在帧调试器里打开单步查看中间颜色值，或者在 Shader 里临时加一个后处理输出原始采样值对比。实操中我会在工程切 Render Pipeline 后，第一时间检查主贴图、法线贴图、金属度贴图的 sRGB 开关状态，这是最快排除"整体变灰"问题的手段。

3.2 压缩格式怎么选：ASTC、BC7、ETC2 的实际数据对比

纹理压缩格式直接决定显存占用、加载时间和画质。Unity 里常用压缩格式对应的纹理大小如下表：

选择格式时我在项目里总结了一套经验。PC / 主机优先用 BC7，画质和压缩比俱佳；Android 和 iOS 统一 ASTC，但块大小要按纹理用途分开——角色和UI用 4×4 或 6×6，大场景的地形和植被用 8×8 甚至 10×10。纯 Android 且需要兼容老设备时，ETC2 是安全底线。需要特别注意的是：建筑类贴图、带精细字体和细线的 UI 切图，压缩格式不当会出现严重色块和边缘糊化，这种纹理宁可用 RGBA32 或 ASTC 4×4，也别为了省 100KB 而牺牲观感。

法线贴图的压缩和颜色贴图完全不同。BC5（RG 双通道压缩）和 ASTC HDR 变体能更好地保留法线方向精度，DXT5 之类把 Alpha 也用来存储信息的方式则容易产生法线抖动。如果项目里法线贴图出现边缘锯齿状闪烁，优先怀疑压缩格式，而不是 Shader 计算。

3.3 Mipmap 与各向异性：什么时候该开，什么时候必须关

Mipmap 开关在场景纹理和 UI 纹理上是两种完全相反的选择。场景中的大尺寸贴图，只要可能被缩放到很小，就应该开 Mipmap，避免远景闪烁和带宽浪费。而 UI 纹理通常在固定分辨率下展示，缩放极少，开了 Mipmap 反而让纹理内存直接增加 1/3，而且永远不会被采样到。2D 游戏的图集、UI 图集，全关 Mipmap 是标准做法。

Aniso Level 不是越高越好。移动端开启各向异性过滤会让显卡每帧多做大量采样计算，尤其在高密度地形纹理上发热明显。合理做法是只在主贴图和质量设置里设置 4x 或 8x，并且通过 Graphic Settings 的纹理质量开关可以根据不同档位动态调整。PC 端 16x 对性能影响很小，但 OpenGL 环境下有些老显卡驱动对这项设置处理并不完善，出现异常模糊时先把它降到 8x 试试。

4. 实用采样套路：从单张 MainTex 到多纹理组合

4.1 TRANSFORM_TEX 的标准姿势：Tiling、Offset 和坐标系细节

材质上的 Tiling 和 Offset 之所以能影响 Shader 里的采样，靠的是 _MainTex_ST 这个内置的 float4 变量。它的 xy 分量对应 Tiling，zw 分量对应 Offset。标准采样写法是：

hlsl复制float2 uv = v.uv * _MainTex_ST.xy + _MainTex_ST.zw;

Unity 封装了 TRANSFORM_TEX(uv, _MainTex) 宏来做这件事，但宏在 URP 和 Built-in 里的解析是一样的，可以直接用。我见过不少人手动写的时候把 Offset 和 Tiling 顺序搞反，结果材质面板怎么调都不对。记住 uv * Tiling + Offset 这个顺序，基本不会错。

坐标细节方面，另一个细节是纹理平铺模式的配合。如果你用了大于 1 的 Tiling，纹理的 Wrap Mode 需要设为 Repeat，否则 UV 在超出 0~1 范围后会采样到边缘固定值，画面会出现拉伸或发黑。地面、墙面这类连续纹理场景里，Wrap Mode 设为 Repeat 是最基础的操作。

4.2 法线贴图与 UnpackNormal：使用前的解码逻辑

法线贴图存放的不是普通颜色，而是各个纹素的法线扰动方向，所以采样之后不能直接当 RGB 用，必须先解码。Unity 的 UnpackNormal 专门处理这件事。在 DXT5nm 和 BC5 等压缩格式下，法线贴图只存两个有效通道（RG），UnpackNormal 会把蓝色通道从压缩数据里重建出来，从而恢复完整的法线向量。

hlsl复制half3 normal = UnpackNormal(SAMPLE_TEXTURE2D(_BumpMap, sampler_BumpMap, uv));

移动端使用时要格外注意：重建出来的法线向量在低精度计算下可能失去单位长度，所以很多 Shader 会在 UnpackNormal 之后主动做一次 normalize。如果项目用了 _BumpScale 控制法线强度，UnpackNormalWithScale 会更方便：

hlsl复制half3 normal = UnpackNormalWithScale(
    SAMPLE_TEXTURE2D(_BumpMap, sampler_BumpMap, uv), 
    _BumpScale
);

法线贴图的 RG 通道在压缩后精度损失比较大，这也是我前面强调法线贴图优先选高精度压缩格式的原因。实践中如果法线贴图出现远处闪烁、边缘锯齿，多半就是压缩精度不足或者 UnpackNormal 使用方式有问题。

4.3 遮罩纹理组合技：一张图的四个通道控制四种效果

纹理组合使用时，遮罩贴图是最实用的一种思路。它不用来显示颜色，而是把每个通道当作一个 0~1 的开关或权重，控制混合、粗糙度、金属度、环境光遮蔽等多个效果。比如地形渲染时，用一张四通道遮罩图，R 通道控制草地混合权重，G 通道控制岩石混合权重，B 通道控制沙地权重，A 通道调制 AO 强度，就能用一张贴图完全驱动材质表现：

hlsl复制half4 mask = SAMPLE_TEXTURE2D(_MaskMap, sampler_MaskMap, uv);

half3 grassColor = SAMPLE_TEXTURE2D(_GrassTex, sampler_MainTex, uv).rgb;
half3 rockColor  = SAMPLE_TEXTURE2D(_RockTex, sampler_MainTex, uv).rgb;
half3 blend = grassColor * mask.r + rockColor * mask.g;

遮罩贴图最需要注意的是导入时的 sRGB 开关。很多美术习惯把遮罩图当作"颜色"保存，但实际上它是数据权重，如果开着 sRGB，混合权重被幂次化，层与层的过渡区域会出现不自然的生硬感。我个人建议统一为 Linear 无 sRGB 的导入方式，并让美术按这个规范来出图。

4.4 UV 序列帧与滚动动画：纹理动画的正确实现

纹理动画在日常 Shader 里主要分两类。UV 滚动常用于水流、传送门、激光这类效果，原理很简单：往 UV 的某个分量上加上随时间变化的值：

hlsl复制float2 scrollUV = input.uv + float2(_ScrollSpeedX, _ScrollSpeedY) * _Time.y;
half4 texColor = SAMPLE_TEXTURE2D(_MainTex, sampler_MainTex, scrollUV);

序列帧动画则是另一套思路。美术会把多帧画面排列在一张大图里，Shader 通过 UV 偏移和缩放来取其中一帧。确认帧率 _FPS 和行列数 _Row、_Column 后，可以按当前时间算出帧号，再把帧号换算成 UV 偏移：

hlsl复制float totalFrames = _Row * _Column;
float frame = fmod(floor(_Time.y * _FPS), totalFrames);

float rowIndex = floor(frame / _Column);
float colIndex = fmod(frame, _Column);

float2 uv = input.uv / float2(_Column, _Row);
uv.x += colIndex / _Column;
uv.y += (1 - rowIndex - 1) / _Row;  // 根据帧排布方式调整

这里最容易踩的坑是帧的排列顺序。不同美术出的图可能是从左到右、从上到下，也可能从下到上，写 Shader 前先约定好排布顺序，并留出 UV 偏移的可调节参数，否则做出来的特效在换图后会彻底乱掉。

5. 纹理优化和三个高频 Bug：从理论到实战排查

5.1 纹理占用怎么算：一个公式摸清显存和带宽

纹理优化的第一步是学会估算占用。显存占用公式很简单：宽度 × 高度 × 每像素字节数，再乘以 Mipmap 系数（开 Mipmap 约 1.33，不开为 1.0）。例如一张 2048×2048 的 BC7 纹理，不开 Mipmap 是 2048×2048×1.44Byte ≈ 4MB，开 Mipmap 约 5.33MB。如果打成图集，12 张 2048×2048 的贴图合成一张 8192×8192 的图集，显存占用往往能低到原来的三分之一到五分之一。

带宽消耗比显存更容易被忽视。每次 GPU 采样纹理都要从显存读取数据，不同采样次数累积下来，带宽很快会成为渲染瓶颈。比如在一帧里对 4K 材质做了 8 次采样，GPU 需要搬移几十 MB 的数据，对移动端来说这直接反映为发热和帧率下降。优化思路有四种：减少采样次数、降低单次采样数据量（用更狠的压缩格式）、缩小纹理尺寸、尽量复用 Mipmap 层级低的区域。

5.2 图集与 Texture2DArray：解决切换开销与采样器上限

纹理切换是渲染状态切换的一种。切换纹理时 GPU 需要重新配置纹理单元，虽然现代 GPU 相比过去好转了很多，但数量级上来之后仍然是开销。解决方案有两种主流路线。

图集（Atlas）是把多张小图合成一张大图，一次采样就能覆盖多种不同的画面区域，适合 UI、2D 角色。它的代价是 UV 需要从原来的独立坐标映射到图集内的子区域，并且图集边缘可能出现颜色渗漏，所以图集填充时需要留 padding 边距，Shader 采样时要适当压缩 UV 到安全区域。

Texture2DArray 则更进阶。它把多张同尺寸的纹理合成一个数组，采样时需要额外传入数组索引：

hlsl复制float4 color = SAMPLE_TEXTURE2D_ARRAY(_TexArray, sampler_TexArray, float3(uv, _SliceIndex));

Texture2DArray 最大的好处是采样时不会出现图集那样的边缘渗色问题，适合地形多材质混合、植被多样性等场景。缺点是所有纹理要求尺寸一致，而且对 GPU 硬件有基础要求，老设备支持不算好。Unity 的地形系统其实一直在底层使用类似的机制来混合多层贴图。

采样器数量是移动端一个硬性指标。GLES3.0 大部分设备支持 16 个片元采样器，但某些低端机可能只有 8 个。Shader 里采样器超限的报错信息往往非常隐蔽，有时只是画面变得全黑或者采样异常。排查方法也很笨拙：逐个注释掉采样贴图代码，找到让 Shader 突然正常的那个采样器，再想合并方案。

5.3 三个高频问题的排查链路：黑边、偏色、模糊

最后分享三个我在项目中反复遇到的纹理相关问题，每个都附上完整排查链路，希望你能少走弯路。

第一个是半透明物体纹理边缘出现黑边。出现黑边时，先检查 Wrap Mode 是不是 Clamp，如果是 Repeat，边缘的采样值会溢出到贴图另一侧甚至采样失败。然后检查图集是否有 padding，最后再确认是否在 Premultiply Alpha 与 Straight Alpha 之间选错混合模式。流程走到这一步，绝大多数黑边问题都能定位。

第二个是贴图在 URP 下整体偏暗发灰。先查工程是否处于 Linear 空间，再查贴图 sRGB 开关是否异常。如果是法线贴图，取消 sRGB 开关后发灰基本消失。如果情况只在移动端出现，还要考虑压缩格式是否选了过低的 ASTC 块，比如法线贴图用 ASTC 8×8 时，会出现明显的色带和方向抖动。把块大小调整到 4×4 往往立竿见影。

第三个是远处纹理闪烁或模糊。优先开启 Mipmap，然后把 Filter Mode 从 Bilinear 调到 Trilinear，最后考虑适度提高各向异性过滤等级。如果开启 Mipmap 后出现接缝或边界生硬，检查相邻材质是否使用了不同的 Mip 偏值，例如 _MipBias 这类参数在雪地、灰尘材质上很容易造成衔接处亮度不连续。

我在跨管线项目里最深的体会是：纹理问题绝大多数不是 Shader 代码的"语法错误"，而是导入设置、平台格式、SRP 特性这几个容易被忽略的环节在互相影响。每次改动纹理相关参数之后，在真机上用帧调试器对比一帧的中间渲染结果，比盯着 Inspector 面板猜要高效得多。这篇基于实际踩坑经验的纹理总结，希望能让你在 URP / Built-in 双管线混用的路上，少做几次"颜色怎么又变了"的无用功。