做三维一张图、数字孪生时，经常会遇到这样的需求：几十 GB 的倾斜摄影、上百 MB 的 BIM 模型，要在浏览器里流畅打开，还要和地图、管线、监测点位叠加在一起。3D Tiles 就是为这类场景设计的数据格式。
3D Tiles 是什么 #
3D Tiles 最初由 Cesium 团队提出，后来成为 OGC（开放地理空间信息联盟）社区标准，用于在网络上流式传输和渲染海量三维地理数据。它的核心思路和二维地图瓦片类似：把大场景切成很多小块，按视距分级加载。离得远只加载粗糙的大块，拉近后再加载更精细的小块。
一套 3D Tiles 数据由两部分组成：
- tileset.json：描述整棵瓦片树，每个节点记录包围体（boundingVolume）、几何误差（geometricError）和子节点；
- 瓦片内容文件：1.0 版常见 b3dm（批量模型）、i3dm（实例模型）、pnts（点云）；1.1 版可以直接引用 glTF / glb，并支持更完整的元数据。
常见三维数据怎么转成 3D Tiles #
| 源数据 | 典型格式 | 转换要点 |
|---|---|---|
| 倾斜摄影 | OSGB（带 metadata.xml） | 读取原点坐标，按原有 LOD 层级重组瓦片树 |
| BIM | IFC、RVT 导出格式 | 简化构件、合并材质，保留构件 ID 与属性 |
| 通用模型 | OBJ、FBX、glTF | 指定放置位置与朝向，必要时自动生成 LOD |
| 管线数据 | Shapefile、DXF、GeoJSON | 按管径、埋深生成圆管或方沟模型，再切片 |
一般流程是：读取模型 → 确定地理位置（坐标配准）→ 构建 LOD 层级 → 压缩几何与纹理 → 写出 tileset.json 与瓦片文件 → 在三维平台中加载验证。
常见问题与原因 #
模型加载后位置偏了、飘在空中或埋在地下 #
最常见的原因是坐标系或原点没对上。倾斜摄影的 metadata.xml 里记录了投影坐标系和原点，转换时要正确读取；BIM 和通用模型本身多是局部坐标，需要手动指定经纬度、高程和旋转角。高程基准不一致（椭球高与正常高）也会导致整体抬高或下沉几十米。
打开很慢、拖动卡顿 #
通常是几何误差（geometricError）设置不合理或单个瓦片过大。几何误差太小，客户端会过早请求高精度瓦片；单瓦片太大，下载和解析都慢。合理的 LOD 分级加上 Draco 几何压缩，能明显改善加载速度。
纹理模糊或颜色发灰 #
纹理被过度压缩或降采样会变糊；颜色发灰常见于色彩空间处理不一致。可以在压缩率和清晰度之间调整，或者对重点区域保留更高的纹理分辨率。
BIM 模型转换后属性丢了 #
转换时需要把构件 ID 与属性写入瓦片的批量表或元数据中，前端点击构件时才能查到属性。只导出几何的转换方式会丢失这部分信息。
转换前的准备清单 #
- 确认数据的坐标系、高程基准和原点；
- 倾斜摄影检查瓦片目录与 metadata.xml 是否完整；
- BIM 模型先在建模软件里清理无用构件和重复面；
- 明确目标平台（如 CesiumJS 或基于它的数字孪生平台）支持的 3D Tiles 版本。
常见问题 #
3D Tiles 和 OSGB 有什么区别？ #
OSGB 是倾斜摄影生产软件常用的输出格式，主要面向桌面端软件；3D Tiles 是面向网络流式加载的开放标准，浏览器里的三维平台可以直接按需加载。Web 端三维一张图通常需要先把 OSGB 转成 3D Tiles。
3D Tiles 1.0 和 1.1 应该选哪个？ #
先看使用的三维平台支持哪个版本。1.1 可以直接使用 glTF 作为瓦片内容，元数据能力更完整；如果平台只支持 1.0，就输出 b3dm 等传统格式。
管线数据能转成 3D Tiles 吗？ #
可以。按管径、管底埋深和管线类别生成三维管线与检查井模型，再切成 3D Tiles，就能和倾斜摄影实景在同一个场景里叠加显示。
转换后的 3D Tiles 怎么发布？ #
3D Tiles 是静态文件，放到任意 Web 服务器（如 Nginx）或对象存储上，开启跨域访问即可被三维平台加载；内网环境同样适用。