Draco 与 Meshopt 压缩器

双向可用，这正是关键

能把 glTF 压成 Draco 的工具有很多，能把它还原回来的却几乎没有——而人们卡住的恰恰是后一个方向。较早的 Babylon.js 版本、Unity 的多个 glTF 导入器以及不少 DCC 软件，根本读不了 KHR_draco_mesh_compression。如果客户给你一个已压缩的 GLB，而你的管线拒收，你需要的是解压，而不是继续压缩。

这个工具两个方向都能做，全部在浏览器里完成，不上传任何文件。

Draco 与 Meshopt 的取舍

两者解决同一个问题，思路不同，选哪个取决于你要优化什么。

Draco 采用考虑网格连接关系的熵编码，文件最小——通常比原始顶点数据减少 80–95%。代价是解码耗时：解码器是一个体量不小的 WebAssembly 模块，解开大网格要花掉实打实的几十毫秒，而用户只能盯着空白等待。

Meshopt 使用字节级过滤器和简单得多的编解码方案。文件比 Draco 略大，但解码速度大约快一个数量级，而且格式设计上允许解码与流式加载并行。对于首屏渲染时间比传输体积更重要的网站，通常 Meshopt 更划算。

独立 .drc 就是不带任何 glTF 外壳的 Draco——只有几何体，没有材质、纹理和层级结构。适合科研管线和自定义加载器，作为带贴图资产的交付格式则毫无用处。

质量损失都发生在量化环节

两种编解码器都会量化：浮点属性按指定位深转成定点整数。这在设计上就是有损的，而每种属性的容忍度并不相同。

• 位置 —— 14 位 对绝大多数模型视觉无损。降到 12 位时，大模型上能看出顶点吸附到网格；降到 10 位就非常明显了。
• 法线 —— 10 位 是安全值。位深不足的表现是平滑着色表面出现色带。
• 纹理坐标 —— 12 位。 低于 10 位，UV 会漂移，纹理在表面上明显“游动”。
• 颜色 —— 8 位 与大多数顶点色数据原本携带的精度一致。

不要压缩两次

对已经是 Draco 的文件再次编码，意味着先解码、把已量化的数值再量化一遍、然后重新编码。每一轮损失的精度都无法找回。工具会在载入时检测已有压缩并提醒你——如果需要换参数，请先解压，再从干净的结果压缩一次。

它压不掉的部分

几何编解码器对纹理毫无作用。如果你 40 MB 的 GLB 里有 38 MB 是 4K PNG，Draco 只能省下几百 KB，你自然会觉得压缩没用。因此结果面板会单独列出 几何体字节数，让你看清编解码器实际的效果，而不被文件其余部分干扰。

隐私

Draco 和 Meshopt 都以 WebAssembly 形式在你的浏览器中运行。不上传任何内容。