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中隐式镶嵌允许你声明一次四叉树或八叉树带有细分方案和最大层级查看器通过程序计算拼贴URIspan stylecolor:#e1e4e8span stylebackground-color:#24292ecodecontent/{level}/{x}/{y}.glb # quadtree (2D) content/{level}/{x}/{y}/{z}.glb # octree (3D) /code/span/span结果tileset.json从兆字节降到几百字节。创作工具不必发出显式节点条目——只需将瓦片文件导出到可预测的文件夹结构中即可。观察者通过计算摄像机视锥的URI来获取图块而不是在JSON树上移动。对于测量员来说大型LiDAR图块集生成更快tileset.json不再是页面加载的瓶颈。过去20万图块的摄影测量采集仅加载图块集清单就要5到10秒甚至还没渲染任何图块。而隐式拼贴则几乎为零。3DTILES_metadata每个功能属性3D Tiles 1.0 没有一种干净的方法来将任意元数据附加到瓦片或特征上。你可以在文件中嵌入批量表但查询它们需要先加载瓦片内容。.b3dm3D Tiles 1.1 增加了一个具有三个范围的正式元数据系统磁贴集元数据——关于整个数据集的属性捕获日期、传感器、CRS、测量员组元数据——跨多个瓦片共享建筑物、调查区域瓦片元数据——每个瓦片属性点数、边界信息、分类属性此外还可通过glTF和扩展实现每个特征的元数据。点云中的每个点或网格中的每个特征现在都可以携带一组任意属性分类、强度、返回数、扫描角度、源测量仪这些属性可以从查看器查询无需加载额外文件。EXT_mesh_featuresEXT_structural_metadata对于测量员来说这就是你最终在浏览器查看器中暴露LiDAR分类码、摄影测量源图像参考或资产ID的方式。客户端可以点击某点查看“地面回波强度142扫描2026-04-12”无需往返到另一个数据库。每个格子有多个内容在1.0版本中一个瓦片包含一个内容。如果你想在同一位置合并网格和点云你就用了复合格式把它们捆绑起来——笨重且只部分支持。.cmpt在1.1中一个瓦片可以直接声明多个条目contentspan stylecolor:#e1e4e8span stylebackground-color:#24292ecodespan stylecolor:#9ecbffcontents/spanspan stylecolor:#e1e4e8: [/span span stylecolor:#e1e4e8 { /spanspan stylecolor:#79b8ffuri/spanspan stylecolor:#e1e4e8: /spanspan stylecolor:#9ecbffmesh.glb/spanspan stylecolor:#e1e4e8 },/span span stylecolor:#e1e4e8 { /spanspan stylecolor:#79b8ffuri/spanspan stylecolor:#e1e4e8: /spanspan stylecolor:#9ecbffpoints.glb/spanspan stylecolor:#e1e4e8 }/span span stylecolor:#e1e4e8]/span /code/span/span两者同时加载和渲染。适用于混合交付物——例如建筑的摄影测量网格与注册的内部细节点云且均位于同一瓦片位置。观众会把它们当作一个逻辑图块但可以对每个图块应用不同的样式。通过EXT_mesh_gpu_instancing实现更好的实例化3D Tiles 1.0 的实例模型是重复的物体如树木、路灯柱或测量标记分布在多个位置。它能用但是一个独立的格式有自己的特点。.i3dm3D 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.cmpt3D 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.1072023 年起完全隐式铺砌和元数据支持稳定。截至2024年NASA-AMMOS 3DTilesRendererJS 库中的Three.js加载器支持大部分 1.1 版本。大多数观察器同时处理1.0和1.1的图块集。字段会声明所使用的规格版本观众会相应分支。没有旗帜日——1.0的图块集可以无限期运行。asset.versiontileset.json编写工具采用1.1版本的速度较慢铯离子——截至2023年新上传时会发出带有隐式平铺的1.1图块集py3dtiles— 在7.02023中增加了隐式铺砌支持。Pix4D / Metashape / RealityCapture——截至撰写时输出1.0风格的图块集;查看版本说明以获取更新PDAL— 通过管道输出1.0风格的瓦片集.pntswriters.tiler如果你的工具输出1.0版本你的图块集依然能工作并且在每个现代视野中都能渲染。升级到支持1.1的工具可以让你获得更小的tileset.json文件、更快的初始加载速度以及元数据系统。这不是强制迁移。测量师应该关注什么实际影响按对日常工作的影响程度排序变化实际影响隐式铺砌更小的tileset.json。在大型数据集上初始页面加载更快。如果你的工具输出1.1就不需要操作。每个功能元数据点击查看器中的一个点查看其分类和属性。这样可以消除客户“你能给我底层数据吗”的一整类问题。每个格子有多个内容同一场景中的网格点云叠加。对混合交付物很有用。子树文件这仅在地区/国家层面重要。大多数测量项目都不符合这个功能。glTF作为主要格式更清晰的创作流程。减少格式转换。对终端用户来说大多是隐形的。GPU 实例化重复对象的渲染速度更快。资产-库存图块集的明显改进。元数据系统是最大的实际胜利。能够直接在浏览器查看器中展示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的瓦片集并在共享链接查看器中暴露元数据。你不必知道你的创作工具发布了哪个规范版本也能获得一个可用的共享链接。
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中隐式镶嵌允许你声明一次四叉树或八叉树带有细分方案和最大层级查看器通过程序计算拼贴URIspan stylecolor:#e1e4e8span stylebackground-color:#24292ecodecontent/{level}/{x}/{y}.glb # quadtree (2D) content/{level}/{x}/{y}/{z}.glb # octree (3D) /code/span/span结果tileset.json从兆字节降到几百字节。创作工具不必发出显式节点条目——只需将瓦片文件导出到可预测的文件夹结构中即可。观察者通过计算摄像机视锥的URI来获取图块而不是在JSON树上移动。对于测量员来说大型LiDAR图块集生成更快tileset.json不再是页面加载的瓶颈。过去20万图块的摄影测量采集仅加载图块集清单就要5到10秒甚至还没渲染任何图块。而隐式拼贴则几乎为零。3DTILES_metadata每个功能属性3D Tiles 1.0 没有一种干净的方法来将任意元数据附加到瓦片或特征上。你可以在文件中嵌入批量表但查询它们需要先加载瓦片内容。.b3dm3D Tiles 1.1 增加了一个具有三个范围的正式元数据系统磁贴集元数据——关于整个数据集的属性捕获日期、传感器、CRS、测量员组元数据——跨多个瓦片共享建筑物、调查区域瓦片元数据——每个瓦片属性点数、边界信息、分类属性此外还可通过glTF和扩展实现每个特征的元数据。点云中的每个点或网格中的每个特征现在都可以携带一组任意属性分类、强度、返回数、扫描角度、源测量仪这些属性可以从查看器查询无需加载额外文件。EXT_mesh_featuresEXT_structural_metadata对于测量员来说这就是你最终在浏览器查看器中暴露LiDAR分类码、摄影测量源图像参考或资产ID的方式。客户端可以点击某点查看“地面回波强度142扫描2026-04-12”无需往返到另一个数据库。每个格子有多个内容在1.0版本中一个瓦片包含一个内容。如果你想在同一位置合并网格和点云你就用了复合格式把它们捆绑起来——笨重且只部分支持。.cmpt在1.1中一个瓦片可以直接声明多个条目contentspan stylecolor:#e1e4e8span stylebackground-color:#24292ecodespan stylecolor:#9ecbffcontents/spanspan stylecolor:#e1e4e8: [/span span stylecolor:#e1e4e8 { /spanspan stylecolor:#79b8ffuri/spanspan stylecolor:#e1e4e8: /spanspan stylecolor:#9ecbffmesh.glb/spanspan stylecolor:#e1e4e8 },/span span stylecolor:#e1e4e8 { /spanspan stylecolor:#79b8ffuri/spanspan stylecolor:#e1e4e8: /spanspan stylecolor:#9ecbffpoints.glb/spanspan stylecolor:#e1e4e8 }/span span stylecolor:#e1e4e8]/span /code/span/span两者同时加载和渲染。适用于混合交付物——例如建筑的摄影测量网格与注册的内部细节点云且均位于同一瓦片位置。观众会把它们当作一个逻辑图块但可以对每个图块应用不同的样式。通过EXT_mesh_gpu_instancing实现更好的实例化3D Tiles 1.0 的实例模型是重复的物体如树木、路灯柱或测量标记分布在多个位置。它能用但是一个独立的格式有自己的特点。.i3dm3D 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.cmpt3D 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.1072023 年起完全隐式铺砌和元数据支持稳定。截至2024年NASA-AMMOS 3DTilesRendererJS 库中的Three.js加载器支持大部分 1.1 版本。大多数观察器同时处理1.0和1.1的图块集。字段会声明所使用的规格版本观众会相应分支。没有旗帜日——1.0的图块集可以无限期运行。asset.versiontileset.json编写工具采用1.1版本的速度较慢铯离子——截至2023年新上传时会发出带有隐式平铺的1.1图块集py3dtiles— 在7.02023中增加了隐式铺砌支持。Pix4D / Metashape / RealityCapture——截至撰写时输出1.0风格的图块集;查看版本说明以获取更新PDAL— 通过管道输出1.0风格的瓦片集.pntswriters.tiler如果你的工具输出1.0版本你的图块集依然能工作并且在每个现代视野中都能渲染。升级到支持1.1的工具可以让你获得更小的tileset.json文件、更快的初始加载速度以及元数据系统。这不是强制迁移。测量师应该关注什么实际影响按对日常工作的影响程度排序变化实际影响隐式铺砌更小的tileset.json。在大型数据集上初始页面加载更快。如果你的工具输出1.1就不需要操作。每个功能元数据点击查看器中的一个点查看其分类和属性。这样可以消除客户“你能给我底层数据吗”的一整类问题。每个格子有多个内容同一场景中的网格点云叠加。对混合交付物很有用。子树文件这仅在地区/国家层面重要。大多数测量项目都不符合这个功能。glTF作为主要格式更清晰的创作流程。减少格式转换。对终端用户来说大多是隐形的。GPU 实例化重复对象的渲染速度更快。资产-库存图块集的明显改进。元数据系统是最大的实际胜利。能够直接在浏览器查看器中展示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的瓦片集并在共享链接查看器中暴露元数据。你不必知道你的创作工具发布了哪个规范版本也能获得一个可用的共享链接。
