前不久,终于对osgb以及3dtiles的数据结构有了足够的了解,成功地利用FME将osgb数据转换成了3dtiles数据。于是,我开心地决定先来写一下如何将osgb转换成3dtiles数据。
为了让大家能够比较详细的了解这两个数据格式,该系列文章一共分为上下两篇,我将会从osgb与3dtiles的数据结构以及层级构建两个方面对其进行介绍。下篇仍在酝酿中,所以我们可以先将此篇作为单篇来看。
本篇文章,仅讲解osgb与3dtiles的数据结构,不会涉及到层级等等的介绍,但为了能够成功的看到我们最终转换出来的数据效果,因此我们仅挑选osgb中的一个层级进行转换,这样能有效地排除层级渲染的时候对数据最终效果的影响。
osgb数据与3dtiles数据粗讲
要想正确的对这两个数据进行转换,我们需要对这两个数据进行一些初步的了解。
首先什么是osgb数据?什么是3dtiles数据?他们两个数据之间有什么差异?
不知道大家有没有想过,为什么市面上能够找到osgb数据向3dtiles数据格式转换,却鲜有能够将3dtiles转换成osgb数据的?是否是这两个数据格式之间存在着很大的差异?
我也一头雾水,后来请教了一个3dtiles数据的大佬。
他跟我说:“理论上,3dtiles是可以转换成osgb数据的,不过成本很大。因为诸如osgb数据转3dtiles本质上是将对人类友好的对象型数据,裂解为对GPU友好的图形编程型数据;以3dtiles、gltf等格式的数据,是为了怎么渲染快怎么来,从来没有考虑过往回倒的余地。”
嗯,了然,就是说这类型数据就不是创建出来给人看的而是给计算机看的,可二次利用率很低。
好了,明白了这个道理,我就不再纠结回转了。
现在我们看一下,这两个数据的区别。
坐标转换
osgb数据,通常渲染在平面坐标场景上,其数据使用的是ENU坐标系。我更习惯叫它相对坐标,在其数据本身的坐标数值上,再加入坐标原点的值,即是正常的载体坐标(通常为2000平面坐标)。其坐标原点及坐标系定义存储在名为“metadata.xml”的xml文件内,长宽高单位为米。
而3dtiles数据格式,则是渲染在球面场景上,坐标常为wgs84经纬度坐标,(也可能为2000