网页里的 3D 模型为什么这么卡？减面、合并顶点与贴图压缩

一个模型在 Blender 视口里转得飞快，导出放进网页却加载十几秒、拖动就掉帧。原因不在浏览器"弱"，而在于 Web 端的预算和桌面软件完全不同：要走网络下载、要在各种设备的 GPU 上实时渲染。优化的本质，是在网格、顶点、贴图三处削掉对观感贡献很小的开销。

因为 Web 端比桌面建模软件多了两道硬约束：下载带宽和设备 GPU 的下限。桌面软件里模型已在本地、GPU 也通常较强；而网页要先把模型通过网络传到用户设备，再在可能是低端手机的 GPU 上实时渲染。

这带来两类瓶颈：一是加载——文件越大，首次可见时间越长；二是运行时——三角面、draw call、贴图采样开销决定帧率。优化就是围绕这两类瓶颈展开，对应到模型上是三个可下手的维度：三角面数、顶点数据、贴图体积。

减面（decimation / mesh simplification）的目标是用更少的三角面逼近原始轮廓。主流做法是基于二次误差度量（QEM, Quadric Error Metrics）：算法为每条边估算"折叠它会让表面偏离多少"，每次优先折叠误差最小的边，反复迭代到目标面数。

这解释了为什么适度减面看不出差别——平坦区域的大量小三角面，移除后对轮廓几乎零影响；而高曲率的边角，算法会尽量保留。但有明确边界：

• 过度减面会塌陷轮廓：减到一定比例后，曲面变成棱块、细节消失，临界点取决于原模型的几何分布。
• UV 接缝和法线易受损：减面可能破坏 UV 边界，导致贴图错位，需要算法专门保护接缝。
• 硬表面 vs 有机体差异大：机械件（硬表面）对减面更敏感，有机模型（角色、地形）容忍度更高。

很多模型存在逻辑上同一个点被存了多份的情况：导出时按面拆分顶点，相邻面不共享顶点，于是顶点数远超几何上应有的数量。合并这些重复顶点（weld / merge by distance），在面数不变的前提下也能减小数据量、提升缓存命中。

这里有个常被忽略的点：顶点是否合并要看属性是否一致。位置相同但法线或 UV 不同的点不能盲目合并，否则会破坏硬边或贴图。所以合并是"位置相同且属性兼容才合"，不是简单去重。这也是为什么面数相同的两个模型，渲染开销可能差很多——顶点复用率、由此产生的索引缓存效率不一样。

很多人盯着面数优化，却忽略贴图往往才是文件大头。一张未压缩 4K 贴图的像素数据约 4096×4096×4 ≈ 64MB，多张叠加轻松压过网格。贴图优化有两条不同性质的路径，别混为一谈：

关键区别：普通图片压缩只省下载，解码后在显存里还是原样大；而 GPU 压缩纹理（如 Basis Universal / KTX2）能让 GPU 直接采样压缩数据，下载和显存双省，代价是引入块压缩特有的画质损失。

网格本身的下载体积，还能靠几何压缩进一步降低，代表是 Draco。它对顶点属性做量化（把浮点坐标降到有限精度）+ 熵编码，常能把网格数据压到原来的几分之一。

但要权衡两点：一是量化是有损的，坐标精度下降可能让高精度模型出现细微抖动；二是解码有运行时成本，需要在客户端跑解码器，对超低端设备是额外开销。所以 Draco 适合"网络是瓶颈、设备尚可"的场景，不是无脑全开。

没有统一答案，取决于 workload：

• 展示类 Web（产品看图、配置器）：优先压加载——减面到轮廓够用、贴图按显示尺寸降、上几何压缩。
• 高端可视化（医疗、工业精检）：精度优先，谨慎减面和量化，宁可加载慢。
• 移动端/弱网：显存和带宽都紧，GPU 压缩纹理和激进减面收益最大。

判断这类优化适不适合一个模型，关键看它面向什么设备、容许多少精度损失、瓶颈是下载还是渲染：瓶颈在下载就先压贴图和几何，瓶颈在帧率就先降面数和 draw call，精度敏感就把所有有损手段的力度调小。

Web 端 3D 卡顿，根因是它比桌面多了下载带宽和设备 GPU 下限两道约束。优化对应三个维度：减面（QEM 优先折叠低误差边，过度则轮廓塌陷）、合并重复顶点（位置与属性兼容才合，提升缓存复用）、贴图与几何压缩（区分"只省下载"与"省显存"，Draco/KTX2 各有有损取舍）。这些手段都是在观感和开销之间做权衡，没有"一键最优"，只有"针对目标设备和精度要求的合适力度"。