原文链接及内容
Introducing 3D Tiles Next, Streaming Geospatial to the Metaverse
介绍 3D Tiles Next,将地理空间数据流式传输到元宇宙

编者注:先前被称为“3D Tiles Next”的3D Tiles社区标准1.1版,旨在为元宇宙提供高分辨率、语义丰富的3D地理空间数据的流式传输。

今天我们很高兴地宣布,3D Tiles Next开放规范现已开放供社区反馈。

在六年前的 SIGGRAPH 大会上,我们推出了用于流式传输大规模异构 3D 地理空间数据集的初始 3D Tiles 规范。自那时起,我们深受启发,看到社区如何利用 3D Tiles 构建应用程序、导出工具、API 和引擎,从而发展出一个开放且互操作的 3D 地理空间生态系统。

注:SIGGRAPH是由ACM SIGGRAPH组织的计算机图形学顶级年度会议。ACM全称为Association for Computing Machinery,即计算机协会。SIGGRAPH全称为Special Interest Group on Computer Graphics and Interactive Techniques,即计算机图形和交互技术特别兴趣小组

CesiumJS 中 Bentley Systems 的发电厂 CAD 模型、虚幻引擎中维多利亚州政府的点云、O3DE 中 Aerometrex 的旧金山摄影测量模型、STK 中的 OSM 建筑物、Three.js 中位于Jezero陨石坑的 NASA 毅力号火星车

利用3D Tiles进行构建的集体经验,结合3D地理空间数据可用性的持续增长,尤其是语义元数据,以及用户对数字孪生和元宇宙日益增长的兴趣,促成了3D Tiles规范的下一代发展。

3D Tiles Next 的核心仍然是大规模的流式交互式 3D。3D Tiles Next 是一组扩展,允许开发者社区更好地:

  • 高效地流式传输语义元数据,
  • 通过空间索引运行大规模仿真和分析
  • 并与glTF软件及其扩展生态系统集成。

新草案扩展的架构,(黄)绿色部分,适用于 3D Tiles Next 和 glTF。

3D Tiles Next 的扩展功能使得类似游戏的地理空间体验能够流式传输到开放的元宇宙中,覆盖包括当今及未来的 VR 和 AR 穿戴设备在内的多种设备。3D Tiles Next 充分利用了 5G 技术以及边缘和云计算,旨在提升开放且互操作的生态系统中的 3D 地理空间体验标准。在开发 3D Tiles Next 过程中,我们与 Maxar 紧密合作,确保其能满足建模与仿真社区对高效运行时地形用于训练、模拟及操作的需求。

注:Maxar:麦克萨科技是一家总部位于美国科罗拉多州威斯敏斯特的太空技术公司,专门生产通信、地球观测、雷达和在轨服务卫星以及卫星相关产品和服务。

左图:3D 资产和元数据的示例来源正变得越来越广泛可用。右图:已经支持或正在支持 3D Tiles Next 的运行时引擎

高效地传输语义元数据

在 3D Tiles Next 中,我们非常重视元数据,因为它的可用性不断提高,且用户需求日益增长。正如当今的车辆、传感器、计算和摄影测量趋势,使我们能够以越来越高的几何和纹理分辨率捕捉现实世界一样,当今的人工智能算法也越来越多地利用语义丰富的元数据来增强 3D 模型。

从 3D Tiles 的初期开始,我们就意识到需要超越单纯的可视化,通过存储这些元数据(如建筑 ID 或点分类)以及几何和纹理来实现。这些元数据常用于样式化和过滤,例如应用基于分类的颜色渐变来区分植被与建筑结构,以及用于用户交互,如在鼠标悬停时显示建筑物的楼层数。

3D Tiles Next 引入了新的元数据扩展,用于:

  • 定义明确的类型系统和更多编码选项,如二进制或 JSON;
  • 更多存储粒度选项,例如每纹素(per-texel)和每瓦片(per-tile);
  • 语义含义被添加到元数据中,促进了领域特定语义扩展的生态系统。

类似于 3D Tiles 1.0 使用 Batch Table 高效存储元数据的方式,3D Tiles Next 实现了 3D Tiles 最显著的性能优势之一:批处理(batching)。许多逻辑要素,如单个建筑物及其元数据,可以在运行时预批处理为一个网格和一个图形 API 的绘制调用,但它们仍能被唯一识别,从而减少了每块瓦片的运行时处理量,并在渲染时降低了 CPU 开销。

元数据类型系统、编码选项和示例语义规范

元数据类型系统

新的3D元数据规范定义了一个类型系统模式和元数据的编码方法。

3D Tiles 1.0依赖于JSON的类型系统;而3D Tiles Next采用了更强的类型系统,包括类、向量和矩阵等类型。元数据的编码方式可以是:

  • 二进制格式,例如当元数据按顶点存储在同一网格的不同顶点时;
  • JSON格式,例如当元数据按瓦片(tile)使用时;
  • 栅格,用于实现精细到每个纹素(texel)的粒度。

不同粒度的元数据

通过使用3DTILES_metadataEXT_mesh_features(glTF的一个扩展),3D Tiles Next被设计为能够以不同粒度高效存储元数据:

  • 按瓦片集(tileset)
  • 按瓦片(tile)或瓦片内容组
  • 按要素(feature)
  • 按GPU实例
  • 按顶点(vertex)
  • 按纹素(texel)

不同粒度下的示例元数据

最精细的粒度,即每个纹素(per texel),允许元数据的变化频率甚至超过几何体本身。例如,想象一座建筑物的侧面可能仅用两个三角形建模,然后应用一个元数据纹理来定义哪些部分是玻璃、砖块或石头。这些不同的材质在分析中会有不同的交互方式,例如射线在射频传播中的反射方式;同时在渲染中也有差异,例如将元数据映射到glTF的基于物理渲染(PBR)材质上。

PBR,physically-based rendering,即基于物理的渲染。

来自Aerometrex的对旧金山渡轮大楼的街景摄影测量。左侧:按纹素(texel)显示的颜色,展示要素分类,例如屋顶、天空屋顶、窗户、窗框和空调设备。右侧:分类用于确定渲染材质属性,例如使窗户呈现半透明效果

元数据的语义规范

3D Tiles Next 旨在实现一个游戏般的元宇宙体验,呈现整个世界的数字表达。在这样的规模下,我们不仅需要表现每个城市、每栋建筑、每个房间、每个门把手以及每个对象的元数据,还需要理解这些元数据的语义含义,以便不同应用程序能够知道元数据如何影响交互。例如,混凝土与草地的摩擦系数会影响车辆的速度,而了解门开启的方向则会影响人群模拟。

3D Tiles Next 提供了元数据基础,以促进一个生态系统的形成,在这个生态系统中,领域专家可以创建 3D Tiles 扩展来定义特定领域的元数据字典及其每个属性的语义。例如,土方工程建设可以为堆料场中的材料(如石头或粘土)定义语义,并为预计算参数设定语义,以加速运行时的体积和面积计算。

通过空间索引运行大规模模拟和分析

3D Tiles Next 优化了空间细分(spatial subdivision),能够实现快速的空间查询、更快的分析,并与 GIS 和模拟生态系统实现更高的互操作性。

自从 3D Tiles 1.0 推出以来,越来越多的人想要在一个真实的 3D 世界模型里,运行那种有很多代理(角色)参与的大规模模拟,同时也想在这样的环境里做一些分析,比如研究视线传播或者射频传播情况。3D Tiles Next 的空间数据结构不仅优化了可视化的流式传输,还优化了大规模模拟和分析,其中光线追踪和最近邻搜索等算法得益于空间细分(spatial subdivision)。

RF Propagation:RF即Radio Frequency,无线电频率,这里整个词汇翻译为射频传播。

关于 agents的翻译,AI给出的解释为:“agents”指的是参与模拟的个体或实体,通常可以理解为模拟中的“角色”或“代理”。它不一定是“人”,也可以是虚拟的物体、车辆、机器人等。

3D Tiles 能处理这么大规模的模型,关键在于其空间细分(spatial subdivision)机制。模型被分割为多个可流式加载的单元(或片段),这些片段(pieces)被称为“瓦片”(tiles)。随后构建由低细节瓦片组合而成的层级结构,用一种叫做“核外分层的细节层次”(out-of-core hierarchical level of detail)的技术,实现在云端根据视角来灵活加载内容。

在 3D Tiles 1.0 中,空间细分是通过一个或多个 tileset.json 文件明确定义的,这些文件描述了空间数据结构,也就是每个瓦片的边界范围、内容以及它的子瓦片,一直递归到最底层的叶子瓦片。

这种设计比传统的基于全局四叉树的 2D 地图瓦片系统更加通用。3D Tiles 的方法很灵活,可以创建各种不同的空间数据结构,这样就能开发出多种 3D 瓦片处理流程,根据不同的输入数据生成优化的 3D 瓦片集。比如,一个城市模型是用建筑物的底部轮廓拉伸出来的3D形状,而另一个模型是用LIDAR(一种激光扫描技术)采集的,这两个模型因为数据密度不同,可能会有不一样的细分方式。可能因为数据密度的不同而有不同的细分方式。但不管怎样,只要这些细分遵循空间一致性规则,子瓦片的内容必须在父瓦片的边界范围内,生成的 3D 瓦片集都能被同一个 3D Tiles 运行引擎流式传输。这是 3D Tiles 生态系统的一个关键优势:3D Tiles 运行引擎可以从任何来源流式传输 3D 瓦片。

不同空间细分的示例:KD-Tree、松散四叉树和八叉树

在3D Tiles Next中,3DTILES_implicit_tiling扩展引入了对3D瓦片集中常用空间索引的支持,不需要明确列出每个瓦片的边界范围。这让用户可以随机访问任何一个瓦片,或者快速获取显示或分析某个区域所需的任意数量瓦片,从而为以下优化提供了可能:

  • 在单台服务器或跨多个计算单元上运行的大规模代理(角色/实体)模拟中,高效的k近邻搜索(k-nearest neighbors)和范围查询会很有帮助。
  • 在利用光线追踪(ray tracing)、光线步进(ray marching)和空间查询(spatial queries)进行分析时,采用均匀的空间索引可以提高效率。
  • 当只需要更新3D瓦片集的一部分时,可以进行部分更新,例如建筑工地上的材料堆放区或城市模型中的新建筑。

新型的运行时流式传输算法被开发出来,例如为在城市中移动的代理(agents,翻译见上面的解释,可以范围为实体)、随时间变化的建筑工地数字孪生体以及飞行模拟器等场景进行优化的流式传输。这些应用都受益于对瓦片的随机访问能力,这使得可以采用针对具体用例的专用算法,而不是依赖于通用的自上而下分层细节级别方法(HLOD,hierarchical level of detail)。

隐式瓦片划分支持大规模模拟,例如城市中的人群,空间索引能够高效查询附近的对象

隐式瓦片划分简洁地表示了3D瓦片集的空间数据结构,包括:

  • 八叉树或四叉树细分(subdivision);
  • 根瓦片的几何误差和边界范围,例如,同时支持全局和局部瓦片集;
  • 每块瓦片的可用性,这样运行时只去加载那些真实存在的瓦片,还有其他属于每块瓦片的数据,会用一种叫二进制莫顿Z次序曲线(Morton z-order curve)的方式存起来;
  • 模板URI,用于定义对瓦片进行随机访问的URI。

左图:瓦片集JSON中的隐式瓦片结构。右图:带有莫顿Z序曲线(Morton Z-order curve)覆盖的四级细分。

隐式瓦片划分当然也比使用tileset.json的显式瓦片划分节省存储空间和网络带宽。节省的空间是有益的,但隐式瓦片划分的真正动机在于,它能够实现对3D瓦片集中任意瓦片的随机访问,并保证瓦片集具有均匀的细分(uniform subdivision),这两者都为上面列出的新优化提供了可能。

除了支持新的算法外,我们在设计隐式瓦片划分时也考虑了互操作性。我们希望通过使用开放规范(如CDB、WMTS和TMS)实现与2D GIS以及传统建模和仿真生态系统的集成。隐式瓦片划分可以表示这些规范以及其他规范中使用的细分方式。

S2细分

3D Tiles Next还包括3DTILES_bounding_volume_S2扩展,该扩展适用于隐式和显式瓦片划分,用于为S2单元定义一种新的边界体积类型。这是一种基于立方体的全局细分方式,其中同一级别的每个瓦片面积大致相等,并且在极点处的扭曲最小,特别是与四叉树细分相比,在四叉树中靠近极点的瓦片会变得非常细长。

关于Hilbert Curve请参考:http://s2geometry.io/devguide/s2cell_hierarchy.html

WGS84 椭球体上的 S2 Hilbert 曲线

Layering with Multiple Contents-多内容分层

一种常见的地理空间用例是将具有相同元数据的对象分组到一个图层中,例如,高速公路、景点和城市建筑物各一个图层,然后可以一起设置图层样式、切换等操作。

借助 3D Tiles Next,3DTILES_multiple_contents 可通过在瓦片的组中定义图层元数据,然后为该组分配多个内容(例如 glTF 资产),来高效支持多图层管理。

与 glTF 生态系统集成

在 3D Tiles Next 中使用 3DTILES_content_gltf,现在一个瓦片直接引用.gltf.glb文件;而不是引用嵌入了 glTF 的.b3dm.i3dm文件。

这将使 3D Tiles 社区和 glTF 社区能够更轻松地从彼此的工作中受益。3D Tiles社区可直接复用glTF生态中的验证器、格式转换工具、数据处理流程、建模工具和运行时加载器;而glTF社区则能获得来自3D Tiles社区的技术反哺,包括对现有工具的功能增强以及新型glTF工具的开发贡献(这种双向赋能将推动三维可视化技术生态的持续演进)。

3D Tiles Next 通过以下方式深化了 3D Tiles 与 glTF 规范和生态系统之间的协同作用:

  • 从 3D Tiles 提供直接的 glTF 引用;
  • 将 glTF 用于点云;
  • 更好地利用 glTF 扩展,如纹理压缩。

3D Tiles 规范中-直接引用 glTF 模型文件

在 3D Tiles 的 tileset.json 中,瓦片可直接引用 glTF 文件:

1
2
3
4
5
6
7
8
9
{
"root": {
"boundingVolume": { ... },
"content": {
"uri": "building.glb" // 直接指向 glTF 文件
},
"children": [...]
}
}

3D Tiles 1.0 包含了用于批量 3D 模型(Batched 3D Models ,.b3dm)和实例化 3D 模型(Instanced 3D Models,.i3dm)的瓦片格式。这些二进制格式嵌入了二进制 glTF,以及一个头部和元数据。.glb glTF 的比特流布局与.b3dm 有着显著的相似性并非巧合,因为它们的最初设计是同时进行的。

左图:3D Tiles 1.0 使用 .b3dm 引用 glTF。右图:3D Tiles Next 直接引用 glTF,使用 EXT_mesh_features 替代 Batch Table 来存储元数据

使用 3DTILES_content_gltf,一个瓦片现在可以直接链接到一个.gltf.glb文件。如果瓦片中的要素具有元数据,则通过上述描述的 EXT_mesh_features glTF 扩展由 glTF 模型引用,从而取代了对.b3dm 的需求。

如果一个瓦片可以从实例化中收益;例如,因为有许多位于不同位置、不同比例的树木,那么将使用现有的 EXT_mesh_gpu_instancing glTF 扩展,从而取代对.i3dm的需求。EXT_mesh_features 也可以与实例化一起使用,以定义每个实例的元数据,如树木类型。

左图:3D Tiles 1.0 使用 .i3dm 实例化 glTF。右图:3D Tiles Next 直接引用 glTF,使用 EXT_mesh_gpu_instancing 进行实例化,并使用 EXT_mesh_features 替换用于存储元数据的 Batch Table

我们希望这一举措能直接引用 glTF,然后添加 glTF 扩展并利用 glTF 社区的扩展,使 3D Tiles 和 glTF 能够相互借鉴彼此的工作,从而促进更多跨行业和跨标准组织的合作。

将 glTF 用于点云

来自蒙特利尔市的 100 亿点云,带有 ASPRS 分类代码

ASPRS:American Society for Photogrammetry and Remote Sensing,美国摄影测量与遥感学会。

3D Tiles Next 中的点云现在利用带有 EXT_meshopt_compression 压缩的 glTF,以支持包含数十亿点的大规模点云及运行时交互,如样式化、过滤和显示每个点的元数据。

在 3D Tiles 1.0 中,点云存储在.pnts二进制文件中,点几何属性存储在要素表(feature table)中,元数据存储在批处理表(batch table)中,并使用 Draco 进行压缩。3D Tiles Next 现在利用 glTF 生态系统来处理点云:

  • 点几何现在存储在 glTF 中,元数据与 EXT_mesh_features 一起存储;
  • 顶点和法线压缩可以使用EXT_meshopt_compression扩展,这种方法在编码、传输和解码时都很高效,并且在GPU内存中保持压缩状态。

在最终确定 3D Tiles Next 规范之前,我们非常希望与社区合作,分析用于运行时 3D 用例的点云压缩选项,以了解使用LEPCCDraco如何补充 EXT_meshopt_compression 所服务的用例。

更好地利用 glTF 扩展,例如纹理压缩

由于3D Tiles Next不再使用b3dmi3dmpnts容器,所有增强glTF瓦片内容的功能都将以glTF扩展的形式实现,如上文示例所示。这将有助于 3D Tiles 更更好地为glTF生态系统做出贡献,并可能形成一个 glTF 地理空间配置文件

此外,3D Tiles Next将继续使用glTF扩展,例如KTX 2.0PBR Next材质。

KTX 2.0支持压缩纹理,用于传输和跨GPU供应商的运行时使用,实现了减少内存、带宽和功耗的多功能优化。我们特别期待将其应用于3D地理空间内容,因为通过卫星和无人机捕获的影像正在全球范围内产生爆炸性的纹理数据。

glTF的PBR Next计划汇集了全球PBR专家,推进glTF的材质表现,从金属-粗糙度和镜面-光泽度扩展到支持一系列新的视觉效果,例如透明涂层、透射和体积效果。例如,透射将通过以物理上合理的方式表示薄表面透明度(thin-surface transparency)来增强挡风玻璃和建筑物上玻璃的视觉真实感,这种方式能够吸收、反射和透射光线。

3D Tiles Next的现状

我们期待在未来几个月与社区合作,共同完成3D Tiles Next规范的最终定稿。社区需要您的意见来帮助完善这一规范,也需要您的努力来开始构建软件生态系统。

3D Tiles Next生态系统的当前状态是:

  1. pipelines ,这里翻译为处理流程比较符合;pipeline翻译为流程
  2. Cesium Native:Cesium 原生的 C++ 库,为游戏引擎(如 Unreal、O3DE)提供高性能地理空间数据渲染能力。
  3. 3D Tiles Next:3D Tiles 规范的下一代标准,支持动态语义化数据、多源内容融合及实时交互。
  4. Cesium for Unreal:Cesium 与虚幻引擎(Unreal Engine)的官方集成插件,用于构建高精度三维地理场景。
  5. Cesium for O3DE:Cesium 与开源引擎 Open 3D Engine (O3DE) 的适配版本,扩展地理可视化能力至更广泛的实时3D应用场景。

3D Tiles Next 路线图

在接下来的几个月里,我们对 3D Tiles Next 的重点是巩固草案规范,并继续促进生态系统的发展,根据实施经验保持规范设计的实用性。

通过与开放地理空间联盟(OGC)的 OGC 社区标准流程合作,以及通过 Khronos 的 3D 格式工作组进行合作,将对于促进协作和采用至关重要。

今天你就可以参与进来。3D Tiles 社区需要您对草案规范的反馈以及您实施经验的见解。请在 GitHub 上的 3d-tiles 仓库中分享您的想法。

来自社区的见解

这里请直接移至:https://cesium.com/blog/2021/11/10/introducing-3d-tiles-next/#insights-from-the-community 访问即可,这里不再翻译具体的内容。

阅读更多

  1. Cesium at SIGGRAPH 2024
  2. Vexcel 3D Cities Now Available with Cesium ion Self-Hosted