纹理分辨率的选择看似只是一个美术资源参数，实际上却牵动着显存占用、带宽消耗和着色器采样效率。一张 2048×2048 的 RGBA8 纹理，仅基础数据就需要 16MB 显存，如果开启 Mipmap，还将额外增加约三分之一的存储量。当场景中同时存在数百张这样的纹理时，平台内存压力和渲染性能会迅速恶化。
要做出合理的纹理分辨率决策，不能只凭视觉感受，而是需要从内存计算、平台差异、屏幕空间覆盖率和资产预算四个维度进行系统分析。本文会先解释纹理尺寸与硬件资源之间的量化关系，再结合不同平台的约束给出可落地的选择方法。
一、纹理分辨率如何影响内存与渲染带宽
纹理分辨率通常以宽高像素表示，例如 1024×1024、2048×2048。分辨率直接决定纹理在 GPU 内存中的基础大小。以未压缩的 RGBA8 格式为例，每个像素占用 4 字节，计算公式为：宽度 × 高度 × 通道数 × 每通道字节数。2048×2048 的基础大小为 2048 × 2048 × 4 × 1 = 16,777,216 字节，即 16MB。如果启用完整 Mipmap 链，存储总量约为基础大小的 1.33 倍，因为每一级 Mipmap 的尺寸都是上一级的一半，总面积收敛为 4/3。
下面这段代码用于快速估算纹理的内存占用：
def texture_memory(width, height, channels=4, bits_per_channel=8, mipmap=True):
base_bytes = width * height * channels * (bits_per_channel // 8)
if mipmap:
# Mipmap 总大小约为基础大小的 1.33 倍
return int(base_bytes * 1.33)
return base_bytes
print(texture_memory(2048, 2048)) # 约 22,369,206 字节
内存占用只是其中一个方面。着色器每次对纹理进行采样时，GPU 需要从显存中读取对应 texel 及其邻近数据，这个过程会消耗大量带宽。纹理分辨率越高，单次采样涉及的数据块越大，缓存命中率越低。在大量像素并行采样的片元着色阶段，如果每个像素都从不同的高分辨率纹理区域读取数据，很容易触发缓存抖动，导致渲染帧率大幅下降。因此，即使平台显存足够，也不意味着可以无限提高纹理分辨率。
另一方面，纹理分辨率过低同样会造成问题。当模型靠近镜头时，低分辨率纹理会因为放大采样而显得模糊，即使使用双线性或三线性过滤，也无法恢复已经丢失的高频细节。合理的分辨率选择应当在内存、带宽和视觉清晰度之间找到平衡点。
二、不同平台的纹理限制与格式差异
移动端设备通常采用统一内存架构，CPU 和 GPU 共享同一块物理内存，系统还会为后台应用和操作系统预留大量空间。主流移动设备可供游戏使用的可用内存远低于标称总内存。例如一台 6GB 内存的手机，游戏可用内存可能不足 3GB，其中纹理预算往往只能控制在几百 MB 到 1GB 之间。与此同时，移动 GPU 的内存总线位宽较窄，带宽远低于桌面显卡，因此高分辨率纹理在移动端的性能代价更加明显。
桌面平台拥有独立显存，容量和带宽相对宽裕，但高分辨率纹理仍然会占用大量显存并增加加载时间。主机通常也使用统一内存，开发者需要同时为游戏逻辑、几何数据、渲染目标和纹理分配预算。WebGL 环境则受浏览器进程内存限制，单个纹理尺寸还受 MAX_TEXTURE_SIZE 限制，通常为 4096 或 8192，但仍需谨慎控制。
纹理压缩格式的差异也会影响实际分辨率选择。移动端常见 ASTC、ETC2，桌面端常用 BC7、BC3，这些压缩格式可以在保持一定视觉质量的同时显著降低内存和带宽占用。同一张 2048×2048 的纹理，使用 ASTC 6×6 压缩后内存可能只有 4MB 左右，比未压缩 RGBA8 小很多。因此在制定纹理分辨率时，需要先确定目标平台支持的压缩格式，再根据压缩后的实际内存评估预算。
平台限制不仅在于硬件，还在于开发管线。有些团队为节省工期直接统一使用 2048 或 4096 尺寸，这种做法在移动端很容易引发内存警告和闪退。正确的做法是建立按平台划分的纹理预算表，并为不同平台导出不同分辨率或压缩格式的资源。
三、基于屏幕覆盖率的纹理分辨率选择方法
屏幕空间覆盖率是判断纹理分辨率是否够用的核心指标。其基本思想是：模型在最终画面中所占的像素区域越大，需要的纹理 texel 越多；反之，远处或小面积的物体只需要低分辨率纹理即可满足视觉需求。估算所需纹理大小时，可以先确定模型在屏幕上的最大显示面积，再结合 UV 展开比例反推所需纹理像素数。
以一个第一人称游戏中的武器模型为例，假设武器在 1080p 屏幕上约占 600×400 像素，即 240,000 像素。如果模型的 UV 展开面积与屏幕显示面积基本对应，那么理想纹理应至少提供与屏幕像素相当的 texel 数。考虑到相机运动和超采样需求，实际需要的纹理分辨率通常会再乘以 1.5 到 2 倍的安全系数。对于 600×400 的显示区域，1024×1024 纹理通常足够；如果强行使用 4096×4096，视觉收益极小，但内存和带宽却增加了 16 倍。
下面的伪代码演示了如何根据屏幕上物体高度和纹理密度需求估算合适尺寸：
def estimate_texture_size(screen_height_pixels, screen_pixel_ratio=1.0, quality_scale=1.5):
# screen_height_pixels 表示物体在屏幕上的高度
# screen_pixel_ratio 表示设备像素比，如 Retina 为 2.0
# quality_scale 是超采样安全系数
required_pixels = int(screen_height_pixels * screen_pixel_ratio * quality_scale)
# 向上取最近的 2 的幂
power = 1
while power < required_pixels:
power *= 2
return power
print(estimate_texture_size(400)) # 输出 512
print(estimate_texture_size(1200)) # 输出 2048
注意代码中的 < 在 HTML 文本中已转义，但实际的 while 循环判断为小于号。这段代码只是简单估算，实际项目中还需要考虑模型 UV 布局是否均匀、有无拉伸区域以及纹理过滤方式。
Mipmap 是配合屏幕覆盖率工作的重要机制。启用 Mipmap 后，GPU 会根据像素在屏幕上的密度自动选择更低分辨率的层级，从而减少远处物体的采样带宽和闪烁。合理生成 Mipmap 可以降低高分辨率纹理在远处造成的性能浪费，但前提是基础分辨率本身不能过低，否则近景仍会模糊。
四、纹理分辨率分配策略与工程化落地
在真实项目中，不可能为每一张纹理单独精细计算屏幕覆盖，更常见的是按照资产类别预先划定分辨率范围。角色面部、武器、重要 UI 元素通常使用 1024 到 2048 尺寸；角色身体、主要道具使用 512 到 1024；远景建筑、地形装饰使用 256 到 512；地面平铺纹理可适当提高分辨率，因为其平铺后覆盖面积大，同时需要保证重复时的细节。
纹理图集也可以有效降低纹理数量，但会将多张小纹理合并为一张大纹理，这会推高单张纹理的分辨率。