5.1 外协件盘点：模型格式与取舍

5.1 外协件盘点：模型格式与取舍

本节摘要：模型格式决定"进厂的是全套标准件还是缺件毛坯"。本节按信息完整度、体积、平台支持三个维度盘点五类常用格式，给出 GLTF 系的压缩伴件使用条件与一张按场景查的决策表，是外协工位的验收第一关。

格式不是后缀名，是信息量

把模型文件当图片对待，是外协事故的源头。一张图片只装像素，一个模型文件却是个压缩包：网格（顶点与面）、材质引用、贴图文件、骨骼、动画片段、节点层级，全都可能塞在里面。格式之间的差别，本质是"这个包里装多少、压得多狠、谁认识它"。OBJ 只装静态网格，材质要靠一个伴生文件描述、贴图再另算；FBX 装得全但格式封闭、浏览器不认识，靠加载器现场翻译；GLTF 按现代 Web 的口味设计——JSON 描述结构、二进制存数据、贴图可内嵌，网格动画骨骼一次带齐。

一个直观对比：同一把 4 万面的椅子，OBJ 加伴生文件约 6 MB、贴图另计；GLB 内嵌压缩贴图约 1.2 MB；再开 DRACO 网格压缩，掉到 400 KB 左右。体积差 15 倍，加载体验就是两个时代。

图：格式决策表——按场景对号入座

压缩伴件的启用条件

GLTF 系有两个压缩伴件，启用与否取决于两笔账。DRACO 压网格：把顶点数据再压 50% 到 90%，代价是加载后要跑解码（浏览器上耗时通常几十毫秒，可接受）。面数上了五位数、文件超过 2 MB 的模型建议上；几百面的小件属于"压缩比跑不赢开销"。KTX2 压贴图：把图片转成 GPU 友好的纹理格式，省显存还免解码，代价是导出管线多一道工序。贴图总量大（如带四张贴图的角色模型）建议上；单张小图标不值得。

启用 DRACO 只需给加载器配解码器，三行代码的事，但要提前和设计部对齐导出选项——"导出时勾不勾压缩"是外协沟通单上的固定条款，别等文件到厂才发现解码器没配。

动手：给格式做一次体检

背景：设计部交付了三版同一台叉车模型：chair 老格式的 FBX、完整贴图的 GLB、压过的 DRACO GLB。要求选出上线版本并报告体积。

操作：分别加载，记录体积与进场后的面数、贴图数量，填进验收单。

import { GLTFLoader } from 'three/addons/loaders/GLTFLoader.js';
import { DRACOLoader } from 'three/addons/loaders/DRACOLoader.js';

const loader = new GLTFLoader();

// 用到 DRACO 压缩件时才需要解码器；普通 GLB 不要配
const draco = new DRACOLoader();
draco.setDecoderConfig({ type: 'js' }); // 低并发场景用 js 解码，省一个 worker
loader.setDRACOLoader(draco);

function inspect(url) {
  loader.load(url, (gltf) => {
    let meshes = 0, tris = 0, textures = 0;
    gltf.scene.traverse((obj) => {
      if (obj.isMesh) {
        meshes++;
        tris += obj.geometry.index ? obj.geometry.index.count / 3 : 0;
        const mats = Array.isArray(obj.material) ? obj.material : [obj.material];
        mats.forEach((m) => { if (m.map) textures++; });
      }
    });
    console.log(url, { meshes, tris, textures });
    stage.scene.add(gltf.scene);
  });
}
// inspect('forklift.glb');        // 预期：1 网格 约 42000 面 4 贴图
// inspect('forklift_draco.glb');  // 预期：同信息，文件体积降约七成
​

结果：两个 GLB 的面数与贴图数完全一致（压缩不损信息），文件体积一为 2.1 MB、一为 620 KB；FBX 版经转换后内容一致但多花了一道工序。上线版定为 DRACO GLB。

解读：验收单上的三列——网格数、面数、贴图数——分别对应三笔后续开销：节点层级深度影响遍历、面数影响绘制与内存、贴图数影响显存与带宽。当场报数，比上线后凭感觉猜"为什么卡"便宜一百倍。另一个隐藏发现：GLTF 的材质是标准化的物理材质，进场即可直接对接第 3 章的 PBR 流程；而 OBJ 进来只有网格，材质贴图要手工重配——"带不带全套信息"在验收这步直接折算成工时。

变式：设计部只会出 FBX 怎么办？不必强改工作流，约定"交付即转换"：用建模软件的导出功能转成 GLTF 再进厂，转换是一次性的，长期用翻译式加载器（每帧开销与兼容风险）不划算。极端情况——模型来源是扫描或打印切片（STL），进厂前先补 UV 与材质，等于按 3.3 节的上漆工序重新走一遍。

散装外协的常见翻车与沟通条款

OBJ 类散装交付最常翻车的不是格式本身，而是"货到件不齐"：贴图文件漏传、路径引用断了、材质描述文件里的贴图名大小写对不上——线上环境下大小写敏感，本机预览好好的模型上线就丢贴图。处置分两层：沟通层，把"交付物 = 模型加贴图加清单"写进交接模板，收货先验件数；技术层，加载器支持自定义路径解析回调，把贴图地址统一改写到自己的资源目录，杜绝散装路径进产线。另一类高频问题是"贴图名带中文或空格"，个别环境会静默失败——外协沟通单上固定一条：文件名一律小写英文加连字符。这些条款琐碎，但每一条都对应一次真实返工，写进模板一次，省下的是每个项目的扯皮时间。

本节要点回顾

• 模型文件是压缩包：网格材质贴图动画全在内，格式差别即信息量差别；
• GLB 是上线正身：单文件、体积小、信息全，Web 交付默认答案；
• 压缩伴件按账启用：DRACO 管网格大户，KTX2 管贴图大户，小件免压；
• 验收当场报三数：网格数、面数、贴图数，对应遍历、绘制、显存三笔账；
• 翻译式加载是下策：FBX 转一次再进厂，别让每帧渲染替格式还债。

格式已定，下一节进装卸工序：异步加载的时序编排、进度看板与失败兜底，把"黑盒进厂"变成标准流程。