xiaohujx的博客

虽然说 颜色编码 在GPU拾取中并不是最好的方案, 但Cesium本身从Real-Time Rendering角度架构设计, 对 颜色编码 做了很多优化方案: 诸如: Scissor Test, Culling Volumn等 弥补 颜色编码在超大场景中可能频繁Draw Call带来的通信成本。这里提到了坐标转换, 本人向提一嘴之前写的一个library, 类似于 babylon 的 gizmo, 有兴趣的话可以研究一下, 点个star。本篇来聊聊Cesium应用的两种拾取方式: 颜色编码, 深度缓存。

前两篇说的批量渲染和本篇说的顶点压缩都是为了优化三维渲染, 提升三维实时渲染的效率, 而两者的侧重点不一样: 批量渲染是为了减少 CPU 与 GPU之间的沟通次数, 而顶点压缩的最大收益点在于减轻内存带宽的压力。是由八个全等的三角形构成的多面体, 数学上，一个常见的描述方法是定义满足 ∣x∣+∣y∣+∣z∣ <= 1的所有点构成一个凸体，而其边界（表面）则正好是满足 ∣x∣+∣y∣+∣z∣ = 1。尤其是在处理大量的三维数据时，如法线、光照方向等，如何有效压缩这些向量信息，成为了一个长期面临的挑战。

3DTile 与前两张说的 Primitive 与 Model 部分不同了, BatchTable 与 BatchTexture都会使用到, 且不同类型的 3DTile 使用了不同的 数据处理方案。在Cesium渲染引擎中, Primitive, Model 及 3DTile 作为主要的数据载体, 他们的应用场景不同, 因此他们对属性数据的管理与渲染都不太相同。这三个类处理的相关瓦片内容没有维护相关瓦片的”属性数据“。复合瓦片（可以包含多个不同的 3D Tiles 类型）这三个是如何处理瓦片属性数据的。

而 Model 部分的 BatchTexture 则更专注于管理颜色、显示和拾取等样式数据，针对 glTF 模型的需求进行了专门优化。在批量渲染时的数据的处理上, 虽然 Primitive 和 Model 的核心都是将 属性纹理化, 但还是有一些不同的, 一个Primitive只会使用一张Texture去管理相关的实例属性, 但是 一个 gltf/glb 可能需要多张Texture去管理结构化数据。本节就到这里, 下节会着重说说 3dtiles的 batchTable处理。来看一下处理属性数据的相关代码。

在大规模 3D 数据渲染中，为了在批量合并几何体的同时支持对单个图元（feature）的交互与动态样式控制，3D Tiles 提出了 BatchTable 机制。

在 3D 渲染过程中，顶点数据通常会被频繁访问，如何有效地利用 GPU 的顶点缓存（Vertex Cache）来减少对同一顶点的重复处理，是提升渲染效率的一个重要手段。针对这一需求，业界普遍采用顶点缓存优化算法来重新排序网格的索引数据（Index Buffer），从而尽量让相邻的三角形复用最近使用过的顶点。Tipsify便是此类算法中的一种常见实现。

再想了解里面的使用方法时, 发现这个不是开源的... 原本想花钱买来他的license研究研究源码学习学习, 但官方告知, 目前 还 不对中国开放...因为之前是开发Babylon.js和Three.js的, 所以多少会接触编辑三维实体的业务,但它俩都有相应的工具gizmo和transformer.在接触了cesium之后, 也遇到了类似需要编辑primitive的场景, 所以就在网上找有没有类似的工具.): 元素的包围球, 此为必填项, 需要计算大小坐标的相对位置.): 添加元素的容器.