CesiumJS 2022^ 原理[3] 渲染原理之从 Entity 看 DataSource 架构 - 生成 Primitive 的过程

Python微信订餐小程序课程视频

https://blog.csdn.net/m0_56069948/article/details/122285951

Python实战量化交易理财系统

https://blog.csdn.net/m0_56069948/article/details/122285941
目录* API 用法回顾

• 1. 为什么要从 Viewer 访问 Entity API
  • 1.1. 高层数据模型的封装 - DataSource API
  • 1.2. 显示管理器 DataSourceDisplay 与默认数据源 CustomDataSource
  • 1.3. 默认的数据源 - CustomDataSource
  • 1.4. DataSource API 与 Scene 之间的桥梁
• 2. 负责 DataSource API 可视化的一线员工 - Visualizer
  • 2.1. 为 CustomDataSource 创建 Visualizer
  • 2.2. EntityCollection 与 Visualizer 之间的通信 - 事件机制
• 3. 时钟 - 如何让 Viewer 参与 CesiumWidget 的渲染循环
• 4. Visualizer 的更新之路
  • 4.1. 更新方法中的三个循环
  • 4.1. Visualizer 的数据转换工具 - Updater
  • 4.2. Updater 的集合 - GeometryUpdaterSet
  • 4.3. 性能的提升 - Updater 的分批
  • 4.4. Visualizer 更新的最后一步 - 批次容器更新
• 5. 批次容器完成数据合并 - Primitive 创建
  • 5.1. 批次容器的类型与创建
  • 5.2. 内部批次容器
  • 5.3. 创建 Primitive
• 本篇小结

---

API 用法回顾

只需传入参数对象，就可以简单地创建三维几何体或者三维模型。

const modelEntity = viewer.entites.add({
  id: 'some-entitiy',
  name: 'some-name',
  position: Cartesian3.fromDegrees(112.5, 22.3, 0),
  model: {
    uri: 'path/to/model.glb'
  }
})

Entity API 通常会被拿来与 Primitive API 比较，无外乎：

• 前者使用 Property API 使得动态效果简单化，后者需要自己编写着色器；
• 个体数量较多时，前者的性能不如后者；
• 后者支持较底层的用法，可以自己控制材质着色器、几何数据并批优化；
• …

本篇感兴趣的是 Entity API 是如何从参数化对象到 WebGL 渲染的。

首先，上结论：Entity 最终也会变成 Primitive。

从上面简单的示例代码可以看出，使用 Entity API 的入口是 Viewer，它不像 Primitive API 是从 Scene 访问的。

这正是关于 Entity API 源代码和设计架构的第一个知识，Entity API 必须依赖 Viewer 容器。

前提是只用公开出来的 API

1. 为什么要从 Viewer 访问 Entity API

Viewer 其实是 CesiumJS 长期维护的一个成果，它在大多数时候扮演的是 Web3D GIS 地球的总入口对象。今天的主角是它暴露出来的 Entity API，不过在介绍它之前，还要再提一提 Scene 暴露出来的 Primitive API

Scene 暴露出来的 Primitive API 是一种比较接近 WebGL 数据接口的 API，面对接近业务层的数据格式，譬如 GeoJSON、KML、GPX 等，Primitive API 就略显吃力了。

虽然可以做一些转换接口，不过 Cesium 团队结合自己研发的数据标记语言 – CZML，配上内置的时钟，封装出了更高级别的架构。

CesiumJS 使用 DataSource API 和 Entity API 这套组合实现了复杂、动态空间地理数据格式的接入。

1.1. 高层数据模型的封装 - DataSource API

这个 API 其实是 Entity API 的基础设施，在源码文件夹下就有一个 DataSources/ 文件夹专门收纳 Entity API 和 DataSource API 的源代码，可见重要程度之高。

首先，分别看定义在 Viewer 原型链上的两个属性 entities、dataSourceDisplay：

Object.defineProperties(Viewer.prototype, {
  // ...
  dataSourceDisplay: {
    get: function () {
      return this.\_dataSourceDisplay;
    },
  },
  entities: {
    get: function () {
      return this.\_dataSourceDisplay.defaultDataSource.entities;
    },
  },
  // ...
}

从上面两个 getter 看，EntityCollection 似乎是被 DataSourceDisplay 对象的 defaultDataSource 管辖的；defaultDataSource 是 CustomDataSource 类型的。

Viewer 拥有一个 DataSourceDisplay 成员，它负责所有 DataSource 的更新。接下来先介绍这个“显示管理器”类。

1.2. 显示管理器 DataSourceDisplay 与默认数据源 CustomDataSource

它随 Viewer 创建而创建，而且优先级相当高，仅次于 CesiumWidget；它自己则创建默认的 DataSource，也就是 CustomDataSource：

// DataSourceDisplay.js
function DataSourceDisplay(options) {
  // ...
  const defaultDataSource = new CustomDataSource();
  this.\_onDataSourceAdded(undefined, defaultDataSource);
  this.\_defaultDataSource = defaultDataSource;
  // ...
}

在这个 CustomDataSource 的构造函数里，就能找到 Viewer 暴露出去的 EntityCollection：

// CustomDataSource.js
function CustomDataSource(name) {
  // ...
  this.\_entityCollection = new EntityCollection(this);
  // ...
}

Object.defineProperties(CustomDataSource.prototype, {
  // ...
  entities: {
    get: function () {
      return this.\_entityCollection;
    },
  },
  // ...
}

所以，包含关系就说清楚了：

<