Cesium的数据格式主要是3DTiles，3DTiles由tileset.json和tile组成，其中tile可以是.b3dm、.i3dm、.pnts、.vctr和.cmpt中的任一种格式文件。此外Cesium还支持其它3D格式，包括glTF、glb、Quantized-mesh（.terrain）等，支持其它数据向3DTiles格式的转换后加载，包括obj、BIM等。
- 3DTiles
3DTiles是一个抽象的数据定义，表现在其没有统一的数据格式，而仅仅是一种命名（也就是说Cesium中的数据到处都可以称为3DTiles格式，但到底什么是3DTiles格式呢？并没有统一的数据格式）。实际上它定义数据的基本框架是瓦片集，瓦片集包括瓦片集数据（tileset.json）和瓦片数据（tile），其中瓦片数据可以是多种文件类型，基本结构如图1.1所示。瓦片集数据是对整个瓦片集的说明以及瓦片的空间组织结构的存储，瓦片数据负责存储单个瓦片内的所有三维地理信息数据，包括模型数据、属性数据等。
图1.1 3DTiles数据基本逻辑框架
3DTiles的瓦片数据有多种：b3dm(Batched 3D Modal，批量3D模型)、i3dm（Instanced 3D Modal，实例3D模型）、pnts（Point Cloud，点云）、vctr（Vector Data，矢量数据）和cmpt（Composite，复合数据）。
- b3dm
b3dm瓦片可以用于存储带纹理的地形表面、三维建筑物的外部和内部（BIM数据）、大量的三维模型数据等。
b3dm的数据结构如图1.2所示，其基本文件结构是文件头部加主体。文件头部记录了文件类型、版本、大小等基本信息，同时也记录了要素表、批量表的大小。主体部分首先是要素表与批量表，然后是存储模型的glb文件。要素表存储要素的元数据（要素个数），批量表存储具体属性（要素id等），要素表与批量表可以采用JSON文本或二进制，没有强制要求。glb文件被内嵌到b3dm文件中，其中使用的几何数据和图片资源可以集成到glb也可以采用外部引用形式。b3dm是3DTiles中用途最多、使用最频繁的瓦片数据种类。
图1.2 b3dm瓦片文件数据结构
- i3dm
i3dm瓦片也存储glb的模型，但是i3dm瓦片强调物体的可复制性。这说明i3dm的模型只用于表达一个对象，通过指定位置该模型对象可以在多个位置出现。官方建议，i3dm可以用于存储大尺度上的树木、风车、消防栓、井盖、路灯、交通信号灯等物体，也可以用于存储小尺度上的螺丝钉、阀门、插座等物体。i3dm体现的是要素的相同性、这种相同性不仅表现在要素的种类也表现在具体的内容，i3dm从很大程度上减少了数据冗余度，这也刚好诠释了i3dm对于“实例”的定义。i3dm文件的基本结构与b3dm类似，如图1.3所示，文件头部仅仅多了对引用glb文件的描述（url或内嵌二进制glTF）。
i3dm与b3dm的差别主要在要素表部分，i3dm的要素表除了实例的个数还需要存储实例出现的位置以及方位，通过位置坐标与方向参数确定实例模型在三维椭球上的渲染位置与姿态。此外，i3dm也提供了在局部地表的东北上坐标框架，当设置这种坐标框架开启时可以不用设置模型方位参数，而改由Cesium运行环境计算所需参数。
图1.3 i3dm瓦片文件数据结构
- pnts
pnts瓦片存储点云数据。
- vctr
vctr瓦片存储矢量数据。
- cmpt
cmpt瓦片将多种不同种类的瓦片合并到一个瓦片中。异质瓦片的合并为3DTiles数据的组织方式提供了更多的实现方案，但是一般很少把不同种类的瓦片放在一起。cmpt最常用的一个用法是将存储不同数据的i3dm瓦片合并到cmpt中，例如将存储树木、路灯的i3dm瓦片包装到cmpt中，达到减少区域瓦片种类的目的。但是，通常的做法是采用瓦片集引用瓦片集，将多种应用数据纳入统一的3DTiles数据框架中。
- Cesium支持的文件格式
Cesium支持的可以直接加载的通用文件格式有.glTF、.glb、.terrain（Quantized-mesh）文件。
- . glTF格式
glTF（GL Transmission Format， GL传输格式）。glTF的全称是GL传输格式，是一种针对GL(WebGL，OpenGL ES以及OpenGL)接口的运行时资产(asset)。在3D内容的传输和加载中，glTF通过提供一种高效，易扩展，可协作的格式，填补了3D建模工具和现代GL应用之间的空白。
glTF1.0和glTF2.0文件结构如下图所示。图2.1描述的是glTF1.0的一个大概结构，分为四大块：最上面的json是一个描述整个三维场景结构与数据配置结构的JSON文本，描述该模型的节点层级，材质，相机，动画等相关逻辑结构；bin则对应这些对象的具体数据信息，包括几何体的基本数据（例如顶点、外法向量、纹理坐标、动画数据等）；glsl是对该模型渲染的着色器，用于存储渲染模型需要的着色器源代码，针对模型的数据信息，给出渲染“配方”；纹理部分存储glTF文件使用的纹理图片（png和jpg）。大块内容可以以Base64的编码内迁到文件中，方便拷贝和加载，也可以以URI的外链方式，侧重重用性。
图2.1 glTF1.0文件结构
图2.2 glTF2.0文件结构
- .glb格式
.glb格式是Khronos工作组对glTF定义的二进制文件扩展，本身是一个二进制文件格式，实现三维模型存储于GL的可传输的格式(glTF). 内含节点层级、摄像机、材质、动画、网格物体都用二进制存储。这个二进制格式存储glTF的组件(JSON，.bin 以及图片) ，同时也避免了用glTF格式文件变大的问题，通过压缩，glb能更快地加载，提供完整的三维场景，且是能在未来的开发中扩展的。该格式使用model/gltf-二进制文件作为MIME类型。
glb作为一个容器，用二进制格式实现glTF的内容，并规避了glTF的一些缺陷。其目的是为了消除glTF文件集中式组织形式中编码文本存储数据容量大和加载时需要额外的解压过程，当数据量过大时使用效果差的问题，而定义的一种文件格式。
glb格式包含20个字节的头文件，然后是glTF文件的JSON部分，最后跟随二进制数据或者在content的JSON中外部引用数据文件。
图2.3 glb文件数据结构
- Quantized-mesh（.terrain格式文件）
Quantized-mesh格式的地形图瓦片的切分规则和HeightMap的一样，也是Tile Map Service (TMS) 的global-geodetic规则，详情可见cesium地形瓦片(HeightMap)格式中的描述。
高度图（HeightMap）实际上就是一个2维数组，用来存储地形网格的坐标（x，y）和高度（z）。把地形看做一系列高度不同的网格，数组中每个元 素的索引值刚好可以用来定位不用的网格（x,y），而所储存的值就是网格的高度（z）。
地形瓦片(HeightMap -1.0)格式的terrain瓦片集是根据TMS（瓦片地图服务）global-geodetic（全球大地坐标）规则进行切分。
heightmap 1.0 特定规则：（1）所有图块都具有后缀名.terrain。（2）图块大小为65x65像素大小，实际上图块的最后一行和最后一列是相邻的东边/南边图块的第一行/第一列。因为其大小不是256x256，所以其对应级别的分辨率也有所不同。
可以使用开源软件 Cesium Terrain Builder 来对DEM数据切片，生成terrain瓦片。对于TerrainTile的数据结构，可以查看代码TerrainTile.hpp、TerrainTile.cpp，很清晰明了。对于单个图块，为65x65大小，每个像素表示一个高度值，海拔值的计算规则为H=像素值*0.2-1000。每个高度值为16Bit的整数，排列顺序为行-从西向东，列-从北向南，总的字节数为65*65*2=8450。相邻图块直接关系大致如下图所示，相邻瓦片之间有一行或者一列的重合。
- 其它相关3D数据介绍
- .osgb格式文件
osgb是倾斜摄影数据格式。倾斜摄影测量技术的数据源是高分辨率的卫星倾斜遥感影像或者近地无人机倾斜影像以及卫星或者无人机的位置和姿态参数。通过这些数据进行空中三角测量解算与同名像素匹配从而计算出模型顶点位置坐标并进行模型重建。倾斜摄影测量的数据成果目前主要以作为倾斜摄影行业标准的osgb格式存储，并且osgb格式自包含LoD(Level of Detail，细节层次)。从osgb到3DTiles的转换己经有开发完成的工具OSGTo3DTiles，由于使用说明不够充分等原因，转换出错时不容易排查故障，所以该工具还需要完善。
倾斜摄影测量是通过倾斜影像进行像素坐标匹配生成的模型，所以数据上有一个很明显的特点：地物与地面连成一体，也就是说倾斜摄影生成的数据只是一层表皮。这种数据对信息的采集简单粗暴，数据（尤其是纹理）的重复利用率比较低，冗余度高。这个特点决定了倾斜摄影测量数据在不经过其他处理或者其他数据辅助是没有办法实现要素化的。生产过程上倾斜摄影的自动化程度很高，例如航空器、飞行器搭载倾斜相机拍摄倾斜影像，内业过程由软件自动化完成，基本不需要人进行细节干预。生产的数据是行业标准格式osgb，自身带有LoD。另外，小型无人机倾斜摄影建模也发展成熟起来，生产成本更加低廉。由于生产自动化、成本低廉、标准明确，所以倾斜摄影测量技术越来越受用户欢迎。
- .obj格式文件
obj文件是3D模型文件格式。由Alias|Wavefront公司为3D建模和动画软件"Advanced Visualizer"开发的一种标准，适合用于3D软件模型之间的互导。也可以通过Maya读写。比如Smart3D里面生成的模型需要修饰，可以输出OBJ格式，之后就可以导入到3dsMax进行处理；或者在3dsMax中建了一个模型，想把它调到Maya里面渲染或动画，导出OBJ文件就是一种很好的选择。OBJ文件一般包括三个子文件，分别是.obj、.mtl、.jpg，除了模型文件，还需要.jpg纹理文件，目前几乎所有知名的3D软件都支持OBJ文件的读写。OBJ文件是一种文本文件具体课参考obj文件。
- .dae格式文件
DAE（Digital Asset Exchange）文件格式是3D交互文件格式，一般用于多个图形程序之间交换数字数据，DAE是一种3D模型，可被flash 导入。3Dmax与maya需要安装dae输出插件才可以打开，输出成后缀为dae的文件。谷歌地球的模型就是DAE。DAE文件是COLLADA的模型文件COLLADA定义了XML命名空间和数据库模式，以便在不丢失信息的情况下轻松地在应用程序之间传输3D资产，从而将各种3D创作和处理工具组合到内容生成管道中。COLLADA不是作为游戏引擎格式设计的; 它被设计为内容管道中所有工具的中间格式，例如DCC工具和调节器。
DAE 是纯文本的模型格式，其本质就是一个单纯的xml文件。相比fbx，对dae格式模型的载入我们拥有非常高的自由控制，这也是最复杂的地方。基本上，dae文件内一开始就把数据分成了好几大块。对我们来说最为有用的是VisualScenes(包含场景骨骼节点树)、Nodes(与VisualScenes类似，两者或互为补充)、Geometries（网格数据）、Materials/Effects/Images（材质相关信息）、Controllers（骨骼信息数据）、Animations（动画数据）、AnimationClips（全局的动画信息），其中静态模型一般也就包括VisualScenes和Geometries。
本文参考文献
扫一扫
1919
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
