小张是某设计院的BIM工程师。
上午10点，甲方发来消息："下午2点项目汇报，把最新的BIM模型在Web端展示一下。"
小张打开平台，上传模型，点击加载。进度条在1%停了整整3分钟，然后浏览器标签页变灰，弹出一个提示—— "此页面已无响应" 。
这不是小张运气不好。这份模型由Navisworks导出，原始文件约300MB，包含数十万个构件、数百万三角面。而浏览器标签页的内存上限只有4GB左右——把这样的模型直接扔进浏览器，就像往一个已经快满的杯子里倒整壶水，溢出只是时间问题。
后来晨曦雷霆BIM做了一件事，让同样的模型从"加载1分钟、帧率6FPS"变成了"首屏1秒可见、帧率48FPS"。
这件事的核心，就是 LOD（细节层次）技术 。
一、BIM模型在Web端的三座大山
小张的遭遇不是个例。BIM模型天生有三个"重"：
第一座山：体量大
一个建筑结构机电全专业的BIM模型，从Navisworks导出后，文件动辄300MB以上。这些数据里不仅有三维几何，还包含材料、供应商、施工阶段等大量工程属性信息。
第二座山：零件多
BIM模型不是一整块，而是由成千上万个独立构件拼成的——梁、板、柱、墙、门窗、机电管线……以我们测试的某项目为例，一个模型里就有 48万多个构件 ，每个都有自己的形状、位置和属性。
第三座山：精度高
BIM模型承载着工程语义，不能像游戏模型那样随意合并减面。每个构件必须在对应的LOD层级下保留应有的几何特征——螺栓就是螺栓，管道就是管道。这种"不能随意糊弄"的特性，让Web端渲染时丝毫马虎不得。
这三座山压在一起，浏览器的"小身板"根本扛不住。直接加载的结果，往往不是"卡顿"，而是浏览器直接抛出 Out of Memory 错误，页面崩溃。
二、LOD是什么？就是"远近高低各不同"
苏轼有句诗："横看成岭侧成峰，远近高低各不同。"
LOD技术的核心思想，跟这句诗一模一样： 你站在不同的距离，看到的东西就应该是不同的。
· 站在远处俯瞰整个建筑，你看到的是轮廓——不需要看到每根螺栓、每块玻璃
· 走近了，盯着某个构件仔细看，才需要加载完整的精细模型
LOD把这个常识用在了3D模型上：
· 远处 ：浏览器只加载一个低精度的"外壳"——反正你也看不清细节
· 近处 ：才加载完整的高精度模型
就这么一个简单的道理，让BIM模型的 首屏可见时间从60秒变成了1秒 。
晨曦雷霆BIM的3D Tiles技术，就是LOD思想在Web 3D领域的最佳实践。它把模型按空间切分成一块块"瓦片"（Tile），构建成一棵树形结构。浏览器只需要加载当前视角下能看到的那几块瓦片，而且只加载当前距离下必要的细节程度。
三、用数据说话：LOD到底有多大魔力？
理论说再多，不如看真实数据。我们用晨曦BIM的一个实际项目——某建筑结构机电全专业模型（Navisworks导出，约300MB，48万+构件）——做了对比测试：
| 指标 | 帧率 | 内存占用 | 首屏可见时间 | 体感 |
|---|---|---|---|---|
| 无LOD，直接加载 | 6 FPS | 浏览器 OOM 崩溃 | 60秒+ | 页面无响应，最终崩溃 |
| 有LOD（3D Tiles） | 48 FPS | 约 428 MB | 1秒 | 流畅操作，指哪打哪 |
几个关键数字的含义：
· 首屏1秒可见 ：不是说完整模型1秒加载完，而是LOD先加载最低精度的轮廓，用户1秒内就能看到模型大致形态，后续细节在交互过程中逐步加载。
· 帧率提升700%（达到原来的8倍） ：6帧是"幻灯片"，48帧是"丝滑操作"。
· 内存从"崩溃"到"可控" ：无LOD时浏览器直接OOM，有LOD后内存稳定在428MB左右。LOD不是让模型变小，而是 让每一兆内存都用在刀刃上 ——不该渲染的瓦片坚决不加载。
注：原始300MB为Navisworks压缩包大小。LOD加载进内存时需要解压并转为GPU可识别的顶点缓冲（Vertex Buffer），故内存占用高于源文件属Web 3D渲染中的正常技术现象。
当前视角下，LOD在做什么？
下面是我们在 晨曦雷霆BIM中截取的运行时数据：
· 已加载到内存中的构件： 43万个
· 当前帧实际渲染的构件： 22.8万个
· 近一半的构件被LOD系统"过滤"掉了——它们要么距离太远看不清，要么被其他构件遮挡
· 视角从“拉远俯瞰”切换到“拉近细节”时，三角面数暴涨 3.5 倍（190 万 → 660 万），帧率从 59 FPS 降至 42 FPS，但依然流畅（>30 FPS）
这意味着： LOD系统每一帧都在做"聪明"的决策 ，只让必要的东西占用GPU资源。
四、LOD落地过程中踩过的三个坑
技术原理听着简单，真正落地的时候，坑不少。
坑一：浏览器 Out of Memory
现象 ：Cesium加载大型BIM模型时，浏览器标签页内存持续增长，最终抛出 Out of Memory 错误，页面崩溃。
排查过程 ：
第一步，打开Chrome任务管理器，观察标签页内存。发现模型加载完成后，内存没有稳定，而是持续缓慢增长——每秒涨约2MB，几分钟后标签页就崩了。
第二步，用Chrome DevTools的Memory面板做了两次堆快照（Heap Snapshot），一次在加载完成时，一次在崩溃前。对比发现，晨曦雷霆BIM的 3DTileset 内部缓存了大量已卸载瓦片的GPU资源，没有真正释放。
第三步，定位到根因：晨曦雷霆BIM的瓦片卸载机制在默认配置下，会保留一定数量的瓦片作为缓存，以避免频繁加载/卸载导致的卡顿。但对于BIM模型，单个瓦片的几何数据量远大于倾斜摄影模型，默认缓存策略过于激进，内存积压严重。
解法 ：
· 调低 maximumCacheOverflowBytes 参数，并将 maximumMemoryUsage 设置为 512 MB（给系统留出缓冲余地），限制Cesium的瓦片缓存上限
· 在业务层监听模型切换事件，主动调用 tileset.trimLoadedTiles() 清理不再需要的瓦片
· 通过调参在缓存命中率和内存安全之间找平衡
效果 ：内存稳定在 428MB 左右，不再持续增长，长时间操作也不崩溃。
坑二：长构件切割——"一根管子撑爆一个瓦片"
现象 ：模型加载后，某些视角下帧率突然掉到个位数。用Inspector排查，发现某个瓦片包含了近10万个三角面——远超单瓦片的合理上限。
根因 ：BIM模型里常有很长的管道和墙体，一根管子可能延伸几十米。如果按空间均匀切割，这根管子会整体落入同一个瓦片，导致该瓦片文件过大，加载慢、渲染卡。
解法 ：
采用"按大小自适应切割"策略。设置一个三角面数阈值（我们设为5000），任何超过这个数量的构件，继续递归切分，直到每一块都大小合适。同时合并相同材质的小构件，减少Draw Call。
特别注意：这种物理切分仅针对渲染层（瓦片）。业务层必须配合唯一构件ID（GUID）进行映射，以保证点击拾取时能精准反查出完整的原始构件，避免"点中管道中间段却高亮整根管子"的错乱逻辑。
效果 ：单瓦片最大三角面数从10万降到5000以内，消除了帧率骤降的卡顿源头，为最终稳定达到48FPS扫清了障碍。
五、LOD不是万能的
LOD在"大场景俯瞰"时效果最好——你站在远处看整个园区，浏览器只需要加载低精度轮廓，帧率拉满。
但有些场景下，LOD的优化空间有限：
· 单个构件细查 ：你放大到一面墙看施工细节，这时必须加载最高精度瓦片，LOD帮不上忙
· 密集构件同屏 ：机电管线密集区域，即使有LOD，同屏可见的构件数量仍然很大
· 属性数据加载 ：LOD优化的是几何渲染，构件属性（材料、供应商等）的加载需要单独处理
所以LOD是BIM上Web的 必要条件 ，但不是充分条件。完整的Web BIM方案还需要配合属性按需加载、视图状态管理、构件隔离显示等策略。
六、总结
回到开头小张的故事。
没有LOD时，小张的汇报变成了灾难——甲方领导在旁边等着，浏览器直接Out of Memory崩了。
有了LOD后，同样的模型，1秒首屏可见，48帧流畅交互。
LOD不是锦上添花的"优化选项"，而是决定BIM模型在Web端 能不能跑 的生死线。
