这篇文章早该发布了，可惜bug不断，一拖再拖，经过这两天的测试，终于稳定了一些，打算今天放出来找骂。
先扯点其他的，关于团队，刚内部群里，发了条信息

内部群

的确是该庆贺下，最近太辛苦，几乎除了在家睡觉的8小时，其他16个小时都在公司干活，新的办公地是一个Loft的办公室，上下两层，下层办公，上层会议室。地方宽敞，早上有阳光，舒服，秀一张图：

会议室
二楼休息区
一楼

也顺便打个广告，诚招天下志同道合之人，来一起发展，致力于空间大数据可视化产业。

好，进入正题，说说我们的新工具，每当 lab升级版本的时候，一定预示着有大事发生。
不断的延期 延期 延期，终于还是要发布一下的我们新的一个处理工具，海量模型处理工具。
这个工具你可以认为是 场景处理工具（CesiumLab2.0里叫：人工模型切片）的升级版，也可以认为他是一个完全的新的工具，下面我们做一个简单的对比。

简介

1，技术对比

工具对比

2， 故宫场景的切片对比：

场景处理工具--非严格的八叉树切片 海量模型工具--严格的八叉树切片

3，更多对比：

受限很多模型都是有版权的，我们不能发出来，我们会自己造一些测试数据，都会放在EarthUI的在线模型切片下。目前有一个小工厂的示例，大家可以先对比下。

EarthUI在线服务

3，设计目标

构建完整层级的LOD金字塔，达到在Cesium上流畅载入城市级建筑外壳模型的目的。
你会发现和我们原版的场景处理工具的差异：1）它会类似倾斜软件一样构建完整层级的金字塔。2）他目标针对的是城市级人工建模的建筑外壳模型，这种模型的特点是都是外壳，没有内部，纹理个数多，而且复用率底。

4，开发过程：

8月初发布CesiumLab2和EarthSDK之后，才真正腾出手来着手这件事情。
8月~9月，整整1个月的框架设计，各种关键算法的搜集，穿插着把catia导出clm的插件也做了。
9月~10月，最核心的模型精简算法以及纹理重投影算法的实现，我得承认这里面很多算法都是开源的，但是没关系，能把这些算法给组织起来，真的不是一件容易的事情，各种坑，无数次差点要放弃。
10月~11月，数据分块算法，以及整体处理流程的实现。这部分看似简单，但是其中的分块阈值，各种算法参数调节才是最麻烦的。实现第一遍，发现处理bug太多，逻辑复杂，删掉重写。实现第二遍，分块太多，处理速度太慢，删掉重写。现在也算第三个版本，效果效率尚可，就先放出来。

先预估下可能被吐槽的地方：

1，处理速度太慢了

同一个场景原来2分钟，现在1小时。这个由于内部算法复杂， 几乎每个块都要重投影纹理，所以“慢”是必然的，目前来说还得大家忍受，看我们以后能否优化算法和处理流程加速这个过程。

2，偶然还有破面现象

现在的三角网精简算法已经不同于第一版采用的经典边塌陷等常规三角网精简算法，而是一种整体精简的算法，类似simplygon。这个算法本身的一些限制性，特殊情况下（尤其是建筑表面不是光滑，有很多棱角，立柱的时候）精简不理想，再加上我们的严格分块也会导致切割线位置可能存在一些异常。但是整体大面还是可以的，拉近就不会有破面现象。

3，局部区域无法到建模的贴图精度

这个也是受限内部处理流程，对于一些几何体非常简单，但是又包含了多个高分辨率的贴图的区块来说只能降低下分辨率了。如果希望强行达到贴图精度，那很可能带来一些处理上的灾难，块个数爆炸增长（严格八叉树，每块会有8个子块，这个很恐怖的）。

4，不支持建筑属性的附加

因为现在整个几何体我们重建了，会丢失他们原来的结构信息，所以属性如何附加成了一个麻烦的事情，这块当然可以暂时按照倾斜单体化的方式去做属性叠加，未来我们会寻求更高效的方式去附加属性。

5，可能无法在服务器或者远程机器上使用

因为目前的算法内部用到了opengl设备环境，但是远程桌面无法创建这个环境，所以见谅。不过算法都是我们实现的，迟早会改成无需opengl环境的方法。

这一切的可吐槽的地方，都无法掩盖它的优势，处理完成之后，可能能跑起整个城市的模型。耶，一白遮百丑。

再预估下可能的问题：

1， 这个工具如何付费？

因为和原来的场景处理工具（人工模型切片工具）需求目标几乎一致，我们也曾经承诺过已经免费的不会收费，所以和它保持同样的付费模式，如果空间参考设置的EPSG地理投影方式，那么需要离线授权，ENU局部坐标系不需要离线授权。

2，能否处理其他类型（不是格式）的模型？

a，人工建模的建筑外壳模型
这种是设计目标考虑的，非常合适，尤其是原来的纹理个数太多，导致无法卡顿的问题，现在彻底解决，而且还可以保证很远距离就能观察到建筑，避免建筑一个个蹦出来。

b，道路交通模型
可能适用， 这种模型一般是bim工具类似revit做出来的， 因为材质较少，实际我们肯定也能处理，而且得到一个流畅的结果，但是数据相对我们原来的bim工具可能量更大，需要再测试。

c，含内部的建筑模型
不一定适用，这种模型包含内部，一般是几何体较为复杂，贴图个数又少，所以能处理，但是结果不一定好。

d，倾斜生成的模型
可能适用，倾斜模型纹理几乎没有复用，理论上可以把倾斜模型的最高精度拿出来我们处理下，但是我们重建的金字塔还是没有cc等输出的好，如果迫不得已可以尝试。

顺道说下我们计划，下阶段我们会重写BIM数据处理工具，会新增 管线处理工具，来满足不同类型的模型生成处理需求，敬请期待。

4，为什么只支持fbx？

cesiumlab做了两年多，对于格式的支持我是深刻体会到，绝壁不是支持越多越好，毕竟我们的时间精力有限，宁愿节省点时间在核心算法上，而不愿花时间在兼容各种格式上。

怎么不用obj？
就是因为它太简单了，导致谁都能输出，也导致大家规范不一致，比如他的坐标单位，比如他的up轴，以及中文编码，obj文件本身都没有这些信息，我们就很难做到完全兼容。

为什么不用dae？
虽说它是开放交换格式，甚至是标准。但是缺陷是建模工具，尤其max对他支持太有限了，模型稍大，几乎不能正常导出。opencollada的插件又丢失了很多东西，再加上它令人头痛的xml解析，还是算了吧。

为什么用fbx ?
因为fbx 是 Autodesk 家产品的交换格式，自然对它的导出支持是最好的，而且最关键，fbx有官方的解析sdk，再也不怕丢东西了。即便这样，我们依然有一个fbx导出的推荐参数，随后请参考这个链接。https://www.jianshu.com/p/d9e15f3033e5

下来就是大家的测试时间，请下载CesiumLab2.1.0 版本，测试它，并给我反馈。
希望以后能再写一些定量分析的文章来对比两版程序的差异。如果要吐槽欢迎入群

Cesium实验室2群

最后还是重复我那句话：我没办法保证这个工具能解决所有人的所有模型加载问题，它能解决一部分问题就可以了。因此，在cesiumlab2上保留了新旧两版（人工模型切片 和 海量模型切片）两个工具，如果你数据量不大，又想急需看效果，还要绑定属性，那就先用老的程序处理吧。