Tiny Online Tools
别再猜「适合网页」到底是什么标准
每一个最终放上网页的3D模型都必须装进某个预算里，但几乎没有人把这个预算白纸黑字写下来。于是就有了那个熟悉的循环：导出、上传、看着手机卡成幻灯片、把贴图改小一点再导一次、如此往复。这款工具把顺序反了过来：您先选定模型要投放到哪里——桌面端、移动端还是WebXR——它会在您动手改任何东西之前，明确告诉您超了哪几项限制、超了多少。
预算全部摊开给您看
| 指标 | 桌面端 | 移动端 | WebXR |
|---|---|---|---|
| 文件大小 | 15 MB | 5 MB | 3 MB |
| 三角面数 | 1,500,000 | 300,000 | 150,000 |
| 绘制调用 | 200 | 50 | 30 |
| 纹理内存 | 512 MB | 128 MB | 96 MB |
| 最大纹理尺寸 | 4096 | 2048 | 2048 |
| 材质数量 | 100 | 25 | 15 |
WebXR那一列最严苛，这是有意为之。头显每一帧都要以高分辨率把整个场景渲染两遍，还得赶在72–90 Hz的时限之内。三角面预算只有移动端的一半，不是悲观，是算术。
纹理内存是最常被忽略的那项指标
一张4096 × 4096的纹理在GPU上约占67 MB的RGBA数据，生成mip链之后大约是89 MB——而它的源文件可能只是一张2 MB的JPEG。八张这样的纹理，就足以让一台中端手机爆内存，无论那个GLB本身有多小。这正是本工具把GPU纹理内存与文件大小分开评估的原因，也是为什么把一张纹理从2048降到1024，省下的内存是省下的字节数的四倍。
这份方案究竟做了什么
最多五项操作，每一项只有在分析确实发现了理由时才会被推荐，并且把理由原原本本写出来：
- 清理 —
dedup、prune、weld。永远值得做，永远无损。 - 简化 — 用二次误差简化把面数降到三角面预算之内，仅在超标时执行。
- 合批 —
instance、palette、join，同时压低绘制调用与材质数量。 - 纹理 — 缩放到计算出的目标尺寸并重新编码为WebP。
- 压缩 — 量化，加上Draco或Meshopt。
顺序是固定的，因为顺序很重要：焊接必须在简化之前，实例化必须在合并之前，编码永远放在最后。任何一项您不认同，直接关掉即可。
老实说明局限
满足全部预算并不等于稳定60 fps。过度绘制、透明度和着色器开销，在一个静态文件里是看不出来的。而且join只会合并共用同一材质的网格。所有处理都在本地完成——您的资源始终不会离开浏览器。