共计 3293 个字符，预计需要花费 9 分钟才能阅读完成。
1. 简介
3D Tiles Next 是一组针对下一代 3D Tiles 的新性能（或者说 3D Tiles 扩大）。
这些新性能目前以 3D Tiles 1.0 的扩大草案出现，未来可能会合并到 3D Tiles 2.0 中。
2. 对于瓦片数据内容的扩大（Tile Content）
2.1. 概述
在 Next 中，glTF 2.0 数据将能够间接作为瓦片的内容，不再应用 1.0 的 b3dm、i3dm、pnts 和 cmpt，提供了与 glTF 生态的互通性。瓦片能够援用单个内容，也能够援用多个内容。
瓦片的内容也能够汇合至相似于 2D 地图图层一样的容器组中。
尽管 Next 应用 glTF 作为瓦片文件，不再应用原来的四种瓦片文件格式，然而并不意味着运行时不再应用，这是数据标准版本的区别，而不是运行时立马就要放弃旧标准。
2.2. 扩大 3DTILES_content_gltf
3DTILES_content_gltf 这项扩大，容许在 Tile.content 属性上间接援用一个 glTF 模型文件（.gltf 或 .glb）。
2.3. 扩大 3DTILES_multiple_content
3DTILES_multiple_content 这项扩大，容许一个瓦片援用多个内容（瓦片文件）。瓦片实际上就是一块空间范畴体，组织起多个瓦片文件是很失常的。
组织模式也多种多样，能够像地图图层一样，也能够轻易分组。
通常会与 [3DTILES_metadata]() 扩大所组织的元数据一起用。
3. 隐式瓦片（Implicit Tiling）
3.1. 概述
隐式瓦片宰割，意思就是将瓦片的空间范畴和空间索引形式“隐去”，即不显式地记录在瓦片对象中，而这种隐含的空间宰割办法和索引形式，则是默认数据生产者和运行时晓得的。
其无效地缩小了 tileset.json 这个文件的体积，并进步了空间索引的效率，寻找、遍历瓦片的速度更快，射线计算、随机拜访、空间查问也更快了。
除了上述长处，还加强了与 2DGIS 中一些天文数据格式 / 数据库的互相集成，例如 CDB、TMS、WMTS、S2.
3.2. 扩大 3DTILES_implicit_tiling
启用了 3DTILES_implicit_tiling 扩大的 tileset（瓦片集），瓦片对象有一一对应的 .subtree 文件，它存储了该瓦片的可见性信息，依此，意味着能够在 URI 上通过惟一的数字编码（level、x、y）进行流式传输。
启用了这项扩大的瓦片集，它的空间宰割构造（树结构）就是紧凑型的了，这种树结构对遍历算法、射线计算、空间索引有帮忙。
总而言之，隐式瓦片这项扩大次要是晋升了大规模数据集的空间索引性能。
3.3. 扩大 3DTILES_bounding_volume_S2
启用 [3DTILES_bounding_volume_S2]() 扩大，意思就是把 S2 几何体 作为瓦片的空间宰割形式。
尤其是与 3DTILES_implicit_tiling 扩大一起应用时，S2 宰割形式十分适合超大规模（洲际、寰球）的数据，其能够最大限度地缩小极地左近的失真（瓦片的空间范畴长方体与赤道左近的不会大小差别过大）。它最大的特点是，同级别的格子所示意的空间范畴大小是差不多的。
S2 所规定的 30 级空间范畴细分等级足够准确到世界任意角落，精度达厘米级。
4. 元数据（Metadata）
4.1. 概述
通过更敌对的类型零碎、新的编码方式及全粒度反对，3D Tiles Next 中的元数据更加弱小了。全粒度是指，元数据能够高层级对象（Tileset、Tile、TileGroup）上记录，也能够在更低层级的单元上记录，比方 glTF 中的几何形态，甚至是单个顶点、单个纹素。
随着 3D Tiles Next 一起提出的 [三维元数据标准（3D Metadata Specification）]()，成为 Next 中所有元数据的根底。这个标准提出了模式、属性类型、存储格局、属性的意义等概念，要求元数据得按这样的形式组织。
以后，曾经实现在 3D Tiles 和 glTF 2.0 这两个数据标准的元数据扩大，将来其余可能的格局的扩大依然以扩大的形式来反对。
4.2. 扩大 3DTILES_metadata
[3DTILES_metadata]() 扩大定义了 Tileset、Tile、TileGroup 三层的元数据如何组织。在其余状况下，元数据又另有别的形式实现，例如在下列两个扩大启用时，元数据是这么组织的：
- 在 3DTILES_implicit_tiling 中，元数据存储在
.subtree二进制文件中，不便大规模的瓦片数据进行流式传输； - 在 3DTILES_multiple_content 中，某个瓦片所指向的瓦片文件会与某个组进行绑定，那么这个组的元数据也成为了瓦片的元数据，加强了瓦片的内容组织、款式化与过滤。
4.3. glTF 2.0 扩大：EXT_mesh_features
[EXT_mesh_features]() 是一个 glTF 2.0 标准的扩大，通常与 3DTILES_content_gltf 一起用。启用后，元数据就能够与瓦片文件（此时就是指 gltf/glb 文件了）中的“三维因素”作用，而且是在各个不同的层级：
- 在每个 vertex（顶点）：与 3D Tiles 1.0 中的批次表一样，顶点能够通过分组来标记属于哪个“三维因素”，从而实现因素级别的元数据；
- 在每个 texel（纹素）：在几何面片不是很简单的数据中，间接将属性值和三维因素 ID 到纹理上，即通过纹素来辨别“因素”，实现元数据与三维数据对象的对应，这是一个很不错的优化伎俩；
- 在每个 GPU 实例（GPU instance）：这个须要配合 [EXT_mesh_gpu_instancing]() 这个 glTF 2.0 的扩大来实现，相似 i3dm 的机制。
上图简略地展现了各层级的元数据如何组织：
- 高层级的 Tileset、Tile、TileContent(Group) 由 3DTILES_metadata 扩大负责实现
- “三维因素”级别的元数据，则由 glTF 2.0 标准中的 EXT_mesh_features 扩大实现。
对于“三维因素”级别的元数据，还心愿读者认真理解 EXT_mesh_features 这个扩大的 例子。
4.4. 三维元数据标准（3D Metadata Specification）
连贯：三维元数据标准（3D Metadata Specification）
元数据指的是瓦片这个实体数据的数据，以及瓦片数据文件中的三维因素数据的数据，那么包含上述两个在内，总要有一套标准来灵便接收各个领域的元数据，这部分尽管不是具体的扩大项，然而也属于 Next 的重要组成部分。
这项标准还提供了一个 三维元数据语义参考（3D Metadata Semantic Reference），用于形容具体某个属性的含意。有些含意可能是通用的，比方“id”、“name”、“description”等，也可能是不通用的，须要具体问题具体分析。
5. 对于 Logo
Next 的 logo 的版权与 CesiumJS 的统一，给开发者应用。然而留神，这个不要作为主要用途，因为其中的 NEXT 文本会被替换。
下载链接：3D-Tiles-Next-Logo.zip
译者注
Next 在三维模型数据格式上、空间索引上、各级空间对象的属性元数据上都下了功夫，专一于“三维大规模流式数据标准”的制订，此次晋升了数据灵活性、性能，却短少了三维里重要的一环：成果。
其实 CesiumJS 作为 3D Tiles 的次要显示运行时，它始终没把成果编程作为宣传点。不过在 Next 推动的这段时间里，官网还是提供了成果编程的一个小尾巴的，那就是随着新的三维数据加载架构公布的自定义着色器接口，容许开发者为渲染过程编写更灵便的着色器（以往只是能写后处理或者外观着色器，自定义着色器适配新架构的同时更规范化了）。
对于 3D Tiles Next 的数据生产工具截至发文（2022 年春节前夕），依然没有特地优良的实现，起因就是大家可能并不相熟这个 Next，我写；也有可能就是 Web3D 自身就小众，WebGIS3D 更少人了，更别说它在搞的一个数据标准的下一代规范了，只管在剖析这些扩大的过程中，我感觉官网为了晋升，还是下了一番功夫的。
