Babylon.js一帧之旅（番外一）：大模型加载实战——压缩、拆分与渐进式加载

「Babylon.js 一帧之旅」番外篇。正篇第（二）篇讲过就绪机制：资源不就绪，帧循环整帧跳过。但当时我们回避了一个更现实的问题——如果资源本身就很大呢？一个 200MB 的 glb 摆在面前，等待它的不是"就绪后渲染"的美好结局，而是漫长的白屏、浏览器崩溃和流失的用户。本篇系统讲解大模型加载的三大工程手段：压缩、拆分、渐进式加载。

引言：大 glb 的成本到底花在哪

在动手优化之前，先看清一个大文件从网络到屏幕的完整成本链：

网络下载（带宽 × 文件大小） → 解析与解压（CPU：glTF 解析、Draco/Meshopt 解码、纹理解码） → JS 堆内存（几何 ArrayBuffer、解码后的纹理位图） → 上传显存（顶点缓冲、纹理——KTX2 可以直接上传压缩格式） → 着色器编译（材质就绪，第（二）篇讲过，往往是最慢的一环） → 首帧渲染

Babylon.js 本身不设文件大小上限，真正的天花板是浏览器内存（桌面端 2GB 量级即为危险线，iOS Safari 更苛刻）。而且注意：解压后的内存占用远大于文件本身——glb 是打包格式，解压时一份数据可能同时躺在 JS 堆和显存里。

三大手段分别作用于这条链的不同环节：

一、压缩：把 200MB 变成 20MB 的正规军

1.1 几何压缩：Draco 与 Meshopt

glTF 生态有两个主流通用几何压缩方案，Babylon.js 都原生支持：

• Draco（Google）：压缩率更高，解码稍慢，扩展名KHR_draco_mesh_compression；
• Meshopt（meshoptimizer）：压缩率略低，解码极快，还为 GPU 做了顶点缓存优化，扩展名EXT_meshopt_compression。

Babylon 侧的接入只需保证解码器可用（新版默认从 Babylon CDN 加载，离线部署时需自行配置）：

// Draco 解码器配置（自建/CDN 皆可）BABYLON.DracoCompression.Configuration={decoder:{wasmUrl:"https://cdn.babylonjs.com/draco_wasm_wrapper_gltf.js",wasmBinaryUrl:"https://cdn.babylonjs.com/draco_decoder_gltf.wasm",fallbackUrl:"https://cdn.babylonjs.com/draco_decoder_gltf.js",},};// Meshopt 解码器配置BABYLON.MeshoptCompression.Configuration={decoder:{url:"https://cdn.babylonjs.com/meshopt_decoder.js",},};

压缩在制作管线完成，不在运行时：

# gltf-transform（推荐，Node 生态）npx @gltf-transform/cli optimize model.glb model.min.glb\--compressdraco --texture-compress ktx2# 或 gltfpack（meshoptimizer 官方工具，输出 Meshopt 压缩）gltfpack-imodel.glb-omodel.min.glb-cc-tc

1.2 纹理压缩：KTX2 是显存优化的关键

很多人只压几何不压纹理，结果文件小了、显存照样爆——因为 PNG/JPG 加载后必须解码成 RGBA 位图，显存占用 = 宽 × 高 × 4 字节 × 1.33（mipmap），与文件格式无关。一张 4K PNG 无论压到多小，显存里都占约 85MB。

KTX2/Basis Universal改变了游戏规则：纹理以 GPU 原生压缩格式（ASTC/BC7 等）直接上传显存，不解码成位图。显存占用通常降到 1/4~1/8。

// KTX2 解码器配置（同样需要转码器，把中间格式转到目标 GPU 格式）BABYLON.KhronosTextureContainer2.URLConfig={jsDecoderModule:"https://cdn.babylonjs.com/babylon.ktx2Decoder.js",wasmUASTCToASTC:"https://cdn.babylonjs.com/uastc_astc.wasm",wasmUASTCToBC7:"https://cdn.babylonjs.com/uastc_bc7.wasm",// ...其余转码 wasm 按需配置};

1.3 传输层压缩：gzip / Brotli

glTF 的 JSON 部分和未压缩几何对文本压缩很友好。服务器开启 gzip 或 Brotli，传输体积再降一档。注意：已用 Draco/KTX2 压缩的部分几乎不会再受益（高熵数据），所以这不是替代方案，而是补充。

压缩组合拳的经验值：原始 glb → Draco/Meshopt + KTX2 + Brotli，总体积降到 1/10 很常见；同时显存占用因 KTX2 再降一个量级。

二、拆分：首屏不需要整个世界

压缩有极限。当一个场景"再怎么压也有 100MB"时，思路要从"变小"转向"分而治之"——首屏根本不需要整个场景，只需要用户第一眼看到的东西。

2.1 按空间/部件拆分资产

制作侧把场景拆成多个 glb，配合一份清单（manifest）描述依赖关系：

{"core":["hero.glb","lobby.glb"],"zones":[{"id":"showroom","file":"showroom.glb","trigger":{"x":50,"z":0,"radius":30}},{"id":"garden","file":"garden.glb","trigger":{"x":-80,"z":40,"radius":40}}]}

2.2 运行时按需加载

// 首屏：只加载核心区awaitBABYLON.SceneLoader.AppendAsync("./assets/","hero.glb",scene);awaitBABYLON.SceneLoader.AppendAsync("./assets/","lobby.glb",scene);// 之后：按玩家位置异步加载邻近区域constloadedZones=newSet<string>();scene.onBeforeRenderObservable.add(()=>{for(constzoneofmanifest.zones){if(loadedZones.has(zone.id))continue;constd=BABYLON.Vector3.Distance(player.position,newBABYLON.Vector3(zone.trigger.x,0,zone.trigger.z));if(d<zone.trigger.radius){loadedZones.add(zone.id);// 不 await——后台加载，不阻塞帧循环BABYLON.SceneLoader.AppendAsync("./assets/",zone.file,scene);}}});

注意一个时序细节（呼应第（二）篇）：后台 Append 会让scene.isReady()再次变为 false，但已就绪的内容不受影响，画面不会冻结——只有新加载部分的材质就绪前，那部分网格不进入渲染。这正是拆分方案体验流畅的原因。

2.3 只导入需要的部分：ImportMesh

如果模型已经是一个文件，但首屏只需要其中几个网格：

// 只导入指定名字的网格，其余不解析constresult=awaitBABYLON.SceneLoader.ImportMeshAsync(["chassis","wheel_FL","wheel_FR","wheel_RL","wheel_RR"],// 只要车身和轮子"./assets/","car_full.glb",scene);

适合"同一个模型文件，不同页面用不同部分"的场景，避免为首屏解析整个大文件。

三、渐进式加载：先有画面，再求精致

拆分解决"加载谁"，渐进式解决"先加载哪个版本"——同一个物体，先来低模撑住画面，高模后台替换。

3.1 方案 A：MSFT_lod 扩展（格式内建）

glTF 的MSFT_lod扩展允许在单个文件内按屏幕占比打包多级 LOD，加载器按覆盖屏幕面积自动切换。Babylon 原生支持该扩展，零代码获得渐进式体验——前提是制作管线支持导出。

3.2 方案 B：手动多级加载（通用做法）

管线侧为每个模型导出低/高两个文件，运行时先低后高：

asyncfunctionloadProgressive(name:string,scene:BABYLON.Scene,position:BABYLON.Vector3){// 第一步：低模先行（几十 KB，秒出画面）constlow=awaitBABYLON.SceneLoader.ImportMeshAsync("","./assets/",`${name}_low.glb`,scene);low.meshes.forEach(m=>m.position.addInPlace(position));// 第二步：高模后台加载，完成后无缝替换BABYLON.SceneLoader.ImportMeshAsync("","./assets/",`${name}_high.glb`,scene).then(high=>{high.meshes.forEach(m=>{m.position.addInPlace(position);m.setEnabled(false);// 先藏好，等就绪});// 等高模材质真正就绪再切换（呼应第（二）篇的就绪机制）scene.executeWhenReady(()=>{high.meshes.forEach(m=>m.setEnabled(true));low.meshes.forEach(m=>m.dispose());// 低模退场，释放内存});});}

要点：切换时机挂executeWhenReady而不是.then——.then只代表数据解析完，高模的着色器可能还在编译，贸然切换会看到"闪现消失再出现"。

3.3 与第（五）篇的运行时 LOD 的关系

注意区分两个 LOD：加载期 LOD（本篇）解决"下载什么"，渲染期 LOD（第（五）篇addLODLevel）解决"画哪个"。两者可以叠加：渐进式加载完成后，高模自身仍带运行时 LOD，远处画低层、近处画高层。

四、加载后的性能收尾

大模型进来只是第一步，让它跑得动还有几个标准动作（与第（五）（六）篇呼应）：

scene.executeWhenReady(()=>{// 静态场景：冻结活动网格列表，跳过每帧剔除重算scene.freezeActiveMeshes();// 静态网格：冻结世界矩阵，省掉每帧矩阵计算scene.meshes.forEach(m=>{if(!m.metadata?.isDynamic){m.freezeWorldMatrix();m.doNotSyncBoundingInfo=true;}});// 材质不再变化：冻结材质，跳过每帧 dirty 检查scene.materials.forEach(mat=>mat.freeze());scene.blockMaterialDirtyMechanism=true;});

注意：冻结是承诺——冻结后再动这些对象需要对应的解冻（unfreezeWorldMatrix等）。动态物体不要冻结。

五、实战：完整的大模型加载管线

把全篇手段组合成一个生产级加载流程：

asyncfunctionloadLargeScene(canvas:HTMLCanvasElement){constengine=newBABYLON.Engine(canvas,true);constscene=newBABYLON.Scene(engine);// ① 加载 UI 与超时兜底（第（二）篇的机制）engine.displayLoadingUI();scene.onReadyTimeoutDuration=60000;scene.onReadyTimeoutObservable.addOnce(()=>{showError("加载超时，请检查网络后刷新");});// ② 配置解码器（压缩资产的前提）configureDecoders();// Draco / Meshopt / KTX2，见前文// ③ 首屏资产：低模 + 核心区，带进度constprogressEl=document.getElementById("progress")!;letloaded=0;constfirstScreen=["hero_low.glb","lobby.glb"];for(constfileoffirstScreen){awaitBABYLON.SceneLoader.AppendAsync("./assets/",file,scene,(e)=>{if(e.lengthComputable){progressEl.textContent=`首屏资源${loaded+1}/${firstScreen.length}：`+`${Math.floor((e.loaded/e.total)*100)}%`;}});loaded++;}// ④ 首屏就绪：关 loading，启动渲染——用户此刻已看到画面awaitscene.whenReadyAsync();engine.hideLoadingUI();engine.runRenderLoop(()=>scene.render());// ⑤ 后台渐进：高模替换 + 邻近区域按需加载upgradeToHighPoly("hero",scene);startZoneStreaming(scene);// ⑥ 全部就绪后做性能收尾scene.executeWhenReady(()=>optimizeStaticScene(scene));return{engine,scene};}

这个流程的体验节奏：第 1~2 秒低模画面出现（loading 结束）→随后几秒高模无缝替换 →探索过程中新区域无感加载。用户从"盯着进度条"变成"已经在场景里"。

六、常见误区

误区一：只压几何不压纹理。
文件确实小了，但 PNG/JPG 进显存一律解码成 RGBA 位图，显存照样爆。纹理必须上 KTX2。

误区二：以为 gzip 能替代 Draco。
传输压缩不解压后的内存问题：Draco 减小的是解码后顶点数据的体积，gzip 只压缩传输。两者解决不同环节，都需要。

误区三：高模.then里立刻替换低模。
数据解析完 ≠ 着色器编译完。切换挂executeWhenReady，否则会看到模型短暂消失。

误区四：后台加载时认为"场景不就绪 = 画面冻结"。
只有新加载部分延迟渲染，已就绪内容照常绘制——这正是流式加载可行的基础。

误区五：低模加载后不 dispose。
渐进替换完成后，低模必须dispose()释放内存，否则"渐进"变成了"双份"。

误区六：拆得越碎越好。
每个文件都有网络往返、解析、材质编译的固定开销，几十 KB 一个的碎片文件会拖垮加载。经验上单个资产包保持在 2~15MB 区间，按"空间区域 + 使用时机"划分，而不是按物体。

七、小结

• 大模型加载的成本链：下载 → 解压 → JS 堆 → 显存 → 着色器编译，优化要逐环对症；
• 压缩：几何用 Draco/Meshopt，纹理用 KTX2（显存优化的真正关键），传输层 gzip/Brotli 兜底；
• 拆分：manifest + 按需 AppendAsync，首屏只加载必需区域，已就绪内容不受后台加载影响；
• 渐进式：MSFT_lod 或手动低模先行，高模替换的时机挂executeWhenReady；
• 收尾：静态内容 freeze 三件套（activeMeshes / worldMatrix / materials）；
• 体验目标一句话：让用户先看到，再看好。

本篇为「Babylon.js 一帧之旅」番外篇一，与正篇第（二）（五）（六）篇互为补充。