工具+详解+版权所属@四季留歌
官方源码schema

一、glTF

详见这里。

二、3DTiles

1.3dTiles的特点

• 三维模型使用了 glTF 规范，继承它的渲染高性能。
• 3DTiles由tileset.json和tile组成，其中tile可以是.b3dm、.i3dm、.pnts、.vctr和.cmpt中的任一种格式文件。
• 除了嵌入的 glTF，3dTiles 自己 只记录各级Tile的空间逻辑关系（如何构成整个3dtiles）和属性信息，以及模型与属性如何挂接在一起的信息，不记录模型数据。

模型数据：三维模型的顶点、贴图材质、法线、颜色等信息。
逻辑关系：各级Tile是如何在空间中保持连续的，LOD是如何组织的。

2.一个简单的3dTiles数据示例

• 入口文件是 tileset.json，描述了整个三维瓦片数据集，记录“逻辑信息”，还包括一些其他的元数据。
• 各级瓦片用文件夹（目录）来组织，“属性信息”、“嵌入的gltf模型” 则位于各个二进制瓦片文件中，这些二进制文件则由 tileset.json 中的瓦片中的 uri 来引用。
  

• 数据集的名称与所在文件夹的名称并无关系，数据集的名称写在入口文件中。
• 瓦片只有两种情况：叶子瓦片(无子节点)，非叶子瓦片。

3.Tileset——(三维)瓦片数据集——.json

• 通常，一个三维瓦片数据集（之后简称：一个3dtiles数据）的入口就是那个tileset.json。

顶级属性概览(必需)：asset、root、geometricError

而通常来说，这个json必须存在以下几个顶级对象：

• asset：有关整个tileset的元数据，应用于特定程序的数据有glTF版本号，生成工具等。
• root：3D Tiles tileset中的根切片。
• geometricError：几何误差，表示简化后的切片/瓦片(tile)与原始几何图形的差异（米为单位）。

• 这个数值的大小能控制 LOD 的显示隐藏，且这个数值父级瓦片一定比子级瓦片大。
• tile的几何误差代表了该切片的选择指标，是一个非负值。
• 根tile是源几何体的最简化版本，将具有最大的几何误差，然后每个连续级别的子级别将具有比其父级更低的几何误差，其中叶子具有接近0的几何误差。
• 较高的几何误差意味着切片重新定义为更加细化的切片。
• Screen-Space Error(SSE),屏幕空间误差：如果渲染tile和其子节点没有内容，则会引入tile的源几何图形与简化后的图形之间的差异（以像素为单位）。

其他属性root、children、refine、content、boundingVolume

children

定义子切片的对象数组。
每个子切片内容都由其父切片的边界范围框完全包围，并且通常具有小于其父切片的几何误差。
对于叶子切片，此数组长度为零，并且可能未定义子切片。

3dTiles在空间上允许数据集使用如下几种树结构：

• 四叉树：适合高度上不太好切分的数据

• 八叉树：追求极致的空间分割和分级（例如点云数据）
  

• KD树

• 格网结构
  
  例如上面的children下有17个子节点，每个节点对应一个uri，与下面中的17个文件一一对应：
  

refine 细化

确定在选择较低分辨率的父平铺进行渲染时，该父平铺的渲染过程。
允许的优化类型有：

• 替换 （“REPLACE”），则子图块将代替父图块进行渲染，即不再呈现父图块。
  

• 附加 （“ADD”），除了父平铺之外，还会渲染子平铺。
  

省略时，继承父级切片的。

bounding volumes 边界范围框

每个子切片内容都由其父切片的边界范围框完全包围。
包含切片或其内容的边界框，只需要一个box、region或sphere。

• box —— number[12]
  
  
  
• region —— number[6]
  
• sphere —— number[4]
  
  

content

有关切片内容的元数据和指向内容的链接

viewer request volume 视图请求范围框

Tile——构成3dtiles的成员：瓦片/切片——.json

• tile是tileset的子集，所以一般也是.json后缀，里面包含可渲染内容的引用（即切片内容，如用uri）和元数据（如内容的边界范围框boundingVolume）。

tile content 切片内容

• 通常，瓦片对象会引用一个二进制的瓦片数据文件（也有例外），是渲染所需的二进制信息：
  
  

tile format 切片格式

有两大数据表：要素表/特征表Feature Table和批处理表Batch Table

tile info 切片信息

从瓦片内容可知，瓦片对象都有如下属性：

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

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

• 其他属性：viewerRequestVolume、transform

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

4.数据与模型

• 3DTiles由tileset.json和tile组成，其中tile可以是.b3dm、.i3dm、.pnts、.vctr和.cmpt中的任一种格式文件。
• 除了嵌入的 glTF，3dTiles 自己 只记录各级Tile的空间逻辑关系（如何构成整个3dtiles）和属性信息，以及模型与属性如何挂接在一起的信息，不记录模型数据。

模型数据：三维模型的顶点、贴图材质、法线、颜色等信息，由gltf承担起来的（作为glb格式嵌入到瓦片二进制文件中）。
逻辑关系：各级Tile是如何在空间中保持连续的，LOD是如何组织的。

所以，“属性数据” 和 “模型” 是如何产生联系的呢？
使用了两个重要的表来记录这种 “模型与属性” 的联系：

• FeatureTable（要素表）
• BatchTable（批量表）

要素表、批量表都是以 二进制 形式存储。

tile瓦片二进制数据文件的大致字节布局结构(b3dm、i3dm、pnts)

除去cmpt这个复合类型不谈，前三种的大致布局见下图：

每一种瓦片二进制数据文件都有一个记录该瓦片的文件头信息，文件头包括若干个因瓦片不同而不太一致的数据信息。

• 当fileHead含有要素表时，fileHead还将包含featureTableJSONByteLength和featureTableBinaryByteLength uint32，用于提取功能表的每个相应部分。
• 当fileHead含有批次表时，fileHead还将包含batchTableJSONByteLength和batchTableBinaryByteLength uint32，用于提取功能表的每个相应部分。

FeatureTable，要素表 —— 记录渲染相关的数据

• 即描述了要素每个要素的位置和外观属性。
• 例如b3dm,每一个模型都是一个要素；例如pnts，每个点都是一个要素。

要素表的结构

• 填充：

• JSON头必须以包含的tile二进制文件中的8字节边界结束，必须使用后继空格字符0x20填充JSON头以满足字节对齐。
• 二进制body必须以包含的tile二进制文件中的8字节边界开始与结束，必须使用任何值的附加字节填充二进制体，以满足此要求。
• 二进制属性必须以字节偏移量开始，该字节偏移量是属性componentType的字节大小的倍数（参考glTF）。

• JSON头：
  
  
• 二进制体：
  

BatchTable，批次表 —— 记录属性数据

• 如果把批次表删掉，那么 3DTiles 数据还能正常渲染。
• 批次表就是所谓的模型属性表，批次表中每个属性数组的个数，就等于模型的个数，因为有多少个模型就对应多少个属性。

其实也有例外的情况，有关 3DTiles 数据规范的扩展能力。

批次表的结构

• 填充：和特征表一样
• JSON头：
  
  
  
• 二进制体：
  

三、b3dm——tile二进制数据文件结构

• B3dm，Batched 3D Model，成批量的三维模型的意思，允许对异构3D模型（例如城市中的不同模型建筑物）批处理。
• 倾斜摄影数据（例如osgb）、BIM数据（如rvt）、传统三维模型（如obj、dae、3dMax制作的模型等），均可创建此类瓦片。
• 每个模型属性（例如ID）在运行时能够识别和更新各个模型。

Header和body

Feature Table

要素表，记录的是整个瓦片渲染相关的数据，而不是渲染所需的数据(glb中)。

• 全局属性：

属性名	属性数据类型	属性描述	是否必需
BATCH_LENGTH	uint32	当前瓦片文件内三维模型（BATCH、要素）的个数	yes
RTC_CENTER	float32[3]	如果模型的坐标是相对坐标，那么相对坐标的中心即此	no

注意，如果glb模型并不需要属性数据，即要素表和批量表有可能是空表，那么 BATCH_LENGTH 的值应设为 0 .

• 要素属性：