CesiumJS 2022^ 源码解读[7]

3DTiles 与 I3S 是竞争关系，可是比起生态开放性、数据定义的灵活性与易读性来说，3DTiles 比 I3S 好太多了。由于数据生产工具的开发者水平参差不齐，且数据并不存在极致的、万能的优化方法，故 3DTiles 1.0 时代的一些工具可能导致的数据渲染质量问题，让 3DTiles 的性能、显示效果颇受争议。

随着 CesiumJS 模型新架构的逐渐成型，下一代的 3DTiles 首先以 1.0 的扩展项测试使用，待日后时机成熟，会将 1.0 的规范标记为过时，甚至直接废弃，直接将这些扩展项作为 1.1 版本的核心定义使用（估计还挺久的）。

下一代 3DTiles 明确了这套规范的职能，即 更自由的显示效果可能性、更专注地三维空间索引性能、更强大的信息融合能力。

唠叨有点长，开始讲解，本文着重介绍的是“3DTiles”在 CesiumJS 中运作流程本身，而不是瓦片文件的解析（解析有兴趣的可以看本系列文章的上一篇，或者看旧版实现）、瓦片的空间调度算法、3DTiles 着色器设计。

1. 3DTiles 数据集的类型

3DTiles 1.0 规范允许异构数据共存于一个数据集上。3D 瓦片只是空间划分的单元，并不是该块三维空域内的具体三维物体。这些三维物体被称作“瓦片内容”。

1.0 允许存在 7 种瓦片内容，它们的文件后缀名是：

• b3dm，批次三维模型，该瓦片文件内置一个 glTF 模型文件，应尽可能在数据生产时优化此 glTF 的绘制批次
• i3dm，实例三维模型，允许内嵌在 i3dm 文件内的 glTF 模型在 WebGL 种绘制多实例
• pnts，点云
• cmpt，复合格式，即前三者的混合体，合并细碎瓦片内容文件成一个，减少网络请求
• vctr，矢量瓦片，未正式发布，本篇不讨论
• json，这种叫做扩展数据集（ExternalTileset），即允许瓦片空域内再嵌套一个子 3DTiles
• 空瓦片，即瓦片无内容

而 1.0 的扩展项，也就是下一代标准增加了一种瓦片格式：

• glb/gltf，也就是直接将 glTF 模型文件作为瓦片内容文件

值得注意的是，社区提案中，延申了 geojson 为瓦片内容文件，也就是说，在未来也许有可能引入更多的瓦片格式，但是能不能成为官方标准还不一定，暂且以 1.0 + 下一代的 glTF 格式为主要解说点。

而 3DTiles 一切的入口，都是从一个 json 文件开始的，这个文件名称是随意的。

2. 创建瓦片树

Cesium3DTileset 类代表了一个 3DTiles 数据集，每个数据集总是有一个根瓦片（Cesium3DTile）。

Cesium3DTileset 同旧版 Model、新的 ModelExperimental 类一样，也是一种“似 Primitive（PrimitiveLike）”类，所以允许直接加入 scene.primitives 容器中。

下面给出一些简单的代码：

import {
  Cesium3DTileset
} from 'cesium'

// 最常规的加载
const t1 = viewer.scene.primitives.add(new Cesium3DTileset({
  url: 'http://localhost/static/tilesets/t1/tileset.json'
}))

// 使用新模型架构加载具备下一代数据标准的数据集
const t2 = viewer.scene.primitives.add(new Cesium3DTileset({
  url: 'http://localhost/static/tilesets/t2/entry.json',
  enableModelExperimental: true
}))

2.1. 请求入口文件

一旦 new 了 Cesium3DTileset，那么就会穿过接近 1000 行的构造函数（未压缩），走到最后的异步请求：

function Cesium3DTileset(options) {
  const that = this;
  let resource;
  this._readyPromise = Promise.resolve(options.url)
    .then(function (url) {
      /* ... */
      resource = Resource.createIfNeeded(url);
      /* ... */
      return Cesium3DTileset.loadJson(resource);
    })
    .then(function (tilesetJson) {
      /* ... */
      return processMetadataExtension(that, tilesetJson);
    })
    .then(function (tilesetJson) {
      /* ... */
      that._root = that.loadTileset(resource, tilesetJson);
      /* ... */
      return that;
    })
}

在第 1 个 then 中，调用 Resource 类相关静态方法，发起网络请求，得到的结果就是 tileset.json 的对象，然后向下传递；

第 2 个 then 是处理 3DTILES_metadata 扩展用的，这个不是本文的核心内容：3DTiles 在 CesiumJS 中的运作流程，所以略过。

第 3 个 then，调用 Cesium3DTileset 实例的 loadTileset 方法，加载整棵 3DTiles 树，也就是下一小节的内容。

2.2. 创建树结构

接上一小节，请求到入口文件并反序列化为 JavaScript 对象后，就由 Cesium3DTileset.prototype.loadTileset 方法开始创建整棵树了。

我一开始纳闷为什么这种加载方法要作为实例方法，而不是静态方法，后来看到 ExternalTileset 的加载过程时才知道这样设计的意图。

先看代码吧：

Cesium3DTileset.prototype.loadTileset = function (/**/) {
  const asset = tilesetJson.asset;
  if (!defined(asset)) {
    throw new RuntimeError("Tileset must have an asset property.");
  }
  if (
    asset.version !== "0.0" &&
    asset.version !== "1.0" &&
    asset.version !== "1.1"
  ) {
    throw new RuntimeError(
      "The tileset must be 3D Tiles version 0.0, 1.0, or 1.1"
    );
  }
  if (defined(tilesetJson.extensionsRequired)) {
    Cesium3DTileset.checkSupportedExtensions(
      tilesetJson.extensionsRequired
    );
  }
  
  /* ... */
  const rootTile = makeTile(this, resource, tilesetJson.root, parentTile);
  
  if (defined(parentTile)) {
    parentTile.children.push(rootTile);
    rootTile._depth = parentTile._depth + 1;
  }
  
  const stack = [];
  stack.push(rootTile);
  while (stack.length > 0) {
    /* ... */
    const children = tile._header.children;
    if (defined(children)) {
      const length = children.length;
      for (let i = 0; i < length; ++i) {
        /* ... */
        const childTile = makeTile(this, resource, childHeader, tile);
        tile.children.push(childTile);
        stack.push(childTile);
      }
    }
    /* ... */
  }
  
  return rootTile;
}

创建树结构主要有三块内容：

• 检验数据合法性
• 创建根瓦片对象
• 从根瓦片开始广度优先搜索整个数据集，创建出所有的 Cesium3DTile

检验数据合法性是近一年来加强的，对版本号、扩展项做了严格的要求。

老实说，这就是 1.0 的性能隐患，如果不使用 ExternalTileset，而把大量的瓦片定义在 tileset.json 上，那么这个广度优先搜索就非常消耗 CPU 的计算资源。下一代的 3DTiles 使用隐式瓦片扩展解决了这个性能弱点。

无论是创建根瓦片，还是创建子瓦片对象，都要经过模块内的 makeTile 函数：

function makeTile(tileset, baseResource, tileHeader, parentTile) {
  const hasImplicitTiling =
    defined(tileHeader.implicitTiling) ||
    hasExtension(tileHeader, "3DTILES_implicit_tiling");
  
  if (hasImplicitTiling) {
    /* ... */
  }
  
  return new Cesium3DTile(tileset, baseResource, tileHeader, parentTile);
}

其实这个函数的主要作用还是分辨下一代 3DTiles 的隐式瓦片用的，也就是判断是否有 3DTILES_implicit_tiling 扩展，如果没有，直接返回 new 出来的 Cesium3DTile 对象即可。

来看看隐式瓦片这个逻辑分支做了什么：

if (hasImplicitTiling) {
  const implicitTileset = new ImplicitTileset(/* ... */);
  const rootCoordinates = new ImplicitTileCoordinates({/* ... */});
  const contentUri = implicitTileset.subtreeUriTemplate.getDerivedResource(
    templateValues: rootCoordinates.getTemplateValues(),
  ).url;
  
  const deepCopy = true;
  const tileJson = clone(tileHeader, deepCopy);
  tileJson.contents = [
    {
      uri: contentUri,
    },
  ];

  delete tileJson.content;
  delete tileJson.extensions;
  
  const tile = new Cesium3DTile(
    tileset, baseResource, tileJson, parentTile
  );
  tile.implicitTileset = implicitTileset;
  tile.implicitCoordinates = rootCoordinates;
  return tile;
}

其实也是返回一个 Cesium3DTile，但是它多了俩专门用于隐式瓦片扩展的字段，分别是 ImplicitTileset 和 ImplicitCoordinates。

待所有瓦片对象创建完毕后，那么 Cesium3DTileset 对象也就算创建完成了，此时也只有这棵树的结构，没有瓦片内容。瓦片内容是根据当前视图状态，随 Scene 的单帧更新过程去选取、下载、解析，进而创建 DrawCommand 的。

2.3. 瓦片缓存机制带来的能力

3DTiles 也是有缓存功能的，由 Cesium3DTilesetCache 类完成缓存，它的实例是 Cesium3DTileset 的一个成员字段 _cache。

在本文下一节将会讲到 3DTiles 的更新过程，有三大步骤，其中有一个叫做“请求瓦片”的步骤，这一步是异步的，用到了 ES6 Promise API，当瓦片内容文件请求、解析完成后，在 tile.contentReadyPromise 的 then 链中就使用下面这个函数将瓦片对象添加到缓存池中：

function handleTileSuccess(tileset, tile) {
  return function (content) {
    /* ... */
    if (!tile.hasTilesetContent && !tile.hasImplicitContent) {
      /* ... */
      tileset._cache.add(tile);
    }
  }
}

这个缓存机制有什么用呢？

翻遍源代码，能在即将在下面介绍的遍历器中、卸载瓦片的过程中用到这个缓存池，这样就能免于再次搜索哪些瓦片需要被卸载了。

此处的缓存机制只是缓存瓦片对象的引用。对于在内存中瓦片文件的缓存，请看本系列文章的上一篇，我介绍了 ModelExperimental 新架构中的缓存机制，那里缓存的 ResourceLoader 上才会有资源数据。

3. 瓦片树的遍历更新

3.1. 三个大步骤

伴随着 Scene 的帧更新过程，Cesium3DTileset 也一起进入更新、创建 DrawCommand 的队伍中。

很快就从 Cesium3DTileset.prototype.update 方法进入到 Cesium3DTileset.prototype.updateForPass 方法。先点题，updateForPass 方法会进入到模块内的函数 update 内，由如下三个大步骤完成 3DTiles 树上的瓦片的选择、请求解析、更新：

方法 updateForPass 里头有一个值得注意的变量，那就是传进来的参数：来自 frameState 的 tilesetPassState，类型是 Cesium3DTilePassState，它身上携带了一个字段：

• pass，是 Cesium3DTilePass 枚举，指示 3DTiles 更新时是哪一道通道的

这个字段用于在更新时获取 passOptions：

Cesium3DTileset.prototype.updateForPass = function (
  frameState,
  tilesetPassState
) {
  const pass = tilesetPassState.pass;
  /* ... */
  const passOptions = Cesium3DTilePass.getPassOptions(pass);
  /* ... */
}

在普通渲染更新过程中，字段 pass 的值就是 Cesium3DTilePass.RENDER，此时 passOptions 根据源码可以得知：

const Cesium3DTilePass = {
  RENDER: 0,
  PICK: 1,
  SHADOW: 2,
  PRELOAD: 3,
  PRELOAD_FLIGHT: 4,
  REQUEST_RENDER_MODE_DEFER_CHECK: 5,
  MOST_DETAILED_PRELOAD: 6,
  MOST_DETAILED_PICK: 7,
  NUMBER_OF_PASSES: 8,
};

const passOptions = new Array(Cesium3DTilePass.NUMBER_OF_PASSES);

passOptions[Cesium3DTilePass.RENDER] = Object.freeze({
  traversal: Cesium3DTilesetTraversal,
  isRender: true,
  requestTiles: true,
  ignoreCommands: false,
});

/* 其他 passOptions */

Cesium3DTilePass.getPassOptions = function (pass) {
  return passOptions[pass];
};

passOptions 会透过 Cesium3DTileset.js 模块内的函数 update，一直传递到瓦片内容的选择、请求、更新这几个流程：

// Cesium3DTileset.prototype.updateForPass 中
if (this.show || ignoreCommands) {
  this._pass = pass;
  tilesetPassState.ready = update(
    this,
    frameState,
    passStatistics,
    passOptions
  );
}

这个 update 函数大致可以分这 3 个流程，图已经在本小节开头给到了：

function update(tileset, frameState, passStatistics, passOptions) {
  /* ... */
  const ready = passOptions.traversal.selectTiles(tileset, frameState);
  if (passOptions.requestTiles) {
    requestTiles(tileset);
  }

  updateTiles(tileset, frameState, passOptions);
  /* ... */
  return ready;
}

不过，在讲这 3 个流程进行讲解之前，还得提一下 passOptions 上的 traversal 成员。

3.2. 遍历器

上一小节的 passOptions 来自 Cesium3DTilePass.js 模块，内部定义的若干个 passOption 中，只有两种 traversal 的值，即：

• Cesium3DTilesetTraversal
• Cesium3DTilesetMostDetailedTraversal

这两个静态类作用于 update 函数的第一个重要步骤，也就是选择瓦片。

passOptions 上这个 traveral 被称作“遍历器”。设计这两个类，是因为 3DTiles 瓦片的空间调度选择较为复杂，独立到一个类中。

我对全代码进行了搜索，发现用到 Cesium3DTilesetMostDetailedTraversal 的逻辑分支条件是使用射线求交拾取相关的 API 时，才会用到这个“详尽遍历器”，大多数时候用的还是普通的遍历器 Cesium3DTilesetTraversal。

3.3. 选择瓦片

现在，把视线从遍历器上返回 Cesium3DTileset.js 模块内的 update 函数中，一句简单的代码就启动了瓦片的选择：

// Cesium3DTileset.js
function update(/* ... */) {
  /* ... */
  const ready = passOptions.traversal.selectTiles(tileset, frameState);
  /* ... */
  return ready;
}

现在明确瓦片选择的目的：把符合当前 3DTiles 数据集上各种优化参数的前提下，选出当前视角下要用于加载、解析（如果未加载和未解析），并继续沿着更新流程创建 DrawCommand 的 Cesium3DTile，挂载到 Cesium3DTileset 对象的 _requestTiles 这个数组成员上。

3.2 小节指出了大多数时候 passOptions.traversal 是 Cesium3DTilesetTraversal。调用 traversal.selectTiles() 方法的主要流程可由下面的流程示意图给出：

更新瓦片信息是第一步，此更新非“更新瓦片的内容数据”，只是更新瓦片对象（Cesium3DTile）的状态信息，主要是可见性计算。

第二步是依据前一步更新的状态，进行从根瓦片到底的遍历（此处有三个逻辑分岔，见源码），这一步就是最核心的调度算法；

第三步就是为选出来的瓦片计算其优先值，优先值越高的，越先被加载、渲染。

由于调度算法并不是本文的目的，所以止步到这一层我认为已足够，感兴趣如何计算 Tile 的可见性、如何被选择，优先顺序如何计算的读者，可以按这一层继续往下追踪源码。

3.4. 请求并解析瓦片内容

接上一步，被选中的瓦片已经存至 Cesium3DTileset 对象的 _requestTiles 数组成员上了，并计算了优先值，即 Cesium3DTile 对象的 _priority 私有成员上，是一个普通的数字。

紧接着，作用域回到 Cesium3DTileset.js 模块内的 update 函数里头，继续执行模块内的 requestTiles 函数：

// Cesium3DTileset.js -> function update()
if (passOptions.requestTiles) {
  requestTiles(tileset);
}

这个 requestTiles 函数只做了两件事：根据优先值排序，并请求瓦片内容：

function requestTiles(tileset, isAsync) {
  const requestedTiles = tileset._requestedTiles;
  const length = requestedTiles.length;
  requestedTiles.sort(sortRequestByPriority);
  for (let i = 0; i < length; ++i) {
    requestContent(tileset, requestedTiles[i]);
  }
}

那么进入到 requestContent 函数中，主要的代码就这几个：

function requestContent(tileset, tile) {
  /* ... */
  
  const attemptedRequests = tile.requestContent();
  
  /* ... */
  
  tile.contentReadyToProcessPromise
    .then(addToProcessingQueue(tileset, tile))
    .catch(/* ... */);
  tile.contentReadyPromise
    .then(handleTileSuccess(tileset, tile))
    .catch(/* ... */);
}

即发起内容请求，并为瓦片对象上的 contentReadyToProcessPromise 和 contentReadyPromise 这两个 Promise 注册 resolve 和 reject 的回调函数。

至此，当前帧的大流程已经基本完成，即选择瓦片、发出请求瓦片内容。有人说请求完了应该要解析啊？是要解析没错，ES6 Promise API 又派上了用场。

从上面的两个 Promise 可以看出，瓦片内容 - 也就是 glTF 瓦片、b3dm/i3dm/pnts/cmpt 等瓦片数据文件请求下来后，还要经过 contentReadyToProcessPromise 中的代码进行处理的。

那么 contentReadyToProcessPromise 又是什么时候，由谁创建的呢？顺着 Cesium3DTile.js 模块中的 requestSingleContent 函数或者 requestMultipleContents 函数，你可以看到这个 Promise 的创建（以其一举例）：

function requestSingleContent(tile) {
  const resource = tile._contentResource.clone();
  /* ... */
  const promise = resource.fetchArrayBuffer();
  const contentReadyToProcessPromise = promise.then(function (arrayBuffer) {
    /* ... */
    const content = makeContent(tile, arrayBuffer);
    /* ... */
    tile._content = content;
    tile._contentState = Cesium3DTileContentState.PROCESSING;
    return content;
  });
  tile._contentReadyToProcessPromise = contentReadyToProcessPromise;
  tile._contentReadyPromise = contentReadyToProcessPromise
    .then(function (content) {/**/})
    .then(function (content) {/**/})
    .catch(/**/);
  
  return 0;
}

可见，请求到 ArrayBuffer 后，进入 makeContent 函数进一步处理瓦片内容，生成对应的 Content 类实例。requestMultipleContents 函数就稍微复杂一些。

用代码流程图来说明，比代码文字好一些：

可见，CesiumJS 对下一代 3DTiles 中“多内容瓦片（1.0 版本中即 3DTILES_multiple_contents 扩展）”还是做了分叉的，对每一个 content 发起请求，留下其请求 Promise，然后使用 Promise.all 并发处理；当每个 Promise resolve 后，调用 createInnerContent 函数，对请求下来的 ArrayBuffer 数据，进入简单工厂 Cesium3DTileContentFactory 分支，创建具体的瓦片内容对象。

如果是单个瓦片内容，如上文所述，走的是 requestSingleContent 函数，当内容文件的请求 Promise resolve 后，调用 makeContent 方法，同样进入 Cesium3DTileContentFactory 工厂中对应的分支，创建具体的瓦片内容对象。

如果是 glb/gltf，且开启了 tileset.enableModelExperimental 为 true，那么就能看到上一篇熟悉的 ModelExperimental 的创建了。b3dm、i3dm 等也同理。

subt、subtreeJson 是下一代 3DTiles 中隐式瓦片（1.0 版本中的 3DTILES_implicit_tiling 扩展）中子树的可见性数据，详见 3DTiles 相关资料。

别忘了，不管是单内容瓦片执行 makeContent 后，还是多内容瓦片执行 createInnerContent 后，也就是请求到瓦片内容文件、解析成具体内容类后，都会留下 contentReadyToProcessPromise、contentReadyPromise 两个 Promise，供进一步处理。

进一步处理什么呢？此时该选择的瓦片选好了，该请求的瓦片请求到了，也解析了，当然就是要 处理成 DrawCommand，供 Renderer 模块去渲染。在说创建 DrawCommand 之前，我先把本节讲解的“三大步骤”中最后一个步骤，也就是 updateTiles 函数讲完，随后再说是如何创建每个被选中的瓦片的 DrawCommand 的。

3.5. 更新瓦片并创建 DrawCommand

三大步骤中的最后一个步骤：

// Cesium3DTileset.js

function update(tileset, frameState, passStatistics, passOptions) {
  /* ... */
  updateTiles(tileset, frameState, passOptions);
  /* ... */
}

function updateTiles(tileset, frameState, passOptions) {
  /* ... */
  const selectedTiles = tileset._selectedTiles;
  const selectedLength = selectedTiles.length;
  /* ... */
  
  let i;
  let tile;
  
  for (i = 0; i < selectedLength; ++i) {
    /* ... */
    tile.update(tileset, frameState, passOptions);
    /* ... */
  }
  
  /* ... */
}

这个步骤没有太多很关键的行为，只是更新一些状态信息、可有可无的效果（例如裁剪面、调试信息等），最终调用 tile._content 的 update 方法，进而创建 DrawCommand 或其它的 Command，总之很常规。

至此，3DTiles 三大步骤，从选择瓦片，到发起请求解析瓦片内容，到更新瓦片状态并随之创建内容在当前帧的 DrawCommand，一切都顺利。期间，ES6 Promise API 配合各个数据对象上的状态机制，来判断在当前帧是否该做什么 —— 譬如某个数据状态得是 READY，才有资格创建 DrawCommand。

3.6. prePassesUpdate 也能创建 DrawCommand

承 3.4 小节，瓦片内容文件请求下来、解析后，相关 Promise 的 then 链最终扔给 Cesium3DTile 对象的 _contentReadyToProcessPromise 成员，随后继续第三个大步骤，更新瓦片的状态后创建 DrawCommand，结束当前帧的战斗。

但是，我发现 Cesium3DTileset 这货有那么一丢丢不一样，它有两条路线可以创建 DrawCommand。

回忆本系列文章第二篇的内容，也就是 Scene 渲染 Primitive、创建出 DrawCommand 的内容，创建 DrawCommand 是在 下面这段函数调用中执行的：

function updateAndRenderPrimitives(scene) {
  const frameState = scene._frameState;
  /* ... */
  scene._primitives.update(frameState);
  /* ... */
}

也就是 PrimitiveCollection 会触发 Primitive 或似 Primitive（例如 Cesium3DTileset、Model 等）的更新，进而创建出 DrawCommand。

注意，Scene 会在 render 之前走一遍 prePassesUpdate：

Scene.prototype.render = function (time) {
  /* ... */
  tryAndCatchError(this, prePassesUpdate);
  if (shouldRender) {
    /* ... */
    tryAndCatchError(this, render);
  }
  /* ... */
}

function prePassesUpdate(scene) {
  /* ... */
  const primitives = scene.primitives;
  primitives.prePassesUpdate(frameState);
  /* ... */
}

也就是会调用 Cesium3DTileset.prototype.prePassesUpdate，最终会调用 Cesium3DTile.prototype.process 方法：

Cesium3DTile.prototype.process = function (tileset, frameState) {
  /* ... */
  this._content.update(tileset, frameState);
  /* ... */
};

这时，对 Tile 上的 content 进行 update，也就是继续进入创建 DrawCommand 的过程，与 3.5 小节的最终目的一致了。

创建 DrawCommand 并不一定是 Primitive.prototype.update 发起的。更新 Primitive 可能是 Scene.js 模块下的 render 函数发起的，也有可能是 prePassesUpdate 函数发起的。所以，似 Primitive 的 postPassesUpdate 方法也有可能创建 DrawCommand。当然，目前也只有 Cesium3DTileset 拥有 postPassesUpdate，可见 3DTiles 的渲染优先级之高。

3.7. 自定义着色器

自定义着色器是 ModelExperimental 新架构带来的 API，即 CustomShader API，在发文时，Cesium 1.95 还是需要显式指定使用新架构，才能使用这个自定义着色器，官方沙盒中也有相关的代码。

这里简单提一下它的作用过程。

自定义着色器虽然定义在 Cesium3DTileset 实例上，但是作用却是在 ModelExperimental 上，见 ModelExperimental3DTileContent：

ModelExperimental3DTileContent.prototype.update = function (
  tileset,
  frameState
) {
  const model = this._model;
  /* ... */
  model.customShader = tileset.customShader;
  model.update(frameState);
};

于是，你就能在 ModelExperimental.prototype.update 方法中看到自定义着色器是如何更新场景图结构对象的了：

function updateCustomShader(model, frameState) {
  if (defined(model._customShader)) {
    model._customShader.update(frameState);
  }
}

ModelExperimental.prototype.update = function (frameState) {
  /* ... */
  // A custom shader may have to load texture uniforms.
  updateCustomShader(this, frameState);
  /* ... */
};

具体的内容还是得到 CustomShader.prototype.update 方法里看。在着色器方面的实现上，用的就是上一篇提到的“阶段”技术，选择性地在着色器代码中增加的。

// ModelExperimentalVS.glsl
void main() 
{
    // ...
    Metadata metadata;
    metadataStage(metadata, attributes);

    #ifdef HAS_CUSTOM_VERTEX_SHADER
    czm_modelVertexOutput vsOutput = defaultVertexOutput(attributes.positionMC);
    customShaderStage(vsOutput, attributes, featureIds, metadata);
    #endif
  
    // ...
}

片元着色器上也有类似的，customShaderStage 函数在 CustomShaderStageVS/FS.glsl 文件中。

3.8. 样式引擎

CesiumJS 使用 Cesium3DTileStyle 相关 API 来实现 3DTiles 的样式化。用法不赘述，有专门的文档：[点我](https://github.com/CesiumGS/3d-tiles/tree/main/specification/Styling|3D Tiles Styling language)

在这里列出，主要是明确它的作用方式：

// Cesium3DTileset.js

function updateTiles(tileset, frameState, passOptions) {
  tileset._styleEngine.applyStyle(tileset);
  /* ... */
}

显然，是在三大步骤的最后一个步骤应用的样式。

Cesium3DTileStyleEngine.prototype.applyStyle = function (tileset) {
  const tiles = styleDirty
    ? tileset._selectedTiles
    : tileset._selectedTilesToStyle;
  const length = tiles.length;
  for (let i = 0; i < length; ++i) {
    const tile = tiles[i];
    if (tile.lastStyleTime !== lastStyleTime) {
      const content = tile.content;
      /* ... */
      content.applyStyle(this._style);
      /* ... */
    }
  }
};

content.applyStyle 只是简单地将 _style 传递给 content 实例，最终还是随 content 实例的 update 方法应用到 DrawCommand 上的。

Cesium3DTileStyle 既可以应用于 3DTiles，也可以应用于 ModelExperimental。它条件样式语言的作用前提是，在 3DTiles /模型中存在 3D 要素表，这是在制作数据时就必须写入的。

3.9. 其它

篇幅原因，有一些相对简单又零碎，或者不属于本文关注的内容，例如事件机制、裁剪平面、几何误差等就不再展开了，以后可以出一些单文来讲。

4. 本文总结

其实本文没写什么很深入的内容，只把创建树、处理瓦片的全流程，以及一些零碎点提炼了出来，希望对读者有帮助。

截至发文，3DTiles 已经应用了有六七年了，也看到了 Cesium 团队为此付出的努力。

不好看？卡顿？确实有点，但是已经在努力了。下一代的 3DTiles 真的值得期待！

我认为，3DTiles 规范只是一种大规模空间三维数据的组织指导资料。它本身没有指导你怎么制作 LOD，也没有告诉你该如何把你的业务需求（分层分户、单体化、点击查询）如何塞到瓦片里，这都需要数据生产开发者的不懈努力，把 GPUPicking、Batch、数据调优手段都用起来，那么 3DTiles 与 glTF 才能焕发出强大的能力，CesiumJS 作为一个前端运行时，它在调优上已经做得很不错了。

简单总结如下：

• 亮点：缓存机制
• 难点：选择调度算法
• 架构设计优点：平稳的接入了下一代 3DTiles 的同时还兼容了 1.0 版本

至此，CesiumJS 源码解读系列已经接近尾声，还有一篇关于资源处理和网络请求、多线程的文章，下篇见。

__EOF__