尧图网站建设 
简介这是一款用于将osgb格式数据转换为3DTiles格式的专用转换工具主要面向需要将倾斜摄影数据或BIM模型在Cesium平台上进行Web端展示的开发者、GIS工程师及测绘行业用户。工具仅支持64位操作系统在内存寻址与处理规模上更有优势能有效解决大规模三维场景在浏览器中加载缓慢、渲染卡顿的问题适合城市级倾斜模型和建筑信息模型的数据预处理。资源包共123个文件大小约8.35MB除主程序exe外还包含31个依赖dll、大量坐标与投影转换定义的csv/xsd/wkt文件以及少量xml、txt、svg等辅助文件可应对不同坐标系与地理参考场景的转换需求。目前已有426人学习下载。通过该工具用户能将osgb格式的倾斜摄影模型或BIM模型高效转为3DTiles并在Cesium中快速加载和交互展示适用于城市规划、建筑测绘、数字孪生等场景。工具内置了较完整的坐标系与投影支持对需要处理地理配准数据的用户尤其实用。1. 格式认知与转换思路1.1 osgb与3dtiles到底是什么很多刚接触倾斜摄影的同学第一次看到“.osgb”这个后缀时第一反应是“这是个什么格式用什么软件能打开”——说实话我第一次拿到航测数据时也懵了一下。osgb全称是OpenSceneGraph Binary它是OpenSceneGraph图形引擎定义的二进制二进制格式通常由ContextCapture简称CC原Smart3D、大疆智图、重建大师等建模软件生成。它的内部结构是一个树状的节点体系每个节点对应一个LOD层级和一块瓦片区域所有纹理贴图以二进制流内嵌在文件里所以单文件往往动辄几十兆甚至上百兆。而3dtiles是Cesium团队在2016年前后推出的开放格式标准专为海量三维数据的流式加载设计后来也成了OGC社区的事实标准。它的核心思路是把模型切成四叉树/八叉树的瓦片集合每一级瓦片有独立的gltf或b3dm文件配合tileset.json描述整棵树的索引关系。浏览器端的Cesium.js引擎拿到tileset.json后就能按视锥体裁剪、按距离调度瓦片从而实现“先粗后细、随看随载”的浏览体验。所以简单说osgb是建模软件的“私有产物”3dtiles是Web端三维地球的“通用语言”。二者之间没有直接互通的接口必须借助转换工具来处理。1.2 为什么要从osgb转到3dtiles如果只是在本机用CC自带的查看器浏览模型osgb完全够用甚至性能比3dtiles更好——毕竟它是原生格式读取路径最短。但一旦你想把倾斜模型发布到Web端让客户在浏览器里无需安装任何插件就能查看、量测、标注3dtiles就成了绕不开的选择。我经手过的几个项目都是这个套路无人机采集照片 → CC建模生成osgb → 转成3dtiles → 发布到Cesium或自研WebGIS平台。市政规划、违建巡查、地质灾害监测这些场景“能打开看”和“能在网页上随时查”是两个完全不同的交付标准。还有一个容易被忽视的原因3dtiles本身是开放的后续做单体化、落图、与BIM模型叠加都更方便而osgb的私有性限制了很多上层应用开发。2. osg2cesiumApp工具选型分析2.1 为什么选中这个命令行工具市面上osgb转3dtiles的工具不算多常见的有这几类一是用CC自带的“导出3dtiles”功能但CC的版本要求高、导出流程繁琐而且对电脑配置要求极高二是用CesiumLab它是图形界面操作适合新手但免费版有限制大模型处理需要付费授权三是用开源方案如py3dtiles、cesium-tiles等这些脚本存在一个共性问题——对osgb的多级LOD支持普遍不理想转换后经常出现破面、纹理丢失。osg2cesiumApp是GitHub上的一个开源命令行工具1.13是我一直在用的稳定版本。它直接读取osgb内部的节点结构逐层重写为3dtiles规范的组织形式不经过中间格式转换所以精度损失小、速度也快。我也试用过几个其他工具综合下来在“转换质量、处理效率、参数可控性”这三个维度它在我手里的项目里表现是最稳定的。2.2 1.13版本的主要特性1.13版本有几个值得注意的更新点。首先是支持了更多的坐标系统转换不只是WGS84经纬度像CGCS2000高斯投影、UTM分带都能配其次是纹理压缩选项可以选择不压缩、转成JPEG或WebP后两者能显著减小瓦片体积再有就是对大规模数据的断点续转支持处理到一半异常中断后重新运行命令可以直接跳过已完成的瓦片这个功能在应对几百G级别倾斜数据时能省下大量时间。不过要提醒一句这类开源工具对系统的依赖通常比较“挑剔”我分别试过Windows和Linux环境同一套数据在两个系统上的表现会有细微差异——Windows下内存占用略高但文件IO更稳定Linux下处理速度快一些不过需要手动处理一些动态库依赖。首次使用建议先用一小块数据做流程验证再上大规模正式数据。3. 实操完整转换流程3.1 环境准备与文件检查这一步看起来基础但很多人恰恰是因为数据前处理没做到位导致转换中途各种幺蛾子。拿到osgb数据后我一般先做三个检查。第一确认osgb文件目录结构。正常的CC导出结构是一个Data目录里面按Tile_编号分块每个编号目录下还有若干级子目录最终层级的文件夹里存放具体osgb文件。如果你的数据是分散的最好还原成这个结构再转换不还原也行但要记录好根目录路径。第二检查坐标系信息。CC导出osgb时通常会在同级目录附带一个metadata.xml文件里面记录了坐标系统、原点坐标、范围等信息。osg2cesiumApp1.13在转换时会读取这个文件来校准位置。如果你的数据是从其他渠道获取、没有metadata就必须自己准备坐标参数否则转换结果的位置会偏到不知哪里去。第三留意纹理贴图数量。有些建模软件导出的osgb把纹理拆成了多个jpg/png文件放在外部osgb里只是引用路径。osg2cesiumApp虽然内嵌了纹理打包功能但外部纹理的路径如果包含中文或空格Linux环境下很容易读取失败。如果遇到这类情况我建议先用云图管家或ModelLab这类软件把纹理重新打包进osgb再做转换。3.2 命令行参数解析与选择osg2cesiumApp1.13是纯命令行操作没有图形界面。Windows下用cmd或PowerShellLinux下用终端进入工具所在目录后执行类似下面的命令osg2cesiumApp --input D:/project/Data --output D:/project/3dtiles --coords 116.3912,39.9072,0这只是最简用法实际项目中我会把参数配得更精细一些。下面列出常用参数及我的建议值参数作用我的建议--input输入osgb根目录路径指向包含metadata.xml的Data目录--output输出3dtiles目录路径建议新建空目录避免覆盖--coords模型原点经纬度坐标格式为经度,纬度,高程与metadata中记录一致--crs源数据坐标系统代码国内CGCS2000填4490WGS84填4326--maxLevel最大转换层级超出部分不处理默认转全部层级数据过大时可限制--textureCompress纹理压缩格式none/jpg/webp追求质量选none追求性能选jpg--thread并行处理线程数建议设为CPU物理核心数的12倍关于--coords这个参数它的本质是告诉转换工具“模型在真实世界中的位置”。三维模型本身只有相对坐标必须通过这个原点挂接到经纬度上。如果你的osgb的metadata里记录了中心点坐标直接用即可如果记录的是东北坐标ENU需要先换算成经纬度——这个换算可以用开源库proj或直接查大地坐标转换表。3.3 运行转换与结果验证参数确认无误后回车执行。以一块约10GB的倾斜数据为例我的配置是i7-12700、64G内存开启16线程整体耗时大约40分钟。期间终端会滚动输出当前处理到的瓦片编号、节点数量、纹理压缩情况基本能实时掌握进度。转换完成后检查输出目录。正常情况下应该看到tileset.json文件和一个Tile_开头的瓦片目录瓦片目录里是b3dm文件每个b3dm对应一个原本的osgb节点。验证成果是否可用我一般用两种方式一是用Cesium官方沙盒Cesium ion Sandcastle加载tileset.json链接看模型是否按预期位置和层级出现二是用离线工具如CesiumLab的快速预览功能。如果本地没有网络环境也可以写一个简单的HTML页面引用Cesium的CDN库直接加载本地服务器上的瓦片——注意必须启HTTP服务直接用file://协议访问会因跨域限制加载失败。我第一次转换时就把验证环节忽略了结果本地打开tileset.json能看到模型发给客户后却怎么也加载不出来绕了一圈才发现是客户没有把整个瓦片目录一起部署只上传了tileset.json。这里提醒所有人3dtiles是一个“目录级”成果发布时一定要打包整个输出目录而不是单独一个json。4. 常见问题与排查技巧实录4.1 坐标系与原点偏移问题这类问题在转换中出现的频率最高典型的故障现象是Cesium中加载模型后模型不在预期经纬度而是偏了几百米甚至几万公里。排查思路分三步走先确认--coords和--crs是否匹配。例如数据源是WGS84 UTM 50N投影但你在--crs里填了4326那坐标偏移就是必然的。正确做法是先查清楚源数据坐标系再用工具换算到经纬度填入--coords。其次检查metadata.xml中记录的原点坐标与--coords是否一致。有些osgb数据的metadata里记录的原点是生成时的局部原点而实际发布时你希望模型放到另一个位置这时必须以你的目标坐标为基准不要盲目照搬metadata。还有一个细节是高程基准。部分区域的DEM高程基于1985国家高程基准而Cesium用的是WGS84椭球高两者可能差几十米。如果对高程精度有要求建议在填写--coords时手动修正高程值或者转换后用Cesium的heightReference参数统一调整。4.2 纹理丢失与模型异常转换后如果模型整体呈灰色或白色检查纹理压缩参数。我的经验是如果源osgb里的纹理本身就是JPEG格式转jpg问题不大但如果是PNG带透明通道的纹理压缩成jpg会把透明通道丢掉导致建筑玻璃、广告牌等区域变成黑色块。这种情况改用--textureCompress none或者先预处理源模型把PNG纹理转成DDS/BC7格式再转换。另一种常见的纹理异常是“花屏”表现为模型表面出现细碎彩色噪点。这通常是纹理坐标精度不足或贴图分辨率在转换过程中被压缩得太狠造成的。opss2cesiumApp1.13默认会做纹理重采样如果源纹理分辨率是4096×4096压缩到512时细节必然丢失。建议把纹理压缩关掉none或至少保留原分辨率的50%以上。有一个坑值得单独说明部分osgb文件内部使用了“外置纹理引用”即osgb只存纹理路径并不真正包含贴图数据。这类文件在转换时极其容易出现纹理全丢的情况。我用过一个叫osgbconvert的开源小工具可以批量把外置纹理“烘焙”回osgb内部处理后再交给osg2cesiumApp成功率几乎100%。4.3 性能优化与修复大数据量转换时内存溢出是最常见的崩溃原因。osg2cesiumApp1.13虽然对内存做了优化但处理TB级数据时依然有压力。我的建议是不要一次性把所有瓦片都塞进转换队列而是按Tile块分批转换。比如把Data目录下Tile_0001~Tile_0010作为一个批次转完后接着下一批最后把多个批次的tileset.json手动合并——这个过程虽然繁琐但对内存和时间的利用效率高很多。另外如果你的最终目标是在Web端流畅展示建议转换时合理设置--maxLevel。倾斜摄影模型一般有十几级LOD但在浏览器端超过15米分辨率之后人眼基本分不清差别。把最大层级砍到10~12级瓦片数量可以减半加载速度明显提升。我经手的项目里用这种方式处理后3D Tiles的首次加载时间平均从30秒降到了8秒左右效果立竿见影。如果转换过程中途报“读取osgb失败”的错误优先检查文件是否被占用或损坏。用CC预览器加载一下源osgb如果能正常打开说明文件没问题可能是osg2cesiumApp的读取逻辑对某些特殊节点不支持如果连CC都打不开基本可以断定文件损坏需要回到建模软件重新导出那一块数据。最后再分享一个小技巧转换完成后用文本编辑器打开tileset.json看“geometricError”的值是否合理。如果相邻层级的geometricError比值过大超过3倍加载时可能出现层级跳变、画面忽闪的情况。这个问题可以通过手动调整geometricError值来改善——我一般把每层的值设为上一层的一半视觉过渡会平滑很多。本文还有配套的精品资源点击获取 从osgb到3dtiles：倾斜摄影模型Web化转换实战指南
简介这是一款用于将osgb格式数据转换为3DTiles格式的专用转换工具主要面向需要将倾斜摄影数据或BIM模型在Cesium平台上进行Web端展示的开发者、GIS工程师及测绘行业用户。工具仅支持64位操作系统在内存寻址与处理规模上更有优势能有效解决大规模三维场景在浏览器中加载缓慢、渲染卡顿的问题适合城市级倾斜模型和建筑信息模型的数据预处理。资源包共123个文件大小约8.35MB除主程序exe外还包含31个依赖dll、大量坐标与投影转换定义的csv/xsd/wkt文件以及少量xml、txt、svg等辅助文件可应对不同坐标系与地理参考场景的转换需求。目前已有426人学习下载。通过该工具用户能将osgb格式的倾斜摄影模型或BIM模型高效转为3DTiles并在Cesium中快速加载和交互展示适用于城市规划、建筑测绘、数字孪生等场景。工具内置了较完整的坐标系与投影支持对需要处理地理配准数据的用户尤其实用。1. 格式认知与转换思路1.1 osgb与3dtiles到底是什么很多刚接触倾斜摄影的同学第一次看到“.osgb”这个后缀时第一反应是“这是个什么格式用什么软件能打开”——说实话我第一次拿到航测数据时也懵了一下。osgb全称是OpenSceneGraph Binary它是OpenSceneGraph图形引擎定义的二进制二进制格式通常由ContextCapture简称CC原Smart3D、大疆智图、重建大师等建模软件生成。它的内部结构是一个树状的节点体系每个节点对应一个LOD层级和一块瓦片区域所有纹理贴图以二进制流内嵌在文件里所以单文件往往动辄几十兆甚至上百兆。而3dtiles是Cesium团队在2016年前后推出的开放格式标准专为海量三维数据的流式加载设计后来也成了OGC社区的事实标准。它的核心思路是把模型切成四叉树/八叉树的瓦片集合每一级瓦片有独立的gltf或b3dm文件配合tileset.json描述整棵树的索引关系。浏览器端的Cesium.js引擎拿到tileset.json后就能按视锥体裁剪、按距离调度瓦片从而实现“先粗后细、随看随载”的浏览体验。所以简单说osgb是建模软件的“私有产物”3dtiles是Web端三维地球的“通用语言”。二者之间没有直接互通的接口必须借助转换工具来处理。1.2 为什么要从osgb转到3dtiles如果只是在本机用CC自带的查看器浏览模型osgb完全够用甚至性能比3dtiles更好——毕竟它是原生格式读取路径最短。但一旦你想把倾斜模型发布到Web端让客户在浏览器里无需安装任何插件就能查看、量测、标注3dtiles就成了绕不开的选择。我经手过的几个项目都是这个套路无人机采集照片 → CC建模生成osgb → 转成3dtiles → 发布到Cesium或自研WebGIS平台。市政规划、违建巡查、地质灾害监测这些场景“能打开看”和“能在网页上随时查”是两个完全不同的交付标准。还有一个容易被忽视的原因3dtiles本身是开放的后续做单体化、落图、与BIM模型叠加都更方便而osgb的私有性限制了很多上层应用开发。2. osg2cesiumApp工具选型分析2.1 为什么选中这个命令行工具市面上osgb转3dtiles的工具不算多常见的有这几类一是用CC自带的“导出3dtiles”功能但CC的版本要求高、导出流程繁琐而且对电脑配置要求极高二是用CesiumLab它是图形界面操作适合新手但免费版有限制大模型处理需要付费授权三是用开源方案如py3dtiles、cesium-tiles等这些脚本存在一个共性问题——对osgb的多级LOD支持普遍不理想转换后经常出现破面、纹理丢失。osg2cesiumApp是GitHub上的一个开源命令行工具1.13是我一直在用的稳定版本。它直接读取osgb内部的节点结构逐层重写为3dtiles规范的组织形式不经过中间格式转换所以精度损失小、速度也快。我也试用过几个其他工具综合下来在“转换质量、处理效率、参数可控性”这三个维度它在我手里的项目里表现是最稳定的。2.2 1.13版本的主要特性1.13版本有几个值得注意的更新点。首先是支持了更多的坐标系统转换不只是WGS84经纬度像CGCS2000高斯投影、UTM分带都能配其次是纹理压缩选项可以选择不压缩、转成JPEG或WebP后两者能显著减小瓦片体积再有就是对大规模数据的断点续转支持处理到一半异常中断后重新运行命令可以直接跳过已完成的瓦片这个功能在应对几百G级别倾斜数据时能省下大量时间。不过要提醒一句这类开源工具对系统的依赖通常比较“挑剔”我分别试过Windows和Linux环境同一套数据在两个系统上的表现会有细微差异——Windows下内存占用略高但文件IO更稳定Linux下处理速度快一些不过需要手动处理一些动态库依赖。首次使用建议先用一小块数据做流程验证再上大规模正式数据。3. 实操完整转换流程3.1 环境准备与文件检查这一步看起来基础但很多人恰恰是因为数据前处理没做到位导致转换中途各种幺蛾子。拿到osgb数据后我一般先做三个检查。第一确认osgb文件目录结构。正常的CC导出结构是一个Data目录里面按Tile_编号分块每个编号目录下还有若干级子目录最终层级的文件夹里存放具体osgb文件。如果你的数据是分散的最好还原成这个结构再转换不还原也行但要记录好根目录路径。第二检查坐标系信息。CC导出osgb时通常会在同级目录附带一个metadata.xml文件里面记录了坐标系统、原点坐标、范围等信息。osg2cesiumApp1.13在转换时会读取这个文件来校准位置。如果你的数据是从其他渠道获取、没有metadata就必须自己准备坐标参数否则转换结果的位置会偏到不知哪里去。第三留意纹理贴图数量。有些建模软件导出的osgb把纹理拆成了多个jpg/png文件放在外部osgb里只是引用路径。osg2cesiumApp虽然内嵌了纹理打包功能但外部纹理的路径如果包含中文或空格Linux环境下很容易读取失败。如果遇到这类情况我建议先用云图管家或ModelLab这类软件把纹理重新打包进osgb再做转换。3.2 命令行参数解析与选择osg2cesiumApp1.13是纯命令行操作没有图形界面。Windows下用cmd或PowerShellLinux下用终端进入工具所在目录后执行类似下面的命令osg2cesiumApp --input D:/project/Data --output D:/project/3dtiles --coords 116.3912,39.9072,0这只是最简用法实际项目中我会把参数配得更精细一些。下面列出常用参数及我的建议值参数作用我的建议--input输入osgb根目录路径指向包含metadata.xml的Data目录--output输出3dtiles目录路径建议新建空目录避免覆盖--coords模型原点经纬度坐标格式为经度,纬度,高程与metadata中记录一致--crs源数据坐标系统代码国内CGCS2000填4490WGS84填4326--maxLevel最大转换层级超出部分不处理默认转全部层级数据过大时可限制--textureCompress纹理压缩格式none/jpg/webp追求质量选none追求性能选jpg--thread并行处理线程数建议设为CPU物理核心数的12倍关于--coords这个参数它的本质是告诉转换工具“模型在真实世界中的位置”。三维模型本身只有相对坐标必须通过这个原点挂接到经纬度上。如果你的osgb的metadata里记录了中心点坐标直接用即可如果记录的是东北坐标ENU需要先换算成经纬度——这个换算可以用开源库proj或直接查大地坐标转换表。3.3 运行转换与结果验证参数确认无误后回车执行。以一块约10GB的倾斜数据为例我的配置是i7-12700、64G内存开启16线程整体耗时大约40分钟。期间终端会滚动输出当前处理到的瓦片编号、节点数量、纹理压缩情况基本能实时掌握进度。转换完成后检查输出目录。正常情况下应该看到tileset.json文件和一个Tile_开头的瓦片目录瓦片目录里是b3dm文件每个b3dm对应一个原本的osgb节点。验证成果是否可用我一般用两种方式一是用Cesium官方沙盒Cesium ion Sandcastle加载tileset.json链接看模型是否按预期位置和层级出现二是用离线工具如CesiumLab的快速预览功能。如果本地没有网络环境也可以写一个简单的HTML页面引用Cesium的CDN库直接加载本地服务器上的瓦片——注意必须启HTTP服务直接用file://协议访问会因跨域限制加载失败。我第一次转换时就把验证环节忽略了结果本地打开tileset.json能看到模型发给客户后却怎么也加载不出来绕了一圈才发现是客户没有把整个瓦片目录一起部署只上传了tileset.json。这里提醒所有人3dtiles是一个“目录级”成果发布时一定要打包整个输出目录而不是单独一个json。4. 常见问题与排查技巧实录4.1 坐标系与原点偏移问题这类问题在转换中出现的频率最高典型的故障现象是Cesium中加载模型后模型不在预期经纬度而是偏了几百米甚至几万公里。排查思路分三步走先确认--coords和--crs是否匹配。例如数据源是WGS84 UTM 50N投影但你在--crs里填了4326那坐标偏移就是必然的。正确做法是先查清楚源数据坐标系再用工具换算到经纬度填入--coords。其次检查metadata.xml中记录的原点坐标与--coords是否一致。有些osgb数据的metadata里记录的原点是生成时的局部原点而实际发布时你希望模型放到另一个位置这时必须以你的目标坐标为基准不要盲目照搬metadata。还有一个细节是高程基准。部分区域的DEM高程基于1985国家高程基准而Cesium用的是WGS84椭球高两者可能差几十米。如果对高程精度有要求建议在填写--coords时手动修正高程值或者转换后用Cesium的heightReference参数统一调整。4.2 纹理丢失与模型异常转换后如果模型整体呈灰色或白色检查纹理压缩参数。我的经验是如果源osgb里的纹理本身就是JPEG格式转jpg问题不大但如果是PNG带透明通道的纹理压缩成jpg会把透明通道丢掉导致建筑玻璃、广告牌等区域变成黑色块。这种情况改用--textureCompress none或者先预处理源模型把PNG纹理转成DDS/BC7格式再转换。另一种常见的纹理异常是“花屏”表现为模型表面出现细碎彩色噪点。这通常是纹理坐标精度不足或贴图分辨率在转换过程中被压缩得太狠造成的。opss2cesiumApp1.13默认会做纹理重采样如果源纹理分辨率是4096×4096压缩到512时细节必然丢失。建议把纹理压缩关掉none或至少保留原分辨率的50%以上。有一个坑值得单独说明部分osgb文件内部使用了“外置纹理引用”即osgb只存纹理路径并不真正包含贴图数据。这类文件在转换时极其容易出现纹理全丢的情况。我用过一个叫osgbconvert的开源小工具可以批量把外置纹理“烘焙”回osgb内部处理后再交给osg2cesiumApp成功率几乎100%。4.3 性能优化与修复大数据量转换时内存溢出是最常见的崩溃原因。osg2cesiumApp1.13虽然对内存做了优化但处理TB级数据时依然有压力。我的建议是不要一次性把所有瓦片都塞进转换队列而是按Tile块分批转换。比如把Data目录下Tile_0001~Tile_0010作为一个批次转完后接着下一批最后把多个批次的tileset.json手动合并——这个过程虽然繁琐但对内存和时间的利用效率高很多。另外如果你的最终目标是在Web端流畅展示建议转换时合理设置--maxLevel。倾斜摄影模型一般有十几级LOD但在浏览器端超过15米分辨率之后人眼基本分不清差别。把最大层级砍到10~12级瓦片数量可以减半加载速度明显提升。我经手的项目里用这种方式处理后3D Tiles的首次加载时间平均从30秒降到了8秒左右效果立竿见影。如果转换过程中途报“读取osgb失败”的错误优先检查文件是否被占用或损坏。用CC预览器加载一下源osgb如果能正常打开说明文件没问题可能是osg2cesiumApp的读取逻辑对某些特殊节点不支持如果连CC都打不开基本可以断定文件损坏需要回到建模软件重新导出那一块数据。最后再分享一个小技巧转换完成后用文本编辑器打开tileset.json看“geometricError”的值是否合理。如果相邻层级的geometricError比值过大超过3倍加载时可能出现层级跳变、画面忽闪的情况。这个问题可以通过手动调整geometricError值来改善——我一般把每层的值设为上一层的一半视觉过渡会平滑很多。本文还有配套的精品资源点击获取