从ContextCapture到CesiumLab：倾斜摄影OSGB转3DTiles的完整工作流与踩坑指南

从ContextCapture建模到CesiumLab转3DTiles，一条踩坑踩出来的倾斜摄影实景三维工作流

干实景三维的同行应该都有这种经历：项目上用ContextCapture跑完倾斜摄影建模，拿到一堆OSGB格式的瓦片数据，结果到了Web端要发布模型的时候，浏览器直接不认，只能一脸懵地回头做格式转换。

我最早干这事儿的时候也绕了不少弯路。一开始是拿OSGB硬往Cesium里塞，折腾了一整天没弄明白，后来才搞清楚OSGB和3DTiles压根就是两个世界的东西。今天这篇就把我常用的那条“ContextCapture建模 + CesiumLab转格式”工作流完整捋一遍，从原理到实操、从参数设置到坑点排查，全部摊开来讲。内容主要围绕倾斜摄影数据从建模软件到Web三维引擎的完整链路，既适合刚接触实景三维的新手，也适合已经在项目里被格式转换折腾过、想系统梳理流程的同行参考。

1. 先搞清楚为什么要转格式：OSGB与3DTiles的本质差异

很多人一上来就急着找工具、点转换，结果参数一填全是懵的。我建议所有做这个流程的人，先把两个格式的底层逻辑弄清楚，后面操作才有方向感。

1.1 OSGB是什么，它的问题出在哪

OSGB全称OpenSceneGraph Binary，是OpenSceneGraph这套渲染引擎定义的二进制格式。ContextCapture建模结束后，默认输出的就是我们最常见的OSGB瓦片文件夹，目录结构大致是：一个Data目录下挂着若干Tile_开头的文件夹，每个文件夹内部又有LOD层级、每层下面有一堆以真实地理坐标命名的瓦片文件。每个瓦片文件本身就是一组三角网模型加对应纹理，局部来看信息完整，单块拿出来也能独立渲染。

问题在于，OSGB是为本地/桌面端渲染设计的格式，它的调度和加载逻辑依赖OpenSceneGraph的体系，而Web端的三维引擎——不管是CesiumJS还是Three.js——都没有原生加载OSGB的能力。你硬要往浏览器里丢OSGB，引擎根本不知道这个文件怎么解析。

更实际的问题是，OSGB的瓦片层级和目录组织方式与Web端需要的LOD调度粒度不匹配。浏览器加载三维模型靠的是“按需调度”，也就是我视野里能看到哪一级、哪几块，我就只加载哪几块。OSGB的瓦片划分虽然也是四叉树逻辑，但它的命名和索引方式是为文件系统设计的，Web端直接拿过来用，调度效率非常差，一加载就是整个模型往内存里堆，体量一大直接卡死。

1.2 3DTiles是什么，浏览器为什么只认它

3DTiles是Cesium团队在2015年前后提出并逐步完善的一套开放规范，核心目标就是解决海量三维数据在Web端的流式加载问题。它不是简单地把模型从一种格式变到另一种格式，而是定义了一个分块组织、按需调度、多级LOD的完整数据规范。

一个标准的3DTiles数据集由几个部分组成：最顶层是tileset.json，相当于整个数据的目录索引，描述了这个模型有哪些层级、每个节点的包围体、几何误差、包含哪些子节点等信息。tileset.json下面，是实际承载模型数据的瓦片文件，B3DM格式就是其中一个核心类型，专门用来打包带纹理的倾斜摄影模型。

CesiumJS在运行时先读取tileset.json，根据相机的位置、视锥、当前视角距离，计算出该加载哪些节点、跳到哪个LOD层级，然后只向服务器请求这些具体的瓦片文件。这就是3DTiles能承载大规模数据的核心原因——数据量再大，实际加载的永远只是你眼前能看到的那一小部分。

1.3 转换的本质：不是转格式，是重构调度逻辑

搞清楚两种格式的原理之后，再来看“格式转换”这件事就容易理解了。OSGB到3DTiles的转换，绝对不是把文件后缀改一下、或者简单做个二进制封装就能完成的。真正的转换过程要做的核心事情是：

• 解析OSGB瓦片内的三角网格、纹理、材质数据
• 把数据重新组织为3DTiles规范所要求的分块树状结构
• 重新计算每个瓦片节点的包围体、几何误差
• 为每一层级的数据生成符合Web端加载粒度的索引文件，也就是tileset.json

这个过程如果工具处理得不好，最常见的结果就是：切片数量爆炸导致请求量巨大、LOD切换生硬、包围体计算错误导致模型跳显。

所以，我自己在项目里对转换工具有一定硬性要求：必须能自动生成合理的LOD层级，最好能保留原始坐标精度，同时支持纹理压缩选项，不然数据量一大Web端根本跑不动。这也是我后来一直用CesiumLab的原因，它的切片算法和LOD策略在这一众工具里做得最省心。

2. 建模端前置准备：ContextCapture建模时的几个关键决定

很多人以为格式转换出问题都是转换工具的锅，其实有相当一部分坑是在建模阶段就埋下的。我做了三十多个倾斜摄影项目之后发现，ContextCapture建模时的几个设置直接决定了下游转换能不能顺利跑通。

2.1 照片采集阶段的注意事项

先说照片采集。这个环节看似和格式转换没关系，实际上关系非常大。ContextCapture的空三和建模都是基于照片重叠度的，如果外业采集时航线重叠率不足、航向重叠度不够，建出来的模型会出现空洞、变形，这些几何问题会原封不动地带到3DTiles里。

我个人的经验是，航向重叠率不低于80%，旁向重叠率不低于60%，复杂建筑区域还需要加密航线。另外像玻璃幕墙、水面这类弱纹理区域，光靠垂直航拍是不够的，需要增加倾斜镜头补拍。照片数量不够硬建模的项目，后期转3DTiles经常出现瓦片破洞、纹理偏移，排查起来比重新飞一遍还痛苦。

2.2 空三与建模设置对后续转换的影响

ContextCapture里新建工程后，第一步是添加照片并跑空三。空三的质量好坏决定了后续模型能不能建准。如果空三跑出来有分层、有弯曲，建出来的模型在高程上就会有问题。建议空三跑完务必看报告，参与度低于70%就得检查照片问题。

建模时有一个关键参数容易被忽略：建模范围。ContextCapture允许你用闭合多边形限定建模区域，这个范围一定要认真画，宁可稍大一点，也不要卡着建筑边线切。因为建模引擎在范围边缘生成的模型往往是不完整的，有个缺口或者薄片，转到3DTiles里这些毛边问题会被放大。另外在Production Setting里面，瓦片大小建议保持默认值附近，不要为了减少瓦片数强行调大，瓦片太大单次请求的数据量就大，Web端加载会明显变慢。

2.3 坐标系设置：最容易埋雷的环节

如果让我说建模阶段最容易给后续转换埋雷的环节，坐标系绝对是第一名。

ContextCapture导入照片时，每张照片都带了POS信息，也就是惯导记录的拍摄位置和姿态。这些坐标往往基于WGS84椭球。ContextCapture默认使用的坐标投影是WGS84 / UTM带号或者CGCS2000，具体取决于项目位置和控制点资料。

我强烈建议在建模阶段就把坐标系定死、定准，最稳定的方案是：项目采用CGCS2000或者WGS84对应的UTM投影坐标，然后在ContextCapture里设置输出坐标系为对应的EPSG代码。这样生成的OSGB本身就带好正确的坐标系统信息，转到3DTiles后直接在Cesium里加载就能落到正确位置。

反过来，如果建模时坐标系没仔细设置，OSGB内部记录的坐标就是你原始的定位坐标，转换工具拿到的是一个没有地理参考的裸网格，后面再纠偏就非常费劲。

这是一个可以直接抄作业的经验：坐标系的EPSG代码务必用笔记下来，和OSGB数据放在同一个文件夹下，项目交接的时候这个纸条比任何文档都好使。

3. 转换工具选型：为什么我选择CesiumLab

市面上能把OSGB转成3DTiles的工具不少，各有各的路子。这块儿的工具选型直接决定你的工作效率，所以我把自己的选型过程和理由展开讲讲。

3.1 市面主流的转换路线对比

先说大方向，目前可行的路线大概有四条。第一条就是CesiumLab这种可视化桌面工具，直接选数据、设参数、点转换，一条龙出结果；第二条是用一些开源的转换库或者脚本，基于osgb和3d-tiles相关的Python/Node库自己写转换逻辑；第三条是走Cesium ion平台，在线把数据上传上去由云端转；第四条是用一些三维GIS平台自带的转换能力，比如超图、ArcGIS Pro等，也能导出3DTiles。

对比来看，Cesium ion对国内项目来说要上传数据，数据安全性是个现实问题，而且它有流量限制，大数据量的项目基本不现实。开源脚本方案对技术人员友好，但OSGB格式本身有版本差异，不同ContextCapture版本生成的数据内部结构不完全一样，脚本很难通吃，自己调解析逻辑调试成本非常高。

ArcGIS Pro转3DTiles能力我实测过，功能是完整的，但它的切片规则比较重，产出的3DTiles体量偏大，而且依赖ArcGIS平台环境，对纯Web前端项目来说不是最优解。

3.2 CesiumLab的核心优势与适用边界

我在几个项目里对比过之后，CesiumLab成了我的主力工具。它最打动我的三个点，第一个是格式兼容性好，ContextCapture生成的典型OSGB目录它基本直接识别，不用我去人工拼接映射关系，步骤上省了很多；第二个是切片参数的灵活性，LOD层级、纹理压缩、坐标系设置都能手动控制，而不是黑盒处理；第三个是它配套的周边功能，比如地形切片、矢量数据转换、单体化，用同一个工具就能串起整个三维WebGIS项目的前期数据处理。

当然CesiumLab也不是银弹。它本质是桌面端工具，处理超大数据量时比较吃内存，我拿一个约200GB的OSGB数据集转过一次，转换过程中内存占用超过32GB，跑了一个多小时才完成。如果项目数据量特别大，建议分批转换然后用它自带的合并功能，处理效率会更稳。

3.3 安装部署与基本界面认识

CesiumLab的安装没什么门槛，下载对应自己操作系统的版本，解压就能用。第一次打开会启动一个本地服务，然后在浏览器里访问它的操作界面。第一次用的人别慌，这属于正常逻辑——数据量大的转换任务，放浏览器里跑反而比原生窗口更稳定。

界面主要分几个模块：数据转换、地形切片、矢量转换、影像处理、单体化工具等。入口看上去多，但OSGB转3DTiles最常用的就是“数据转换”模块，选OSGB转3DTiles这个子功能就行。其它功能属于进阶玩法，后面有机会单独开篇。

提示：CesiumLab启动后如果提示端口被占用，在设置里改一个端口重启就行。实际操作中大部分启动异常都是端口冲突或者路径中带中文和空格导致的。

4. CesiumLab转换实操全过程

下面进入整个项目最核心的实操环节。我会按照我在真实项目中的操作顺序，从数据导入开始，到参数设置、执行转换、结果检查，全流程过一遍，重点参数给出我的推荐值和背后理由。

4.1 数据导入与工程创建

打开CesiumLab，进入数据转换模块，选择“OSGB转3DTiles”。第一步是要你把OSGB的原始数据路径选中。

这里有一个重点坑位：选择路径的时候，一定要选到那个包含Tile_开头文件夹的上层目录，或者直接定位到Data目录那一层，而不是选到某个具体的Tile_xxx瓦片文件夹内部。我第一次用的时候就是选到了某个Tile_0001文件夹里面去，结果工具只识别到这一个瓦片，转换出来的3DTiles只有巴掌大一块模型。

正确的目录层级是这样的：

项目根目录 └── Data ├── Tile_0001 ├── Tile_0002 ├── Tile_0003 └── ...

在数据路径选择框里，填到Data这一层即可。CesiumLab会自动扫描下面的所有Tile文件夹，把它们当作一个完整模型来处理。

选完数据后会让你设置输出路径，建议单独建一个输出文件夹，不要和原始OSGB放在一起，避免转换过程产生的大量临时文件把源数据目录搞得一团乱。

4.2 关键参数逐项解析与推荐值

参数设置是转换流程里最需要用心的地方。CesiumLab的参数面板里选项不少，但真正需要每次项目都关注的，主要是下面这几个。

坐标系设置：这个参数直接决定你的模型能不能在Cesium里落到正确位置。要明确一点：你把OSGB转成3DTiles，坐标系是可以跟着转换的。最稳定的做法是选择“使用源数据的坐标系”，前提是前面建模阶段你已经把坐标系设置正确了。如果源数据坐标系信息缺失，就需要手动选。优先选CGCS2000 / WGS84的UTM投影坐标系，EPSG代码对应起来。这里我一般会额外勾选“输出为经纬度”，让CesiumJS端加载更省事。

LOD层级设置：LOD层级决定了模型在不同距离下显示的细腻程度。CesiumLab会自动根据源数据的层级生成对应的LOD，但你可以控制最大LOD级别。我的建议是默认自动即可，它会尽量保留源数据的LOD结构。不要盲目追求高LOD，因为每多一层，数据体积就大一圈，浏览器加载压力也随之增大。如果你的模型主要用于Web端大场景浏览，而不是精细单体展示，可以适当降低最高LOD，性能收益非常明显。

纹理压缩：这是Web端性能优化的核心参数。原始纹理都是JPG/PNG级别的贴图，未经压缩直接打包进3DTiles，一个中等规模的项目可能产生几个GB的纹理数据。把纹理压缩选项打开，格式选择WebP或者JPEG，质量设置为80左右，肉眼几乎看不出区别，但数据体积能下降一半以上。如果模型要在移动端跑，甚至可以压到70，性能优先。

坐标原点：3DTiles规范要求所有的几何数据都是相对某一个原点来记录的，这个原点坐标写在tileset.json的transform属性里。CesiumLab会自动计算模型的中心点作为原点，一般不用手动干预。但如果出了位置偏移的问题，可以回来检查这个原点的值是否合理，尤其是当OSGB原始坐标是经纬度小数格式时，容易出现origion计算异常的问题。

4.3 转换执行与产物检查

参数全部设置完成后，点转换，任务就进入执行队列。整个转换过程的时间取决于数据量和机器配置。我拿一个大约30GB的OSGB数据集做示例，在32GB内存的机器上转换耗时大概15分钟左右。过程中可以在任务列表里看到进度条和日志输出。

转换完成后，记得做三件事的检查。

第一件，看产物完整性。输出文件夹下应包含一个tileset.json文件，以及若干b3dm文件。如果连tileset.json都没有，说明转换失败，去日志里看报错。

第二件，看产物规模和层级。统计一下b3dm文件的总数和总大小，如果产生了几万个碎片文件，说明LOD合并策略可能没生效，加载时请求压力会很大。这种时候需要回到参数设置，调低最大LOD层级或者开启合并策略。

第三件，就是直接拉到Cesium里试加载。

5. Cesium中加载3DTiles与周边能力扩展

转换完的3DTiles最终要交给CesiumJS加载展示，这块儿也一并说清楚，因为很多人在这一步也会卡一下。

5.1 用CesiumJS加载转换结果

Cesium中加载3DTiles的核心API是Cesium3DTileset，加载代码非常简单，核心逻辑是创建一个Cesium3DTileset对象，传入tileset.json的地址，然后加入场景即可。

一个基础的加载代码片段长这样：

// viewer为Cesium.Viewer实例 const tileset = await Cesium.Cesium3DTileset.fromUrl( '你的数据服务地址/tileset.json' ); viewer.scene.primitives.add(tileset); // 视角飞到模型位置 viewer.zoomTo(tileset);

这段代码跑通之后，可以做两件事来验证模型是否正常：一是转视角观察模型有没有错位、拉伸、破洞；二是打开开发者工具的Network面板，滚动视角看瓦片请求是否按需发起。如果加载后模型位置不对，先排查坐标系设置；如果加载后模型黑乎乎一片没有任何纹理，先排查纹理路径和纹理压缩格式兼容性。

我建议在实际项目中把3DTiles放到独立的静态资源服务上，开启Gzip压缩，配合浏览器的缓存策略，加载体验会好很多。别直接用本地文件路径加载，CesiumJS出于安全策略会拦截本地文件的跨域请求，用本地服务器起一个静态服务就好，很多新手在这一步卡住过。

5.2 地形切片、shp转3dtiles、单体化等实用扩展

CesiumLab的功能其实不止OSGB这一个入口。我后面做项目时陆陆续续把它的周边能力都用上了，上手顺序大概是“切地形”能配合倾斜摄影模型叠加高程，还有shp矢量转3dtiles、还有模型单体化这几种场景。

6. 常见问题与排查技巧实录

最后这部分，我把这几年做倾斜摄影建模和Web端展示过程中遇到的典型问题整理成一张速查表，方便你直接定位问题、抄作业。

6.1 常见问题速查表

6.2 位置偏移的深度排查

位置偏移这个问题值得单独拎出来细说，因为它牵涉到的环节最多，且不像纹理丢失那样一眼能看出来。处理这类问题时我会遵循“从源头到末端逐层排查”的原则：首先是ContextCapture建模时设置的坐标系，其次是CesiumLab转换时的坐标系设置和坐标原点，最后是CesiumJS加载时的viewer场景坐标。三个环节只要有一个坐标系对不上，模型就会飘。

如果排查一圈发现三处设置都没问题，还有一个隐蔽的可能：模型本身漂移但Scale没校准。CesiumJS默认长度单位是米，如果源数据单位不是米，就需要在tileset的modelMatrix里做缩放修正。这类极端情况比较少见，但真遇到了没有思路，可以先检查单位。

6.3 纹理丢失的排查思路

纹理性问题在格式转换中最为常见。我看到很多同行遇到白模第一反应是工具的问题，但其实OSGB内部纹理存储和3DTiles的纹理规范本身就是不同的，转换工具如果处理不好纹理坐标映射，就出现丢纹、错纹。

按照这个顺序排查，基本能解决90%以上的纹理问题：先看转换日志有没有纹理相关告警；其次更换纹理压缩格式，WebP格式在某些环境下有兼容风险，换JPEG重转一次验证；再不行就看原OSGB纹理贴图是否存在中文路径——很多工具对中文路径处理有Bug，这是容易忽略的根因。

6.4 不同建模软件的适配问题

还有一个经验值得一提，就是不同版本ContextCapture生成的OSGB在内部结构上是有差异的。CesiumLab官方说兼容主流版本，但我在实际项目中遇到过老版本生成的OSGB里部分瓦片文件命名不规范，导致转换后局部瓦片丢失的情况。解决办法是更新到新版本软件重新导出OSGB，或者把有问题的瓦片所属区域单独重新建模再合并。

另外用其它建模软件（比如大疆智图、重建大师）产出的OSGB，CesiumLab也能识别，但个别数据源的瓦片结构不标准，转换前可以先用工具自带的“OSGB目录检查”看一眼，提前发现问题就不会白等一场转换。

7. 延伸：从OSGB到3DTiles之外的完整WebGIS数据链路

转换本身跑通之后，很多项目还涉及周边数据配套。结合我接触过的项目来看，一个完整的实景三维Web项目，除了倾斜摄影模型，还需要地形、矢量、单体化等数据配合，这里把顺手趟过的几个相关方向也放在一起说说。

7.1 地形切片与模型叠加

倾斜摄影模型解决的是“地物看得清”的问题，地形数据解决的是“地表起伏还原”的问题。CesiumLab的地形切片模块可以把DEM数据转成Cesium支持的地形格式，最终在Cesium中作为terrainProvider加载。

实操中建议把地形切片和倾斜摄影模型用相同的坐标系生产。如果坐标系不一致，模型和地形之间会出现悬浮或沉陷。部分项目由于航拍和DEM高程基准不同，模型比地形低了一截，处理方式是统一高程基准，或者给模型加一个高程偏移值，在代码里通过模型矩阵调整。

7.2 shp矢量转3DTiles与单体化

shp转3dtiles是我搜索词里很重要的一条，实际对应的是矢量数据三维化展示这个需求。CesiumLab里可以把shp面的要素直接拉伸成三维的3DTiles数据。这个功能做楼层高度示意、规划方案对比相当好用。

单体化则实景三维里避不开的话题。所谓单体化，就是把连片倾斜摄影模型按栋、按户“切”成可以独立选中的对象。目前常见的做法是借助矢量面数据结合3D Tiles的扩展能力，为每个对象挂接属性，点击模型就能弹出对应的楼栋信息。CesiumLab里的单体化工具会自动完成大部分切割和属性挂接流程，生成的3DTiles在Cesium里点击即可查询属性。

我已经在几个项目中用这套流程落地过：先把楼层shp转成带高度的3DTiles轮廓，再与倾斜摄影模型叠加，既实现了立体化展示，又实现了按楼层选中的交互。两个数据相对齐是关键，检查两个数据源的坐标系是否一致就行。

7.3 其它模型格式转入3DTiles

fbx转3dtiles也是搜索热词，它对应的是人工精模进Web端的场景。ContextCapture建的倾斜摄影模型虽然真实，但模型结构比较碎，做单体的精细展示还是不够。我的做法是把3ds Max建的精细模型导出为FBX，再通过CesiumLab的转换功能转成3DTiles，加载到Cesium里做展示。

FBX转3DTiles需要注意的是PBR材质的兼容性。Cesium对PBR参数的支持已经比较成熟，但部分自定义Shader材质还是会在转换中丢失，这类问题只能回到建模软件里把材质简化一下再导出。

办公文档转换成网页时，有些团队会用到Jupyter Notebook导出静态HTML或PDF，再嵌入Web平台作为辅助资料，这条链路可视化展示也不错，但和3DTiles就不是一个技术线了，这里不展开。

8. 我给新手的实操建议与最后几点经验

最后分享一些碎碎念性质的经验，都是项目里一次次踩坑换来的，不算系统，但每条都有用。

第一，做转换之前先把数据备份好。倾斜摄影的OSGB源数据动辄几十个GB，转换过程万一参数设置错误，有可能破坏原始数据。我给自己的规矩是源数据盘只读，转换产物单独放一个盘。

第二，参数调整要一次只动一个。转换设置面板里选项很多，出现问题的时候不要同时改好几个参数，否则出问题了你根本判断不了是哪个参数导致的影响。我一般用最小化验证法：拿一小块数据反复试参数，确认效果后再跑全量数据。

第三，善用CesiumLab的预览功能。转换完成之后，CesiumLab本身可以直接预览生成的3DTiles，如果这一步就能看到问题，就别急着往前端写代码。

第四，每一步都记录。建模时的坐标系、转换时的参数设置、加载时的代码版本，这些信息全部记录下来，出现问题时才能快速判断是哪个环节出了错。

说实话，整个工作的流程并不复杂，但涉及的工具和环节很多，每一步都有很多细节。我见过太多人卡在某个环节小而简单的问题上熬几天，其实很多问题网上都能搜到，关键是得有耐心去定位、去判断。

希望这篇内容能帮你少走点弯路。你按这条链路走一遍，大概率第一次就能把数据完整跑通。如果遇到这篇没写到的问题，欢迎留言交流，我看到会回复。