非常抱歉，比原计划推迟了一个月左右，而且现在仅发布了一个内测版本，如遇bug还望海涵并及时反馈给我们，以及用得不爽的地方可随时吐槽。

不过 CesiumLab3终于来了，相较Lab2有以下几大方面的革新。

CesiumLab3 已经废弃了使用electron 的方式。electron本身是很优秀的框架，而且也比较适合做工具类产品的界面，但是为了扩大CesiumLab3的使用便利性，我们决定还是废弃electron，直接把Lab3 做成一个服务型的工具，也就是Lab3可以部署在局域网里，同事通过局域网网页页面来操作，进行数据处理。也可以部署在公网上，相当于把cesium ion搬到了自己的服务器上一样。这样希望大家明白，CesiumLab3绝不是一个单机程序，而是一个小型可私有化部署的云服务。

一，分发服务

Lab1的分发服务当时用java写的，因为部署麻烦，还需要安装jdk，所以我们升级到了Lab2，Lab2的服务是基于nodejs（electron）来写的，这样极大方便了本地数据的测试预览。但是到了Lab3，对于分发服务，我们不能再停留在仅仅是做为预览使用，我们要考虑服务性能，并发等等。所以Lab3的服务，实际做了多进程处理，可以支持更大并发访问需求。除了性能外，还有如下的功能改进：

1，影像服务

除了原有的普通分发服务外，我们新加了实时缓存影像服务和影像集合。

实时缓存影像服务是对其他影像服务的代理和缓存（pak），当请求此服务的切片时，首先从缓存中查找影像切片，若不存在则从其他影像服务下载该切片，返回给客户端并缓存到pak中。CesiumLab3去掉了影像下载功能（因为有很多问题），实时缓存影像服务在一定程度上可以代替影像下载功能。

影像集合可以将多个影像服务合并成一个服务，当请求此服务的切片时，按顺序从影像集合中查找切片，若存在则返回，若不存在则查找下一个。类似于图层组。但目前没有对透明切片进行融合，导致影像边缘空洞，未来如果该功能使用率比较高的话，可以考虑进行融合。

2，地形服务

与影像服务一样新加了实时缓存地形服务和地形集合。功能也和影像服务一致。

二，数据处理

数据处理一直是CesiumLab的基础核心功能，这次的改进有：

1， 倾斜模型切片

1）更新内容

结束了CesiumLab2.3 版本里 倾斜V3 和 V4的长期共存的局面，这次终于可以和v3说再见了。V4相比V3，主要是小osgb文件的合并，以及json索引文件的合并，不会出现很多json请求的情况。此外几个重要的更新：

A， 革新了 顶层重建算法

处理过程不再像V3一样依赖GPU， 经过超过200GB的数据测试，算法效果要优于V3。

B， 解决V4处理下一些数据没有到最高精度，以及某些数据块缺失（尤其修复过的数据）的问题。

倾斜处理的优化到这里也算是基本完善了。

2）多块倾斜处理的流程：

第一步，使用倾斜模型切片，对一个Data使用倾斜模型切片得到一个3dtiles

第二步，使用索引合并工具对  你项目里需要一次性引入的，并且是第一步得到的多个3dtiles ，放在同一级目录下。使用我们提供的索引合并工具 ，得到一个总览的 tileset.json 文件，并在你项目里引用这个总览的tileset.json

第二步并没有做任何数据上的额外优化，仅仅是把多个倾斜索引合在一起，这么做也是有意义的，因为Cesium的3dtiles 最大缓存（maximumScreenSpaceError）是对 每个tileset设置的。这种引用一个总览tileset.json ，比引用多个tileset.json来说，缓存的调度合适一些，也可以加速淘汰看不见的 倾斜块。

 

3）顶层重建的数据要求：

仅限一个 Data 目录下，采用四叉树或者八叉树分Tile的结构，目录类似如下结构的, 一般常见是 context capture输出的结构:

               

       

               

    目前我们见过的Tile结构比较多样，诸如下述，都无法进行顶层重建

                   

                       

       

                             

               

         

              

                                                                                                        

 4) 处理过程的时间问题

       处理过程分两个大阶段

       A， 原始osgb优化阶段，默认参数下，一般这个阶段 15G 每小时

              如果选了ktx2格式压缩，那么这块可能是  0.5G / 每小时

               

     B ，顶层重建过程， 这个时间消耗，是根据Tile的个数多少来定的

            需要重建的次数大约 =  Tile的个数 * 0.6

            单次重建的次数大约是 0.5分钟

            比如一个Data下有1000块，那么重建顶层的时间消耗  =  1000*0.6 * 0.5 = 300分钟 ，也就是5个小时

2， 通用模型处理

根据我们统计，用户频度最高的两个工具，一个是倾斜，一个是通用模型处理

通用模型处理里反馈问题最多的是八叉树处理器

关于八叉树LOD ，我们需要澄清一个误区：

数据不是带了LOD就更优，加载更平滑，渲染更高效。尤其你数据总量就1G左右，那其实更应该选择小场景，小场景不带LOD，可以通过其他的优化手段来最快速加载数据，展示效果和效率基本和建模的精度相当。对于小数据建了LOD，可能大多情况下都是多此一举，没必要绕弯子。

当数据实在是无法用小场景加载，再考虑采用我们的八叉树处理器来创建LOD，创建LOD是个算法要求很高的过程，直到当前的Lab3，我们也无法宣称这个算法很完美，它依然不能应对不限量的数据加载。

1）八叉树LOD策略

创建LOD有很多策略，比如以前做数字城市的时候根据建筑对象，每个建筑去生成lod，然后每个建筑根据远近单独调度。但是我们既然这个工具叫通用模型处理，那么其实也就表示，我们的LOD策略需要更通用一些。我们无法预先知道用户的数据是建筑还是道路或者是很精细的BIM模型，甚至是某种设备模型。所以我们采用了一种最简单最直接的处理方式：

严格按照八叉树分块边界对数据分块，然后每块内尝试简化。

这种LOD策略简单暴力适应性强，但是对于每一类特定数据可能不是最好方案，如果你们有搞不定的已知数据，可以拿给我们来定制LOD生成策略。

2）八叉树参数设置

     目前八叉树LOD 部分只有三个参数：

               

   三角网简化 和 最小、最大级别

1，三角网简化的开启条件，如果场景里几何体复杂密度很高，那么可以开启。但是我们见过很多模型，他的几何体其实很简单，纹理非常大，比如20MB的obj，但是纹理竟然有8000多张，这些模型就无需开启三角网简化，我们内部会对纹理进行简化处理。

2， 最小级别和最大级别

    我们的级别和精度 是如下计算的

               

默认的最小级别 16级，对应的精度0.59，也就是说这种尺度下最多能看清楚半米左右的区别。最大级别是20级，对应的精度是0.037，也就是这种尺度下最多能看清4厘米左右的区别。

这个尺度对于我们一般的建筑模型完全足够了。

因为八叉树计算是个极度缓慢的过程，一个块需要的时间大约是在分钟级别。1000米*1000米范围的大约有 9个16级块，可能有 50或者60个17级块，500个18级块，4000个19级块，32000个20级。这一平方公里要处理完需要的时间很夸张，如果数据已知，那就降低下最大级别。

最小级别按照 数据总范围来设定

       一般最大级别 = 最小级别 + 3

       加一个帮助提示  

       1平方公里

              16级       10分钟

              17级        

       

3）建筑白模处理

另外一个特殊使用案例，如果您用通用模型处理城市级白模，白模本身已经足够简单了，所以无需三角网简化，另外根据你的数据范围来设置一个合适的最小级别，比如你的数据范围大约是30 公里 * 30公里，为了避免顶层块过多，假设我们能接受顶层最多100（10*10）个块，那么顶层块的大小就应该在3公里左右，从表里查到3公里是13级（2.4公里），所以最小级别就设置13，因为建筑白模的几何体相对简单，所以每个块不需要简化，白模又没有纹理，所以也就不需要分层，那么最大级别也可以设置13，这种方式基本能保证渲染效率。

当然如果你的白模数据范围很小，就几个平方公里，直接选择小场景处理器。

如果白模范围很大，比100公里*100公里更大，那么这种通用方式的模型处理，最终效果可能无法达到最佳，找我们定制吧。

3，点云处理

之前的版本中，当数据量太大，为了避免内存不足，对数据进行了分块，会把一个大的las切分成多个小las，这样做的后果导致频繁读写硬盘拖累了整个处理速度。新版本中，不再进行分块，而是在处理一段时间后进行缓存（sqlite)，大幅提升处理速度。

增加了draco压缩，可以极大减小3dtiles的数据量。压缩率与参数相关，首先是压缩级别，1-10级，越大压缩率越高，压缩速度越慢。然后是量化参数，量化参数越小压缩率越高，但数据精度损失越严重。实际处理时，如果结果有明显失真，则可以调大量化参数，相反可以调小。调参数是件困难且无趣的事情，未来我们会给出几组默认值供大家选择。

               

在输入las文件时计算最大级别，解决了在默认情况下，输入多个文件时因为最大级别不同导致的缺块问题。

4， 影像处理

增加 4326的切片方式，4326的影像切片 + 4326地形切片才能保证地形和影像的调度达到最高性能的结果。

增加了tms切片。在CesiumLab2中的tms只是在服务层实现的，但切片还是wmts。@cesium for ue的用户，可以重点了解下。顺便再次@cesium for ue用户，地形处理去掉了zip压缩，免去了自已发布切片时不必要的麻烦。

增加了切片像素大小设置。默认256*256像素，选择较大的切片，可以减少网络请求。

5，revit导出clm

去掉了授权验证，这也算新版本进一步的开放，给所有人的福利，导出clm过程不再限制。但是clm处理过程依然需要付费。

6，紧凑 和 散列互转工具

散列格式： 其实就是每个切片独立存一个 硬盘文件，这种方式适合大部分小型项目 ，因为散列可以直接使用现成的静态服务器（tomcat，nginx，iis等）分发，所以使用相对方便。但是散列也有一个缺陷，当数据量大了之后，碎文件过多，硬盘存取效率降低，不仅是数据处理过程缓慢，最终分发读取效率也不高，更致命的是，基本上没办法做数据迁移。

紧凑格式：这个我们Lab2都存在的方式，后缀是clt（cesiumlab tiles），实际上它是一个sqlite文件，里面有几个sqlite表格，具体查看Lab帮助文档，这样把很多碎文件，存储到硬盘的一个文件里，这么做好处是处理过程中硬盘存取的效率是稳定的，基本不会随着数据量变化（但是如果总量超过1T，这块可能也需要再测试）。尤其适合有数据迁移需求的项目。

我们这次新增了一个小工具，可以实现 散列3dtiles 和 紧凑（clt）之间的相互转换，送给需要的人。

7，数据库存储

Lab的3dtiles切片存入mongodb 和 postgresql 功能其实早就在代码里支持了，不过一直没有开放到 Lab2的使用界面上，这次我们还是放出来，送给需要的人。

上一节已经提到，不管是散列还是紧凑都有些缺陷。而mongodb 和 postgresql 存储不但可以解决以上问题，还满足了@分布式或者集群服务用户的需要。未来，如果需要，还可以加入hdfs/hbase/s3等等存储方式

8，CesiumLab希望与您共同成长，合作共赢

CesiumLab3在登录页采用了非主流设计，竟然把最容易被用户看到的空间让给了合作伙伴。CesiumLab本身是一款地理信息基础数据处理平台软件，旨在为在地理信息领域里奋斗的伙伴们提供力所能及的帮助，您的成功是我们最大的动力。如果需要在此展示您的风采，请备好资料联系我们，期待您的加入。