每次到写文章的时候就很高兴，意味着又有重大功能更新了，也意味着10多天昏天黑地的闭关日子暂时结束了。 依照惯例，先放图
小范围精模型cesium加载效果

大范围白模cesium加载效果

存储对象名称支持点选
处理目的：
MAX建模的三维场景 或者其他建模软件导出的三维模型数据（只支持静态场景，不支持动画） 转为 cesium可以加载的 3dtiles模型。
希望达到的目标：
自动创建lod，加快cesium的加载和渲染速度。
使用的优化手段：
大模型（mesh）切分、场景分块、三角网简化、纹理缩放合并、材质合并。 分久必合，合久必分，分分合合，估计有些人都晕了，我也很晕，但是没办法，这是必要的过程。
支持格式：
我使用的开源项目assimp做输入数据读取解析器，所以理论上支持的模型格式多达57种，详细见 https://github.com/assimp/assimp。
这里有我们熟悉的，obj，3ds，gltf 还有很多人关心的 ifc（ifc只支持一部分格式，不是全部，别高兴太早）。
开发过程中都是用dae测试的、为什么用这种格式？dae是基于xml的，可以算第一个比较完整的模型交 换格式标准，所有数据都是文本保存，更方便阅读和调试。所以我建议如果可以最好max中导出dae格式做测试。
导出工具：

max支持的两种dae导出工具
Autodesk Collada是 autodesk官方出的导出插件，这个插件真心很烂，特别对于大场景的导出，基本次次卡死。唯一的优势是对中文支持比较友好，对象的中文名都输出到dae了，所以没办法冒着次次卡死的风险不停的测试。下面是我的导出参数：

autodesk dae 参数1

autodesk dae参数2
OpenCOLLADA 是 开源的导出插件，点链接OpenCOLLADA 去下载对应版本的插件。这个插件优点是导出很快速，缺点也非常明显，对中文支持不友好，max里的所有中文名称都没了。
OpenCOLLADA dae参数
参数配置：

模型参数配置
从简单的说：
保存名称：把模型对象名称（Node的name）存入3dtiles的featuretable中，这样加载cesium之后，可以依据pick到的模型名称来区分点击的对象，方便做后续的业务，当然如果你的数据是 花花草草，这些本身就是装饰类的模型，那就没必要保存这个了。
强制双面：按道理模型都应该存储这个属性，但是可惜MAX导出的dae没有保留这个有用的属性。所以我们需要在这里强制设置，对于常见的十字交叉树木花草、单片护栏、围墙等物体，需要勾选此项。对于封闭的模型，例如建筑物或者设备等，不要勾选，可以提升一些渲染效率。
贴图效果：无光照 ： 适应的是 烘培后的场景 或者 像花草树木本身贴图都是实景图片的模型。
简单光照：适应的其他贴图模型，采用自定义shader实现，相当光线一直是视点方向，正对平面，模型最亮。
cesium默认：cesium内置的处理方式，全局太阳光。（因为一些人反映模型效果太暗，所以才搞了个 无光照 和 简单光照）
分割策略：这个最难解释的，我们天天提LOD，LOD是什么？核心就四个字：分块，分层 。这个工具的3600行纯手打的C++代码就是围绕这四个字来的。分层，其实依据精度来计算的，这个也就不展开了，核心机密。我们来说说这个分块策略：
空间优先： 依据模型（精确到每个mesh）的模型空间位置，来分割块，这个也是常规手法，比如四叉树，八叉树等等，不过这回因为考虑到适应性，并没有使用四叉树或者八叉树，而是自创的一个二叉树。简单来说，分别在x，y，z三个轴向上分割，哪个轴向上分割的模型总量差较小，就使用哪个轴。
材质优先：依据模型（精确到每个mesh）的材质（含贴图）来组合，优先把使用相同材质的模型放在一起。为什么要做这个？请看文本图1，近处的花花草草，如果按照空间分割、这些花花草草本身其实几何体很简单，但是纹理很大，导致这个纹理存储在多个块中，就比较浪费了，完全没有必要，所以这种优先使用材质分块，分层级别更少，效率更好一些。 注意优先二字，我们内部会自动计算，分块这两种方法会综合运用，而不是唯一标准。 后记： 这个工具最开始并没有排到我计划的列表中去，不过看大家各种尝试，转模型太辛苦了，还是牺牲一下我两周的时间来做点事情。和我最开始预估的一样，第一，我自己暂时用不上这个工具；第二，本身这个工具的难度就很大，需要上所有的优化手段，模型分割、模型简化，纹理合并，场景分块等等。所以我很担心，这个坑填不上，后来想想，先填一点，能解决一部分问题也好。每天约16个小时的高强度工作，大约花了2天设计了整个流程，又花3天时间堆上所有代码，又花了2天时间调通。效果也有了。然而，这时候我又有了更好的处理流程，觉得第一版太屎了，修修补补，各种不顺眼，本着做产品不是做项目的目的，决定代码重构。花了0.5天整理思路，1天的时间堆代码（3000多行c++代码一天手打出来），2天各种测试修补bug，再来0.5天的UI部分，这回效果基本满意了。再这过程中，真的也是没有及时回复很多小伙伴的消息，真的抱歉了。 模型优化是个无底洞，这个工具也不是放之四海而皆准，依然还有较大的优化空间。有人问我支不支持几百平方公里的模型？ 我不好回答，因为这要看模型制作的精细度，以及模型现在的场景结构。如果转换有问题，请发测试数据给我。

一起来聊技术吧