简介这是一份倾斜摄影OSGB格式的三维地理空间数据包以武汉某景点的多角度航拍建模成果为实例适合测绘、GIS、城市规划及相关专业学生与从业者用于学习倾斜摄影数据组织与OSGB格式的典型应用方式。压缩包共267个文件容量27.64MB包含265个osgb分块模型文件、1个s3c场景索引文件及1个xml配置文件便于观察数据层级结构、模型调度逻辑与工程组织方式。目前已有3291人学习下载。通过解压并浏览数据可以直观理解倾斜摄影从多视角影像采集、空三解算、点云生成、表面建模到OSGB瓦片化输出的完整流程也能在支持OSGB的软件中查看L19、L20、L23等层级细节并尝试导入GIS或三维建模工具进行场景漫游、量测与分析是入门实景三维建模和三维GIS的良好素材。 做三维实景和测绘项目的人八成都有过这样的经历成果交出去的时候对方张口就要“osgb文件”甚至以为它就是单个文件。等你发过去一个几百GB的文件夹对方直接懵了。其实倾斜摄影数据的osgb格式本质是一套分层分块的瓦片组织方案而不是一个可以随意拷贝的孤立文件。今天就把这套格式的来龙去脉、使用要点和踩坑记录完整梳理一遍希望能帮到正在被OSGB折磨的同行也顺便给刚入行的人省点摸索时间。1. 为什么OSGB能成为倾斜摄影事实上的交付格式1.1 OSGB不是格式而是一套瓦片与LOD的组织规则很多人以为OSGB是一种类似OBJ的“模型文件格式”拿到一个.osgb文件就算拿到模型了。这个理解在数据量小的时候凑合能用放在真实倾斜摄影项目里就完全行不通。倾斜摄影数据通常是按“瓦片金字塔”生产的。空三解算、密集匹配、TIN构网和纹理映射完成后生产软件会把整个测区切成很多个矩形区块每个区块再按层级继续细分。每一层、每一块都保存成一个独立的OSGB瓦片文件瓦片里既包含三角网几何信息又包含纹理坐标和对应的纹理图片同时每个父级瓦片会保留一个低精度的简化模型和子瓦片的包围盒信息供渲染调度时使用。OSGB本质上脱胎于OpenSceneGraph场景图后缀是OpenSceneGraph Binary的缩写。它不像OBJ那样是纯文本而是二进制序列化的场景图节点。好处很明显读取速度快、文件体积小、支持外部纹理和内嵌纹理两种方式更重要的是天然支持LOD换级。也就是说相机在远处看到的是粗糙的大瓦片拉近后才自动加载精细子瓦片这套机制让超大场景在普通显卡上也能跑得动。1.2 与OBJ、FBX相比OSGB解决的是“大场景能不能跑起来”的问题做过实景项目的人应该都有印象用ContextCapture或Metashape把模型导成OBJ一个县城级别测区轻轻松松几百GBOBJ文件打开半天不响应导入建模软件后更是直接卡死。为什么因为OBJ/FBX是“单文件全量模型”思路所有三角面堆在一起没有空间索引也没有分层分级显卡和内存必须一次性吃下全部数据。OSGB完全不同。生产软件输出OSGB时会把测区按照固定大小切成几百上千个瓦片目录每个目录只保存局部模型。配合osgEarth这类渲染引擎它只加载视锥体内可见的瓦片任何时刻内存里都只有一小部分模型数据。这个思路和Web地图的切片加载是一样的只是把二维影像换成了三维几何。另外OSGB在生产端几乎是无缝衔接的。ContextCapture、Smart3D、Metashape、大疆智驾这些主流重建软件默认都能输出OSGB互相之间通过S3C索引或目录结构就能识别。对于测绘和GIS行业来说能直接进入EPS、DP-Modeler等修模软件能在Skyline、SuperMap、Cesium中加载这已经成了事实上的行业标准交换格式。2. 拿到OSGB数据的第一次体检目录结构里藏着的全部秘密2.1 先从Metadata.xml读出坐标系、原点与纹理参数拿到一批OSGB成果不要急着双击模型文件看效果。第一步应该是打开数据根目录找到metadata.xml。这个文件记录了整批数据最关键的元信息包括坐标系、原点、纹理质量、瓦片生产软件版本等。以ContextCapture为例常见的目录结构大致是这样Data/ metadata.xml S3C/ Tile_000_005/ Tile_000_005.osgb Tile_000_005/ Tile_000_005.osgb Tile_000_005.osgb ... Tile_001_005/ ... ...metadata.xml里通常能看到类似这样的内容ModelMetadata version1.1 SRSPROJCS[China Geodetic Coordinate System 2000 / 3-degree Gauss-Kruger zone 38, ...]/SRS SRSOriginfalse,false/SRSOrigin TextureQuality95/TextureQuality TextureMaxSize4096/TextureMaxSize VertexColorfalse/VertexColor ProductionVersion.../ProductionVersion /ModelMetadataSRS字段非常重要。它告诉你这批数据用的是国家2000坐标系还是WGS84投影方式是经纬度还是高斯投影中央经线是哪一度带。这些信息直接决定了后续坐标转换怎么做。很多项目拿到数据后不读这个文件直接塞进游戏引擎结果模型位置完全对不上就是坐标系没搞明白。2.2 怎么判断这套瓦片金字塔建得是否健康除了元数据还要检查瓦片目录的完整性和LOD层级是否正常。健康的OSGB数据应该具备几个特征第一每个区块的目录结构是对称的不会出现某个区块有三级子瓦片、另一个区块一级都没有的情况第二瓦片文件大小呈金字塔分布父级瓦片相对小子级瓦片数量多但单个文件不大第三纹理文件与.osgb文件成对出现并且没有零碎的孤立纹理。比较快捷的检查方式是用osgviewer或市面上的数据查看器打开整个Data目录然后从高空向低空逐级拉近视角。如果拉近到一个区域时模型突然消失或者远处的粗模和近处的细模之间有明显跳变基本说明LOD生成有问题或者是生产时个别瓦片没有计算成功。更隐蔽的问题在纹理上。打开瓦片目录看一眼如果发现大量纹理文件的大小只有几十字节那就要警惕蒸烤机或生产端出过差错这时候直接在软件里叠加显示问题区域会出现一片片灰模或黑斑。实际项目中我还会额外检查一下总瓦片数量和占用的磁盘空间是否与生产报告对得上。曾经有一个项目交接时少拷了第二级子目录结果用osgEarth加载时整个测区只有稀稀拉拉几栋楼其他全是平地排查了很久才发现是数据拷贝时漏了文件夹。3. 把OSGB接进三维平台前先解决的原点与坐标系问题3.1 为什么地图上好好的模型进了引擎就疯狂抖动OSGB在专业GIS软件里显示正常但一导入Unreal、Unity这类游戏引擎模型就开始闪烁、抖动、顶点位置偏移甚至整个模型在视野边缘被裁剪掉。这个问题几乎每个Unity或UE开发者都会遇到根子在于浮点精度和原点设置。倾斜摄影数据动辄覆盖几个平方公里模型坐标为很长的投影坐标数值比如X500000多Y3400000多。游戏引擎用单精度浮点存储坐标时数值越大有效小数位就越少。场景离世界原点越远顶点位置的计算误差就越明显导致三角形顶点位置上抖动、纹理出现高频闪烁。处理思路通常有两种。一种是先做坐标平移把测区中心的坐标值减掉将模型挪到引擎世界原点附近然后在场景里维护一个“真实坐标偏移量”用逻辑坐标管理空间关系。另一种是直接用局部坐标系重新生成OSGB也就是俗称的“东北天坐标系”或“自定义原点投影”生产软件会把所有瓦片坐标平移到测区中心附近这样进入引擎后数值就小了。这里需要特别强调如果不打算做后续坐标还原千万别轻易动原始数据导出的新坐标要重新生成Metadata否则下次别人拿到这批数据会对不上。3.2 从OSGB到3D Tiles/glTF的常用转换路线OSGB虽然专业但Web端不直接吃这一套。要让浏览器里的Cesium加载必须转成3D Tiles要让Unity/UE读取经常也要先转成glTF或FBX。转换工具有很多但每一步都有坑。我用得比较多的一条路线是CesiumLab的OSGB转3D Tiles。转换时要注意几个参数数据坐标系是否选对纹理格式是否保留是否开启Draco压缩以及LOD抽稀级别。CesiumLab会读取你选中的Data目录按切片金字塔重新组织成Tileset.json加b3dm文件。如果原始OSGB坐标是高斯投影下的CGCS2000在Cesium里需要模型坐标系和场景坐标系保持一致否则会出现在地球上对不齐、旋转错位的问题。另一条路线是用osgconv把OSGB转成glTF/OBJ。osgconv是OSG自带的命令行工具转小区域没问题但一整个测区直接转还是会把所有瓦片压成一个大文件性能立刻崩盘。所以建议先保留OSGB做专业协作只把需要放到引擎展示的局部区域单独导出。转换完成后最好用相关引擎的资产查看器检查一次法线方向和纹理UVOSGB的坐标系是Y轴向上的转换到Z轴向上的引擎里时模型旋转关系很容易搞反纹理也会跟着翻转。4. OSGB模型常见的花脸、破洞、悬浮物排查实录4.1 玻璃幕墙、水面和树冠空洞扎堆的重灾区倾斜摄影的建模算法对“没有纹理特征”的表面几乎束手无策。玻璃幕墙是典型的反光表面太阳一照不同角度的影像反射的内容完全不一样空三匹配点会大量丢失最后模型表面就出现大面积拉花甚至破洞。水面也一样尤其是有波纹的河流、平静的湖面算法找不到稳定的同名点生成结果要么是一块平整的黑色几何要么直接镂空。处理这类问题靠后期修模软件是常用的办法。像DP-Modeler、模方这些工具专门针对OSGB模型做单体化修补、压平、补洞和纹理重映射。实际操作时先用软件选中破洞区域周边的白模一键补洞生成基础几何再把多视角影像投影到新几何上生成纹理。对于水面通常的做法是把水面区域压平到一个高程然后手动赋予一张水面纹理相当于用“P图”的思路把模型修正。树冠区域的问题又不一样。风吹时树冠来回晃动多张影像里树木的位置不一致重建出来的树冠就像被揉烂的棉花还有很多飞散的碎片点。解决这个问题没有什么捷径只能在预处理环节先做点云分类把植被点去掉或单独标记再进行构网和贴图。生产中想完全自动处理不太现实关键区域还得人工修。4.2 纹理发黑、接边色差、悬浮物从成因到处置纹理发黑是我遇到最多的问题之一。如果模型在靠近看时正常拉远之后逐渐发黑发暗多半是纹理贴图的mipmap和色彩空间设置问题不同渲染引擎对sRGB的处理不太一样。如果是局部瓦片发黑那就是对应影像参与映射时曝光不足或是该瓦片的UV采样出现错误。解决办法是回到生产软件里重新输出该区域而不是在渲染器里硬调。接边色差主要是航飞时不同架次曝光不同造成的。倾斜摄影常常是分区域飞行的不同时间的太阳高度角、云层遮挡都会影响影像亮度导致相邻瓦片之间一深一浅整个模型看起来像打了补丁。治理办法是在建模软件里做色彩平衡和匀色处理或者后期用修模软件统一色调。这里我建议在完成重建后、输出OSGB前就检查等导出来再做匀色效率会低很多。悬浮物和地底冗余则属于数据洁癖问题。低空无人机在密集人流或车流区域飞行时移动目标会被重建出半透明鬼影树木边缘和建筑物裙楼底部经常会有飘在空中的碎片几何。面对这种数据能做的就是做点云分类、手动选择删除噪声点然后重新构网。做城市级项目时如果屋顶或地面以下有大量冗余三角网会白白增加渲染负担可以导出数据后在修模软件里做一次整体裁剪不要偷懒。5. 交付归档与选型建议OSGB数据的最终归宿5.1 什么时候继续用OSGB什么时候必须转3D TilesOSGB和3D Tiles不是互斥的关系而是用在不同的场景。如果项目是给测绘、自然资源、城市管理部门做三维基础数据平台桌面端、内网、专业软件环境比较多那就保持OSGB交付兼容性最好。如果项目是要做成Web端的数字孪生、园区大屏、智慧城市看板那必须转3D Tiles否则浏览器加载不动。从转换成本看如果原始数据是ContextCapture生产的建议在生产阶段直接同时输出一份OSGB和一份3D Tiles不要事后二次转换。有朋友问为什么不在生产时直接出3D Tiles其实ContextCapture支持直接输出3D Tiles但很多作业员还是习惯用OSGB做修模、质检和归档所以两种格式都出比较稳妥。如果手里只有OSGB又急着上Web可以用CesiumLab或开源的3d-tiles-tools做转换但要预先做好坐标、LOD等级和纹理压缩的规划转完至少要抽检5个以上瓦片不要看全貌没事就交付。5.2 归档清单与交付规范写给所有被甲方追着要数据的人关于OSGB数据的交付我自己踩过一次大坑之后定了两条规矩第一不手动改瓦片文件和纹理文件名第二归档时必须附带一份数据说明文件。有一次为了省空间我把一批瓦片里重复的纹理图片去重后单独放了一个文件夹结果整个模型拉远之后全部变成白模。原因是OSGB的纹理路径是生产软件内部写死的我动了路径和文件名渲染器就找不到贴图了。从那以后我只在生产软件里重新导出绝不对瓦片做手动文件操作。交付时一个标准的清单大概是OSGB瓦片目录Data/完整拷贝metadata.xml坐标系说明文件EPSG编号、投影参数、中央经线测区范围KML或SHP生产报告包括空三精度、控制点精度、数据分辨率、采集日期成果预览截图与加载说明文档。很多项目拿到OSGB后最大的问题不是数据本身而是说明文档缺失。坐标系是什么、原点在哪里、单位是米还是度不写清楚的话下游工作人员只能靠猜猜错一次就是几个小时甚至一天的返工。5.3 一点选型心得别被“格式万能论”带偏我见过不少团队迷信所谓“通用格式”总想把所有数据统一成一种结果转换过程里精度丢了、LOD没了、纹理乱了。其实OSGB格式是否合适取决于你的生产链路和交付目标。专业GIS、修模、测绘成果归档直接用OSGBWeb数字孪生转3D Tiles游戏级可视化再考虑glTF/FBX和轻量化减面。最关键的一点是无论选择什么格式都要保留一套原始工程文件。OSGB是成果不是母本真正的母本是空三工程、影像集和连接点。等到后续做单体化、做属性挂接、做模型更新的时候只有回到母本里才能真正改得动。数据更新迭代时我也只信同一套生产软件重新出而不是拿旧OSGB硬修这个习惯给我省了太多麻烦。最后再分享一个小技巧拿到新的OSGB数据后先在资源管理器里看一眼顶层目录下的瓦片块数量再用Meter或相关专业软件加载一次把加载时间和显存占用记录下来。这批数据以后每次迭代对比只要发现性能指标明显变差十有八九是LOD层级或纹理上限设置被改动过。数据资产管理这件事越早建立记录后面省的事就越多。本文还有配套的精品资源点击获取