3DTiles 与 I3S 是竞争关系,可是比起生态开放性、数据定义的灵活性与易读性来说,3DTiles 比 I3S 好太多了。由于数据生产工具的开发者水平参差不齐,且数据并不存在极致的、万能的优化方法,故 3DTiles 1.0 时代的一些工具可能导致的数据渲染质量问题,让 3DTiles 的性能、显示效果颇受争议。
随着 CesiumJS 模型新架构的逐渐成型,下一代的 3DTiles 首先以 1.0 的扩展项测试使用,待日后时机成熟,会将 1.0 的规范标记为过时,甚至直接废弃,直接将这些扩展项作为 1.1 版本的核心定义使用(估计还挺久的)。
下一代 3DTiles 明确了这套规范的职能,即 更自由的显示效果可能性、更专注地三维空间索引性能、更强大的信息融合能力。
唠叨有点长,开始讲解,本文着重介绍的是“3DTiles”在 CesiumJS 中运作流程本身,而不是瓦片文件的解析(解析有兴趣的可以看本系列文章的上一篇,或者看旧版实现)、瓦片的空间调度算法、3DTiles 着色器设计。
3DTiles 1.0 规范允许异构数据共存于一个数据集上。3D 瓦片只是空间划分的单元,并不是该块三维空域内的具体三维物体。这些三维物体被称作“瓦片内容”。
1.0 允许存在 7 种瓦片内容,它们的文件后缀名是:
ExternalTileset
),即允许瓦片空域内再嵌套一个子 3DTiles而 1.0 的扩展项,也就是下一代标准增加了一种瓦片格式:
值得注意的是,社区提案中,延申了 geojson 为瓦片内容文件,也就是说,在未来也许有可能引入更多的瓦片格式,但是能不能成为官方标准还不一定,暂且以 1.0 + 下一代的 glTF 格式为主要解说点。
而 3DTiles 一切的入口,都是从一个 json 文件开始的,这个文件名称是随意的。
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
}))
一旦 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 树,也就是下一小节的内容。
接上一小节,请求到入口文件并反序列化为 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 的。
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 上才会有资源数据。
伴随着 Scene
的帧更新过程,Cesium3DTileset
也一起进入更新、创建 DrawCommand 的队伍中。
很快就从 Cesium3DTileset.prototype.update
方法进入到 Cesium3DTileset.prototype.updateForPass
方法。先点题,updateForPass
方法会进入到模块内的函数 update
内,由如下三个大步骤完成 3DTiles 树上的瓦片的选择、请求解析、更新:
方法 updateForPass
里头有一个值得注意的变量,那就是传进来的参数:来自 frameState 的 tilesetPassState
,类型是 Cesium3DTilePassState
,它身上携带了一个字段:
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
成员。
上一小节的 passOptions
来自 Cesium3DTilePass.js
模块,内部定义的若干个 passOption 中,只有两种 traversal
的值,即:
Cesium3DTilesetTraversal
Cesium3DTilesetMostDetailedTraversal
这两个静态类作用于 update
函数的第一个重要步骤,也就是选择瓦片。
passOptions
上这个 traveral
被称作“遍历器”。设计这两个类,是因为 3DTiles 瓦片的空间调度选择较为复杂,独立到一个类中。
我对全代码进行了搜索,发现用到 Cesium3DTilesetMostDetailedTraversal
的逻辑分支条件是使用射线求交拾取相关的 API 时,才会用到这个“详尽遍历器”,大多数时候用的还是普通的遍历器 Cesium3DTilesetTraversal
。
现在,把视线从遍历器上返回 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 的可见性、如何被选择,优先顺序如何计算的读者,可以按这一层继续往下追踪源码。
接上一步,被选中的瓦片已经存至 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 的。
三大步骤中的最后一个步骤:
// 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.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 的渲染优先级之高。
自定义着色器是 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
文件中。
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 要素表,这是在制作数据时就必须写入的。
篇幅原因,有一些相对简单又零碎,或者不属于本文关注的内容,例如事件机制、裁剪平面、几何误差等就不再展开了,以后可以出一些单文来讲。
其实本文没写什么很深入的内容,只把创建树、处理瓦片的全流程,以及一些零碎点提炼了出来,希望对读者有帮助。
截至发文,3DTiles 已经应用了有六七年了,也看到了 Cesium 团队为此付出的努力。
不好看?卡顿?确实有点,但是已经在努力了。下一代的 3DTiles 真的值得期待!
我认为,3DTiles 规范只是一种大规模空间三维数据的组织指导资料。它本身没有指导你怎么制作 LOD,也没有告诉你该如何把你的业务需求(分层分户、单体化、点击查询)如何塞到瓦片里,这都需要数据生产开发者的不懈努力,把 GPUPicking、Batch、数据调优手段都用起来,那么 3DTiles 与 glTF 才能焕发出强大的能力,CesiumJS 作为一个前端运行时,它在调优上已经做得很不错了。
简单总结如下:
至此,CesiumJS 源码解读系列已经接近尾声,还有一篇关于资源处理和网络请求、多线程的文章,下篇见。
版权说明 : 本文为转载文章, 版权归原作者所有 版权申明
原文链接 : https://www.cnblogs.com/onsummer/p/16432909.html
内容来源于网络,如有侵权,请联系作者删除!