3D Tiles 1.1：测量师的新动态
3D Tiles 1.0 于 2019 年由开放地理空间联盟（Open Geospatial Consortium）批准。1.1 版本于 2023 年获批，现为当前的 OGC 标准。大多数工具仍在输出 1.0 风格的图块集，但 1.1 是生态系统的发展方向，它改变了大型场景的创作、存储和查询方式。
以下是实际发生的变化，以及如果你是通过无人机、激光雷达或摄影测量管道制作图块集，哪些重要。
背景：3D Tiles 的起源
3D Tiles 由 Cesium 于2015年左右开发，旨在解决 GIS 已有的问题——将大量地理空间数据流入浏览器——用于 3D。1.0 版本于 2019 年成为 OGC 社区标准。它定义了一个包含 、 、 、 和 瓦片内容格式的 tileset.json层级结构，一个四叉树/八叉树空间细分，以及决定何时细化为更高 LOD 图块的屏幕空间-误差指标。.b3dm.pnts.i3dm.cmpt
该规范带来了大量功能。但也带来了摩擦。编写一个十亿点的激光雷达数据集意味着生成数百万个独立瓦片文件以及明确列出每个瓦片的元数据tileset.json。添加每个特征属性（分类码、强度值、属性表）很笨拙。在同一瓦片中合并不同内容类型也很笨拙。
1.1版本解决了这些摩擦问题。关于底层格式的入门介绍，请参见我们的3D Tiles解释。
1.1版本的新内容
隐式铺砌
最大的变化。在1.0版本中，每个图块都必须明确列出其边界体、几何误差和内容URI。一个拥有百万图块的图块集意味着清单中有一百万条目——通常拆分到嵌套的外部图块集，但每个节点仍需显式元数据。tileset.json
在1.1中，隐式镶嵌允许你声明一次四叉树或八叉树，带有细分方案和最大层级，查看器通过程序计算拼贴URI：
content/{level}/{x}/{y}.glb # quadtree (2D) content/{level}/{x}/{y}/{z}.glb # octree (3D)
结果：tileset.json从兆字节降到几百字节。创作工具不必发出显式节点条目——只需将瓦片文件导出到可预测的文件夹结构中即可。观察者通过计算摄像机视锥的URI来获取图块，而不是在JSON树上移动。
对于测量员来说：大型LiDAR图块集生成更快，tileset.json不再是页面加载的瓶颈。过去，20万图块的摄影测量采集仅加载图块集清单就要5到10秒，甚至还没渲染任何图块。而隐式拼贴则几乎为零。
3DTILES_metadata：每个功能属性
3D Tiles 1.0 没有一种干净的方法来将任意元数据附加到瓦片或特征上。你可以在文件中嵌入批量表，但查询它们需要先加载瓦片内容。.b3dm
3D Tiles 1.1 增加了一个具有三个范围的正式元数据系统：
-
磁贴集元数据——关于整个数据集的属性（捕获日期、传感器、CRS、测量员）
-
组元数据——跨多个瓦片共享（建筑物、调查区域）
-
瓦片元数据——每个瓦片属性（点数、边界信息、分类属性）
此外，还可通过glTF和扩展实现每个特征的元数据。点云中的每个点，或网格中的每个特征，现在都可以携带一组任意属性（分类、强度、返回数、扫描角度、源测量仪），这些属性可以从查看器查询，无需加载额外文件。EXT_mesh_featuresEXT_structural_metadata
对于测量员来说：这就是你最终在浏览器查看器中暴露LiDAR分类码、摄影测量源图像参考或资产ID的方式。客户端可以点击某点查看“地面回波，强度142，扫描2026-04-12”，无需往返到另一个数据库。
每个格子有多个内容
在1.0版本中，一个瓦片包含一个内容。如果你想在同一位置合并网格和点云，你就用了复合（）格式，把它们捆绑起来——笨重且只部分支持。.cmpt
在1.1中，一个瓦片可以直接声明多个条目：content
"contents": [ { "uri": "mesh.glb" }, { "uri": "points.glb" } ]
两者同时加载和渲染。适用于混合交付物——例如，建筑的摄影测量网格与注册的内部细节点云，且均位于同一瓦片位置。观众会把它们当作一个逻辑图块，但可以对每个图块应用不同的样式。
通过EXT_mesh_gpu_instancing实现更好的实例化
3D Tiles 1.0 的实例模型是重复的物体，如树木、路灯柱或测量标记，分布在多个位置。它能用，但是一个独立的格式，有自己的特点。.i3dm
3D Tiles 1.1 被弃用，转而支持 glTF 的扩展。实例几何体现在存在于常规图块内容中，使用标准的GPU实例路径。结果是：实例化更快，与 glTF 工具生态系统集成更干净，且使用更少的格式。.i3dmEXT_mesh_gpu_instancing.glb
对于制作包含数千个重复对象的图块集（资产清单、植被调查、基础设施目录）的测量员来说，实例化渲染速度明显更快。
大型场景的子树文件
隐式铺砖需要一种方式告诉观察者概念四叉树/八叉树中哪些瓦片真实存在（你不想为海洋或稀疏的激光雷达区域生成空瓦片）。1.1引入了子树文件——二进制文件，编码了隐式层级子树中瓦片和内容的可用性。
单个子树文件可以在几千字节内描述数百万瓦片的可用性。查看器在穿越层级结构时获取子树文件，然后用它们决定请求哪些隐式瓦片URI。
对于测量员来说：这在区域或国家数据集的尺度上很重要。一个覆盖稀疏的大陆LiDAR数据集，过去需要明确列出所有现有的瓦片。对于子树文件，同一数据集以紧凑的二进制格式描述其可用性，并根据观察者的需要进行流式传输。
glTF作为主要的图块内容格式
3D Tiles 1.0 具有（批处理 3D 模型——一个用自定义头部包裹的 glTF 和特征表）、（Point Cloud ——一个自定义二进制）、、 和 。四个格式，四个解析器。.b3dm.pnts.i3dm.cmpt
3D Tiles 1.1 将推荐的图块内容格式简化为二进制 glTF。网格、点和实例化模型都存在于使用 glTF 扩展名的文件中：.glb.glb
-
网格 — 标准 glTF
-
点 — （或某些实现中）EXT_mesh_primitive_pointKHR_points
-
实例——EXT_mesh_gpu_instancing
-
元数据 — ，EXT_structural_metadataEXT_mesh_features
.b3dm， ， 和 已被弃用，但查看器仍支持以实现向后兼容性。新模具应该会发出瓦片。.pnts.i3dm.glb
对于测量师来说：实际效果是流程中的格式转换减少。你导出给浏览器显示的 glTF 可以直接铺砖，无需重新编码成 。.b3dm
兼容性
自 1.99 版本（2022 年底）起，CesiumJS 逐步支持 3D 瓷砖 1.1 功能，从 CesiumJS 1.107（2023 年）起，完全隐式铺砌和元数据支持稳定。截至2024年，NASA-AMMOS 3DTilesRendererJS 库中的Three.js加载器支持大部分 1.1 版本。
大多数观察器同时处理1.0和1.1的图块集。字段会声明所使用的规格版本，观众会相应分支。没有旗帜日——1.0的图块集可以无限期运行。asset.versiontileset.json
编写工具采用1.1版本的速度较慢：
-
铯离子——截至2023年，新上传时会发出带有隐式平铺的1.1图块集
-
py3dtiles — 在7.0（2023）中增加了隐式铺砌支持。
-
Pix4D / Metashape / RealityCapture ——截至撰写时，输出1.0风格的图块集;查看版本说明以获取更新
-
PDAL — 通过管道输出1.0风格的瓦片集.pntswriters.tiler
如果你的工具输出1.0版本，你的图块集依然能工作，并且在每个现代视野中都能渲染。升级到支持1.1的工具可以让你获得更小的tileset.json文件、更快的初始加载速度，以及元数据系统。这不是强制迁移。
测量师应该关注什么
实际影响，按对日常工作的影响程度排序：
元数据系统是最大的实际胜利。能够直接在浏览器查看器中展示LiDAR的分类、强度和元数据捕获——无需单独的属性表——缩小了“客户端查看调查”和“客户端查询调查”之间的差距。这就是交付成果漂亮与实用成果之间的区别。
标准的发展方向
3D Tiles Next 是后来成为 1.1 的作品集的工作名称。OGC和铯社区正在探索的未来方向：
-
更深层次的 glTF 集成——1.1 版本已经让 glTF 成为主要的图块内容格式。未来的版本可能会将更多规范整合进glTF扩展，模糊了“glTF模型”和“3D Tiles数据集”之间的界限。
-
改进的点云处理——3D Tiles中的点云渲染在原始点忠实度上仍落后于Potree。在这方面积极工作。
-
时间动态3D瓷砖——捕捉历史可视化（采石场六个月，基础设施资产多年）。目前负责应用端;未来的规范版本可能会对此进行正式化。
-
更好的创作工具——目前最大的差距不是规格，而是工具生态系统。预计未来一两年内，更多创作软件会赶上1.1版本。
标题是：3D Tiles 现已成为一个成熟的、OGC 认可的、供应商中立的标准，并实现广泛。这种格式不会消失——如果说有什么变化，1.1版本更巩固了它作为大规模空间数据的默认流媒体格式。
如果你今天向客户交付3D瓦片，Swyvl会读取1.0和1.1的瓦片集，并在共享链接查看器中暴露元数据。你不必知道你的创作工具发布了哪个规范版本，也能获得一个可用的共享链接。
浙公网安备 33010602011771号