3dTiles 数据规范详解[2] Tileset与Tile

转载请声明出处：全网@秋意正寒 http://www.javashuo.com/article/p-xugyfwqx-mh.html

1、一个简单的3dTiles数据示例

上图是一份 3dTiles数据集在文件夹内的样子，层层打开可得如下特色：

• 入口文件是 tileset.json
• 各级瓦片用文件夹（目录）来组织

3dTiles 数据目前的具体文件实现，是一些零散的文件。

数据集的名称与所在文件夹的名称并没有关系，数据集的名称写在入口文件中。

3dTiles至少有一个 tileset.json 文件，做为整个数据集的入口。它是一个 json 文件，描述了整个三维瓦片数据集，它记录的是上一节说起的“逻辑信息”，还包括一些其余的元数据。而“属性信息”、“嵌入的gltf模型” 则位于各个二进制瓦片文件中，这些二进制文件则由 tileset.json 中的瓦片中的 uri 来引用。

瓦片是什么？

瓦片，屋顶上的瓦片。古时候，盖房子，屋顶不能一次浇筑完工，也没有特定的“屋顶”零件，因此只好一片片瓦片盖上去（我瞎掰的）。

瓦片切割了三维数据，容许三维数据进行细分。咱们都知道网速是有限的，在加载超大规模的三维模型数据时，不可能把一个模型所有下载下来再渲染，那样等待的时间太慢了，可是一点一点出现，视野范围外的“瓦片”则干脆就不下载、渲染，性能、视觉都有提升。这就是瓦片的设计优势。

传统的二维地图瓦片，叫作 WMTS 或 TMS，这个 "T" 就是 Tile 的意思。

如今，你只要知道，3dTiles就是把空间进行切块，每一个块叫作 “tile”，也即瓦片。至于怎么切的——待会介绍 tileset.json 时，会隆重介绍树结构。

瓦片只有两种状况：叶子瓦片，非叶子瓦片。根瓦片也是非叶子瓦片。非叶子瓦片和叶子瓦片有什么区别呢？主要就是叶子瓦片不会再有孩子了（树结构的知识哈，不懂的建议去学习数据结构中的树）。

瓦片包含什么内容呢？本篇稍微靠后再仔细了解瓦片。

如今，咱们先认识一下，描述整个 3dTiles 数据集的入口文件，也叫作三维瓦片数据集 —— tileset.json：

2、Tileset——(三维)瓦片数据集

一般，一个三维瓦片数据集（以后简称：一个3dtiles数据）的入口就是那个”tileset.json“，至于这个文件的名称可不能够改，暂时未做测试。

如今，咱们先来研究研究 这个入口文件记录了哪些信息，拿一份最简单的 3dtiles数据来举例，该数据只有一个根瓦片（root），根瓦片再无子瓦片。

root对象中有一个content，内有uri属性，其就记录了根瓦片的二进制数据文件的URL，这个URL是个相对路径，相对于 tileset.json 文件。

① 顶级属性概览

经过上面介绍，3dTiles数据的入口文件是一个名叫 tileset.json 的文件，而一般来讲，这个json必须存在如下几个顶级对象：

• asset
• root
• geometricError

因为本人学识有限，目前不太清楚 geometricError 的精确含义，只知道这个数值的大小能控制 LOD 的显示隐藏，且这个数值父级瓦片必定比子级瓦片大。

asset 对象，记录了整个数据集的声明和归属数据，相似于数据声明，能在此写入 version、tilesetVersion 等属性，固然也能够像上方的例子同样，写入生成工具、gltf朝向等信息。

root 对象，即这个数据集的根瓦片，每一个3dTiles数据集必须有一个 root 对象。

至于 tileset.json 中其余的顶级对象，请查阅官方文档：点我

② root瓦片及其children

树结构对于三维空间数据的组织有很大的优点。3dTiles在空间上容许数据集使用以下几种树结构：

• 四叉树
• 八叉树
• KD树
• 格网结构

四叉树容许使用传统的均匀四叉树，也容许使用松散四叉树等变种（例如，容许子节点，即子瓦片容许存在空间范围重叠）。

上图为两个子瓦片在空间上存在部分重叠，照顾到了建筑物不可能严格切分的特色。

四叉树对在高度上不太好切分的数据比较适合，而若是追求极致的空间分割和分级（例如点云数据），那么八叉树更合适。

八叉树也容许使用各类变种。

kd树比较难理解，在此不做展开，这也是一种有趣的空间结构分割的数据结构。

格网结构的树容许瓦片存在多个子瓦片：

一般出如今倾斜摄影数据上，可是这会致使网络请求过多的问题。

③ 坐标系统

咱们能够用简单的两位数、三位数：经纬度，还有一个高度来标识地球表面附近的任何一个点。经纬度的范围不超过三位数，而用米做单位的空间直角坐标系来描绘地球，数字太大，很差记忆。

在GIS中，WGS84就是一个用经纬度来标识空间坐标的“地理坐标系，Geographic Coordinate System”。

因为历史上对地球测量的技术不一样，科学家制造了多个长半轴短半轴不太同样的“椭球”，来模拟地球的形状。目前，最具表明性的就是两个以地球质心为中心的椭球体：

• WGS84椭球体
• 中国国家2000椭球体（即CGCS2000）

基于椭球体，咱们容许有多种不一样的坐标系定义，WGS84坐标系其实并不太严谨。基于WGS84椭球（长短半轴等信息自行查询哈），可使用球面坐标度量，即经纬度，还有一个从质心射向椭球面上的点的“椭球高度”射线，来记录第三维高度数据。

介绍了那么多，3dTiles其实采用的是WGS84椭球，可是并未采用经纬度记录数据：由于相对于精细三维模型来讲，经纬度不足以提供足够精确的空间分割（要照顾图形显示问题）。因此，一样是那个形状，3dTiles使用了同一个WGS84椭球，可是更方便计算的坐标：空间直角坐标。

用经纬度记录数据的WGS84坐标系，WKID是4326，用地心为坐标原点的空间直角坐标来记录数据的坐标系，WKID是4979.

3dTiles 用的就是4979坐标系。

3、Tile——构成3dtiles的成员：瓦片

一般，瓦片对象会引用一个二进制的瓦片数据文件（也有例外，往下拉一点会说）：

在1.0 版本的规范中，瓦片所引用的二进制的瓦片数据文件，有四种类型：

类型	英文名称	文件后缀名
批量三维模型	Batch 3D Model	b3dm
实例三维模型	Instance 3D Model	i3dm
点云	PointCloud	pnts
复合模型	Component	cmpt

这些不一样的瓦片对应了些什么数据呢？本篇只贴一张各类数据类型的截图和信息对比表：

瓦片类型	对应实际数据
b3dm	传统三维建模数据、BIM数据、倾斜摄影数据
i3dm	一个模型屡次渲染的数据，灯塔、树木、椅子等
pnts	点云数据
cmpt	前三种数据的复合（容许一个cmpt文件内嵌多个其余类型的瓦片）

关于这些二进制瓦片数据文件的数据结构如何，下一篇开始会详细展开。

如今，咱们关注一下，瓦片对象的职能，也就是，它记录了啥信息：

这是一个children下的第一个瓦片，观察不可贵知，与root瓦片其实在属性上长得如出一辙。

瓦片对象都有以下属性：

• boundingVolume：空间范围框，容许有box、sphere、region三种范围框，可是只能定义一种
• geometricError：几何偏差
• content：瓦片内容，uri属性引用二进制瓦片数据文件。
• 其余属性：viewerRequestVolume、transform

没错，瓦片对象记录的就是瓦片的元数据，真正瓦片的本体数据在content所引用的二进制文件中。

瓦片还能够再引用 3dTiles 数据集！

我一再强调3dTiles十分灵活。

Tile不只仅能够在其uri属性中引用 诸如 .b3dm、.i3dm、.pnts等二进制瓦片数据文件，还能够再引用一个 3dTiles！

这是一份从osgb倾斜摄影数据转换而来的3dtiles数据，清晰可见在root瓦片的第一个child瓦片中，引用了另一个json文件。这证实了两件事：

• 3dTiles的文件名能够不是tileset.json
• 3dTiles容许套娃

原则上，只要被引用的子一级3dtiles 不循环引用父级3dtiles，那么就OK（规范如是说）。

它真的很灵活！

---

下一节将展现二进制瓦片文件中的相当重要的一部分：两大数据表。