1. 远处的摩尔纹和近处的模型抖动：Mipmap与LOD到底在解决什么
1.1 一个"简单引擎"也躲不过的渲染事故
当我在做一个简化版引擎时，第一个真正让我头皮发麻的画面问题不是光照不对，而是地板纹理在镜头拉远时开始疯狂闪烁，像有一层白色雪花在瓷砖缝里跳舞。与此同时，远处山坡上的低模树桩每一帧都在轻微抖动，边缘像有碎振动。这两个现象，一个是典型的高频纹理欠采样，另一个是几何体下采样后的时序抖动——本质上都是同一类问题：我们让渲染管线以"超出它分辨率能力"的方式去表达细节。Mipmaps和LOD，就是解决这两个问题最经典也最实用的工程手段。
Mipmap为纹理提前生成一组逐级降低分辨率的"备份"，当屏幕像素密度不足以重现高频细节时，GPU自动切换到模糊的层级，避免闪烁和摩尔纹。LOD则为同一个物体准备多档精度的网格，离得远就画粗模型的，把三角形预算让给屏幕里更值得表现的部分。在商业引擎里，这两个功能往往是一行设置的事：勾上"Generate Mipmaps"，再开一个"Auto LOD"。但在一个自己从零搭的简单引擎里，这两件事都要亲手串起来——从纹理资源的生成、上传，到渲染管线的采样状态，再到模型数据的组织与运行时切换。整个过程走一遍，比看十遍文档都有效。
这篇内容适合正在自研引擎、或者想搞明白"引擎里那个Mipmap选项到底在做什么"的开发者。我会把原理、实现链路、工程接入和踩坑记录全部摊开讲，代码以OpenGL风格为例，但思路是图形API通用的。
1.2 为什么远处的细节会"爆炸"：欠采样原理快速回顾
先把最基础的概念补上。屏幕上每个像素对应纹理上的一个区域，当物体拉远时，一个像素对应的纹理区域会变大。如果这个区域里包含了很多明暗交替的细节（高频分量），而GPU只取一个点去采样（点滤波），那这个像素就会被随机落到某个亮或暗的texel上。相邻像素随机性不同，就形成了闪烁和摩尔纹。
这本质上是采样频率低于信号频率导致的混叠。根据奈奎斯特采样定理，要无失真地重建一个频率为f的信号，采样频率必须至少达到2f。屏幕上每个像素是一个"采样点"，它的采样频率由投影后的像素密度决定；当纹理细节频率高于这个密度时，必然产生混叠。现实里我见过不少同学试图靠"把纹理分辨率调低一点"来解决问题，其实方向反了——分辨率再高，相机拉得足够远，高频细节一样会超出像素密度的表达上限，闪烁只会换个距离重新出现。
解决方向只有两个：一是提高采样频率，也就是提高渲染分辨率，但这是治标不治本；二是在采样之前把高频过滤掉，这正是Mipmap在做的事——预先对纹理做低通滤波，每一级mip相当于以不同频率上限得到的"模糊但无锯齿"的版本。
1.3 这两个问题为什么经常一起处理
如果只看画面问题，Mipmap和LOD可以完全分开解决。但它们在工程组织上有两个共同点：都需要"预生成多份数据"，都需要"运行时根据视距选择合适版本"。很多引擎把Mipmap和LOD放在同一个Resource Manager里管理，原因就在这里：纹理有一套mip chain，模型有一套LOD chain，本质都是同一个思路——预生成、运行时选择、生命周期管理。
它们还有一个共同的收益：降低带宽。Mipmap让GPU在远处像素上不必读取全分辨率纹理的texel，代价是纹理总内存增加约1/3；LOD让GPU不必渲染远处庞大三角形数的网格，代价是维护多套网格数据。在带宽受限的移动平台上，这两个优化往往是"不做就卡，做了就顺"的关键。所以我一直认为，简单引擎也值得认真做这两件事，它们直接决定引擎在不同场景下的帧率下限和画面质量下限。
2. 从2x2平均到4/3内存：Mipmap的生成算法与采样链路拆解
2.1 Mipmap不是一堆"缩小图"，而是一组预滤波结果
Mipmap这个概念最早在1983年的图形学论文中提出，思路是：把一张原始纹理做一系列2x2降采样，得到第0级（原始尺寸）、第1级（1/2宽高）、第2级（1/4宽高），一直到1x1像素。每一级都携带了前一级的高频信息被低频过滤后的结果。你可能觉得这不过是"把图缩小几份，远处选张模糊贴上去"，实际不是。
GPU采样的时候并不是只选某一级，而是在相邻两级之间做三线性插值（Trilinear Filtering）：先在同一级内做双线性插值，再在相邻两级之间做一次线性混合。这个混合系数来自屏幕像素在纹理坐标上的导数，也就是这个像素实际覆盖了多大一块纹理区域。代码里你通常只设置采样器的过滤方式，很少直接干预mip级；但调试时要理解，GPU内部会通过纹理坐标的偏导数估算"足迹"，再换算成需要哪一级。
所以，mip级别的选择本质是一个由视距和斜率驱动的自动过程。把物体拉远，纹理足迹变大，系统自动往高mip级（模糊）那边走；凑近看，又自动回到第0级取细节。这个自动切换如果做得好，肉眼几乎察觉不到；做得不好，就会出现一层一层"模糊跳变"，那是后面要聊的采样参数问题。
2.2 在CPU端自己生成mip链：滤波核与边缘处理
在简单引擎中，最省事的方案是调用图形API的自动生成接口，比如OpenGL里的glGenerateMipmap。但如果你希望资源加载阶段可控、可调试、可离线预处理，自己实现一遍生成逻辑会更有底。最经典的生成器是盒式滤波器：把2x2的四个texel颜色做平均，得到下一级的一个texel。每降一级，图像细节减半。
伪代码如下：
void GenerateMipChain(std::vector<Image>& mips) { const Image& base = mips[0]; Image prev = base; while (prev.width > 1 || prev.height > 1) { Image next(prev.width / 2, prev.height / 2); for (int y = 0; y < next.height; ++y) { for (int x = 0; x < next.width; ++x) { Color c = Average4( prev.GetPixel(2*x, 2*y), prev.GetPixel(2*x + 1, 2*y), prev.GetPixel(2*x, 2*y + 1), prev.GetPixel(2*x + 1, 2*y + 1)); next.SetPixel(x, y, c); } } mips.push_back(next); prev = next; } }这段代码里有一个容易忽略的细节：奇数尺寸纹理。宽高除以2向下取整时，最后一行或一列会被丢掉。实践里更稳妥的做法是"面积平均"——让每个mip像素覆盖上游对应范围内所有texel的均值，而不是严格的2x2。对普通素材，两者差别不大，纯盒式滤波就够用了。只有做高质量离线工具时，才需要考虑Kaiser窗口、三角形滤波器或Catmull-Rom锐化那些更复杂的方案。
另一个关键点是边缘处理。当UV超出[0,1]范围（比如用了重复寻址模式），GPU生成mip时如何处理边缘，直接影响平铺纹理在远处的接缝表现。最稳妥的做法是在生成第0级之前，把纹理左右、上下各扩展复制一圈——把靠边的像素镜像到对侧去，这样降采样时能感知到相邻周期内的颜色，生成的mip链在REPEAT模式下才不会出现黑边或白边。这个坑我在第五节详细说。
2.3 GPU端采样状态：两个过滤器参数决定画质
纹理上传并携带mip链之后，渲染时真正需要决策的只有两个采样参数：MIN_FILTER和MAG_FILTER。前者决定当屏幕像素覆盖的texel区域大于1时（缩小采样）如何选点，后者决定当覆盖小于1个texel时（放大采样）如何选点。
常规配置可以参考这张表：
| 使用场景 | MIN_FILTER | MAG_FILTER | 效果 |
|---|---|---|---|
| 三线性，推荐默认 | GL_LINEAR_MIPMAP_LINEAR | GL_LINEAR | 相邻mip级平滑过渡 |
| 双线性+mip就近 | GL_LINEAR_MIPMAP_NEAREST | GL_LINEAR | 有明显mip切换跳变 |
| 关闭mip，只双线性 | GL_LINEAR | GL_LINEAR | 远处会闪烁、摩尔纹 |
| 调试用，全点采样 | GL_NEAREST | GL_NEAREST | 无可参考性，通常只用于观察像素化 |
三线性过滤是最容易获得"还算不错"画质的起点。再往上升一步就是各向异性过滤（Anisotropic Filtering）：它能处理斜视地面这类场景——像素在纹理空间里呈现为不对称的长条形状，标准mipmap会把两个方向一起模糊，导致地板斜着看糊成一片。各向异性过滤会沿最长导数方向多采样几次，斜视清晰度提升非常明显。
实际开启方式上，现代GPU普遍支持到8x或16x各向异性，但接口写得比较啰嗦，需要先查询能力再设置参数：
GLfloat maxAniso = 0.f; glGetFloatv(GL_MAX_TEXTURE_MAX_ANISOTROPY_EXT, &maxAniso); glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAX_ANISOTROPY_EXT, std::min(4.0f, maxAniso));提示：各向异性过滤不是替代Mipmap，而是在Mipmap基础上对斜视采样做补偿，两者是叠加关系。先保证mipchain存在，再谈各向异性，顺序别反。
3. 一套模型的多副面孔：几何LOD的构建、简化与切换策略
3.1 三角形预算视角：为什么远处的东西不该那么精致
几何LOD的核心思想一句话就能说清：远处物体在屏幕上只占几个像素，你却用几万三角形去渲染，纯属浪费。现代GPU三角形吞吐量不低，但顶点处理、光栅化、带宽和后续像素填充的开销都会随三角形数上升。场景里如果有大量重复物件，差距立刻被放大。
举个我实际跑过的例子：场景里放100棵树，每棵5万三角形，合计500万三角形。没有LOD时，哪怕树已经退到屏幕边缘变成几个像素，也得把这500万三角形全部处理完。加LOD后，远处树切到500三角形的版本，100棵树的三角形开销降到5万，节省99%。移动端上这种优化尤其重要，因为移动GPU顶点处理能力比桌面差得多，带宽和发热也都是硬约束。
LOD不止是省三角形，还关系到帧率的稳定性。如果近距离三角形激增、远距离骤减，帧时间会忽高忽低，体感就是"卡一下、顺一下"。合理的LOD切换能让GPU负载在不同距离范围保持相对均匀，帧时间曲线平滑很多。
3.2 网格简化：从自动减面工具到离线管线
准备多档LOD，第一步是生成简化网格。简单引擎里最务实的做法不是自己写一套简化算法，而是用离线工具或开源算法库预先减面，导出为多套网格文件。业界用得最广的简化算法是QEM（Quadric Error Metrics，二次误差度量），思路是：迭代地挑选"合并后几何误差最小"的边进行坍缩，直到三角形数达到目标。误差用二次曲面近似衡量，所以能优先保住轮廓和特征线。
自己在简单项目里完全可以直接用3D建模软件或开源网格处理库的减面功能，把高模减到75%、50%、25%、10%三角形数，导出成几个文件。我的做法是在资源管线里约定命名规则：tree_LOD0.mesh、tree_LOD1.mesh……加载时统一装入同一个LODGroup组件。
如果确实想自己实现简化算法，推荐从最基础的"顶点聚类"（Vertex Clustering）开始：把模型所在空间划分成均匀网格，每个格子内的顶点合并成一个代表点，从而降低顶点数。这个方法简单、可控、稳定，画质损失确实比QEM明显，但用来理解"简化的本质是信息取舍"非常合适。跑通这条链路之后，再去换成QEM也不迟。
3.3 距离计算与切换阈值：别让LOD"闪来闪去"
网格准备好之后，运行时要做两件事：算距离、选LOD。距离计算通常有两种口径：相机到物体包围球中心的距离，简单稳定；相机到包围盒表面的距离，更精确，适合从内部穿过的隧道类物体。我默认用包围球中心距离，开销低，户外场景里差距不大。
切换阈值的选择也有两种思路。一种是直接给世界距离阈值，比如50米切LOD1、150米切LOD2，直观、好调、容易理解。另一种是屏幕空间误差（Screen-Space Error）：把物体最大简化误差投影到屏幕上，当误差小于某个像素数时才切换，更专业但调试成本高。简单引擎强烈建议先用距离阈值，跑起来之后再手工微调。
这里有一个非常容易踩的细节：延迟切换（Hysteresis）。如果切换阈值是20米，物体在19.9米和20.1米之间来回移动，就会出现频繁切换，肉眼看到的就是模型在"抽搐"。解决办法是让"升到更精细档"和"降到更粗糙档"的阈值之间留一段缓冲区。比如LOD1在距离小于30米时切上来，但要到距离大于45米时才切下去。这个缓冲区间能消掉大部分抖动。
3.4 离散LOD vs 连续LOD：简单引擎先走哪条路
主流水引擎里还有一种做法叫连续LOD（Continuous LOD），同一份数据在运行时根据距离动态调整拓扑，实时增减三角形。它省内存，还能避免切换瞬间的"pop"（模型突变），但实现复杂度高，而且在Deferred渲染或静态批次场景里要处理很多边界情况。
对"simple engine"我的建议非常明确：先用离散LOD，每档一个mesh，把框架跑通再说。离散LOD唯一的缺点就是切换时可能有个可见突变，但这个突变可以通过三种手段压到很低：把切换点放在物体移动慢、屏幕占比小的位置；用淡入淡出或顶点位置的线性过渡；以及最朴素的——让相邻两档网格的拓扑尽量接近。等框架稳了，若真有地形或大量植被需要连续过渡，再演进到CLOD也不晚。
4. 接入渲染管线的工程细节：驱动能力、内存开销与采样器配置
4.1 纹理上传：一次提交整个mip链
在简单引擎里，合理的数据流是：导入器把mip链全部生成好，渲染层创建纹理时用glTexImage2D逐级上传。如果你用glGenerateMipmap自动生成，第0级上传完后调用一次接口即可，但这会在运行时产生GPU端生成开销。我更倾向于在资源加载阶段就准备好完整mip链，避免每次新建纹理时重复计算。
伪代码如下：
GLuint CreateTexture2D(const std::vector<Image>& mips, bool aniso) { GLuint tex; glGenTextures(1, &tex); glBindTexture(GL_TEXTURE_2D, tex); for (int level = 0; level < (int)mips.size(); ++level) { const Image& img = mips[level]; glTexImage2D(GL_TEXTURE_2D, level, GL_RGBA8, img.width, img.height, 0, GL_RGBA, GL_UNSIGNED_BYTE, img.data.data()); } glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT); if (aniso) { GLfloat maxAniso = 0.f; glGetFloatv(GL_MAX_TEXTURE_MAX_ANISOTROPY_EXT, &maxAniso); glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAX_ANISOTROPY_EXT, std::min(4.0f, maxAniso)); } return tex; }这段代码的潜在问题在于GL_MAX_TEXTURE_MAX_ANISOTROPY_EXT这个枚举在不同驱动上的兼容性，以及从glTexImage2D开始到设置参数过程中任何一步的资源泄漏——如果外部代码忘了glDeleteTextures，一个带mip链的纹理就会白白占着几MB显存不放。所以我会建议在Texture类里用RAII管理生命周期，析构时统一释放。
4.2 内存账要算清：Mipmap实际只多占1/3
很多人一听说mipmap以为内存会翻倍，其实并没有。等比降采样后，整条mip链的总内存是原始纹理的4/3，也就是增加约33%。推导很简单：第0级占1份，第1级占1/4，第2级占1/16……几何级数求和：
S = 1 + 1/4 + 1/16 + 1/64 + ... = 1 / (1 - 1/4) = 4/3
所以1024x1024的RGBA8纹理，原始占4MB，带完整mip链后约5.33MB。场面上一串小纹理累加，大概多占1/3显存——这个代价换来的却是巨大的带宽节省，因为远处的像素不再需要把全分辨率texel从显存拖进缓存。做性能分析时，这是一个非常划算的交换。
但要注意压缩纹理的情况。ASTC、BC7等格式的每一级mip都有独立的压缩尺寸，而且不同格式对最小尺寸对齐有要求，比如某些格式要求每级宽高是4的倍数。如果在生成mip链时没有提前对齐尺寸，最后一两级可能出现无效数据或加载失败。这个问题在导入管线里就要定好规范：压缩纹理由离线工具统一做好mip链，运行时只负责上传，不做在线生成。
4.3 LOD数据组织：LODGroup和渲染器的协作
在运行时，我用一个LODGroup组件来管理一个物体的所有LOD网格：
struct LODGroup { std::vector<Mesh*> meshes; // LOD0, LOD1, ... std::vector<float> minDistances; // 每级生效的最小距离 float switchRange; // 迟滞缓冲区间 };渲染器每帧的逻辑是：取出相机位置，计算物体中心到相机的距离，从LOD0开始向后找，选择第一个满足dist < minDistances[i]的mesh；找不到则使用最后一级。配合前面说的迟滞，升级和降级各用一张不同的距离表，就能有效防止抖动。
这里还有一个容易忽略的优化：LOD选择不一定每帧都算。很多引擎会做"按帧抽样"，比如每隔0.2秒重新计算一次距离并选择LOD，中间帧沿用上一次结果。对慢速移动的物体效果明显，能省一点CPU，但要注意延迟不能大，否则玩家快速转头时会看到远处的LOD切换明显滞后。
4.4 Shader侧配合：采样器声明与mip级控制
接入渲染管线后，Shader里通常只需要把纹理采样器声明成sampler2D，过滤状态由纹理对象本身决定。但如果你想主动控制mip级，比如做基于视角的锐化或者某些混合特效，可以用textureLod(sampler, uv, lod)显式指定。这在Mipmap调试时特别有用：固定写一个LOD值，就能直接观察某个层级的画面。
还有一个常见误区：设置GL_TEXTURE_MAX_LOD限制了最大mip级，却忘记设GL_TEXTURE_MIN_LOD下限，导致某些驱动从异常层级开始采样。低配设备上偶尔出现的颜色偏差，排查时先看这组参数是否对称设置，能省下大量时间。
5. 用调试视图和性能数据说话：踩坑记录与调优验证
5.1 先把"当前用的是哪一级"可视化出来
Mipmap和LOD的调试，最怕的是看不出问题在哪。我的第一个建议是给引擎加两组可视化工具。
第一组是mip级别显示。用一个debug shader，把实际采到的mip级编码成颜色输出，比如LOD0=红、LOD1=绿、LOD2=蓝、LOD3=黄。一眼就能看出场景里哪些区域用了过高的mip级。如果你的API支持textureQueryLod之类的查询，可以直接在shader里拿到实际的mip level，不需要再猜。
第二组是LOD边界绘制。把每级LOD的切换距离用线框球体画出来，调试时拖动相机进出边界，直观感受切换点是否合理。我还会在Debug UI里加两个按键，手动强制切到LOD0或LOD2之类的级别，用来单独观察某一档网格的视觉质量。这两组工具加在一起，调参就不再是盲人摸象。
5.2 我踩过的三个坑，以及对应解法
第一个坑是mip边缘颜色渗透。我用REPEAT寻址平铺了一张带高亮边缘的砖墙贴图，拉远之后砖缝之间出现奇怪的暗色条纹。原因在于CPU生成mip时，2x2平均跨过了平铺边界，但驱动在REPEAT模式下的自动mip处理并不一定和我的生成逻辑一致。解法是在生成mip前把第0级纹理做边缘扩展复制，让降采样能感知到平铺的连续性；实在不行就改用GL_CLAMP_TO_EDGE专门处理含边缘语义的贴图，平铺面另开一张REPEAT纹理。
第二个坑是NPOT纹理。某张道具贴图尺寸是512x300，我在某台旧设备上上传带mip链的NPOT纹理后，画面直接黑屏，回退到双线性又正常了。原因是部分旧驱动对NPOT纹理加Mipmap的支持不完整。解法要么在导入管线把NPOT纹理统一重采样到二次幂，既规整又能更好对齐压缩格式；要么提前确认目标设备对NPOT纹理加Mipmap的支持情况，做功能开关动态回退。
第三个坑是LOD切换引起的"几何涟漪"。一套山体从LOD0切到LOD1时，顶点位置变化太大，切换瞬间山脊出现一圈肉眼可见的"涟漪"。解法有三个方向：调整简化算法参数，让低模在切换临界处尽量贴近高模位置，也就是做"保持边缘"；拉开切换距离，让变化发生在视觉注意力不集中的位置；最后还可以做顶点混合过渡，在过渡区间内对两个mesh的顶点位置做lerp。我最终用了顶点混合，效果最好，只是多花了一点CPU。
5.3 实测数据：多少优化才算"值得"
以我那个模拟项目X为例，场景是一个约200米见方的区域，里面大约300个带LOD的静态物体，40张使用Mipmap的纹理。改造前既没开Mipmap也没做LOD，远处场景最低帧大约35fps；改造完成后，同样场景能跑到55fps以上。
拆开看数据：开启Mipmap后，远处地面纹理的闪烁彻底消失，纹理带宽占用下降约30%；加离散LOD后，三角形数从约850万降到180万，draw call数没变，但顶点处理时间明显缩短。帧时间抖动也从改造前的±8ms缩小到±2ms。这不是什么理想环境下的漂亮数字，就是很普通场景量级的表现，足以证明这两个优化在简单引擎里的性价比有多高。
关键还是那句话：不要拍脑袋设LOD阈值。先用场景截图和profiler数据确定瓶颈，再决定每档LOD的切换距离。我把所有阈值都放在一个配置文件中，每次调参后跑同一段固定路径录像对比，比肉眼反复进出场景高效得多。
5.4 几个亲测有效的调优小习惯
第一，Mipmap从大纹理开始开。512x512的砖墙可能看不出太大差异，但2048x2048的复杂贴图在远处就是重灾区。优先把大尺寸纹理的mip链补上，效果立竿见影。
第二，LOD从"远处数量多的物体"开始做。树木、石块、路灯这类重复物件才是LOD最大的受益者，反而是那个唯一的主角模型优先级没这么高。
第三，每次改动只做一件事。把Mipmap和LOD拆成两个独立分支来做，独立测、独立回滚。这两项优化都有"视觉上没那么明显但profiler上很显著"的特点，一旦混在一起调试，很容易错误归因。
第四，保留一个强制关闭的开关。引擎里加一个--no-mip和--force-lod0的命令行参数，方便随时对照开启前后的画面与帧率。这个开关在后续优化shader和材质时也会派上大用场。
第五，调试Mipmap时给各级加上固定假色，跑一个固定旋转镜头看整体变化节奏。很多时候"看起来糊"并不是mip级别选得不对，而是相邻mip之间的过渡区太窄或太宽，用假色视图能直观发现问题出在切换节奏上。
