一转眼又是一周的时间，我们的实验室功能又强大了。
照旧我们先放毒，放图，图，太晚了，字都敲不到一起了
lod以及包围盒
大雁塔实例，按楼层单体化
倾斜数据处理参数设置
简单介绍一下 CesiumLab 的 Osgb倾斜数据转3dtiles：
1，倾斜模型的精确匹配
CesiumLab 支持投影信息的自动读取 以及 界面输入
自动读取：如果当前输入路径，例如 C:\data\dayanta 那么会自动尝试 读取 C:\data\metadata.xml，从此文件中提取投影和中心点
界面输入：对于一些非contextcapture导出的osg，可能就没有这个metadata.xml，那么我们可以在界面上手动选择一个投影或者一个站心坐标系位置。
这里其实我有一点点的疑惑，比如如果metadata.xml里是utm50N的投影，并且有个srsorigin
模型的顶点坐标 + srsorigin 是 utm50N投影下的坐标值吗？
或者 模型的顶点坐标 仅仅是 srsorigin 和 utm50N 构造的站心坐标系下的 相对坐标 ？
我现在是前者来处理的。
对于小范围场景，几公里范围内，这个误差很小，我大概算了算，1公里误差在7厘米左右
对于大范围场景，这个还是需要搞清楚，希望懂的人给解惑一下。
手工输入站心坐标（全球任意位置放置）
2， 倾斜模型的单体化
单体化，我的个人理解就是把倾斜模型按属性分割，3dtiles的batchid属性是绑定在每个顶点之上的，所以我们的单体化是基于顶点来做的，简单来说，就是判定每个顶点属于哪个属性面，然后通过batchid去赋予它属性。
当然这块我稍微做了一下扩展，对垂直方向也进行了判定。
拿我上传到qq群（595512567）文件的示例数据，大雁塔来说，其实在shp文件同一个位置，有8个面feature（基座到第七层各一个），每个feature的最大最小高度是不同的。倾斜模型中每个顶点逐个判断，属于那个高度范围，那么就绑定哪一层的属性。
大雁塔的单体化shp数据
当然在如果处理的时候没有设置最小高度字段和最大高度字段，那么顶点会忽略高度因素，完全按照多边形范围判定。
其它更新
1，dataserver 默认支持sqlite
虽然我很喜欢mongodb，但是为了非专业玩家考虑，我不得不忍痛割爱，大家再也不为mongodb安装所折磨了。具体看使用文档吧。
2，首页增加了码农工具
码农工具
我会逐步把我开发或者数据调试处理过程中用到的一些小公举放到这个模块下，这个模块只是为了调试方便，可能会有很多使用问题，大家选择使用吧 。
模型查看器：用threeejs做的一个模型浏览工具，threejs的各种模型解析应该都是社区贡献的，所以统一性并不是太好，我目前只是堆了gltf,dae,obj,ply等模型的代码进去，但是实在没精力去修正其中的各种问题，目前只能说gltf2.0的模型还是可以的，其它的模型还是不要尝试了，等我逐渐丰富把。
模型转换器： 前两天看有人在问osgb转gltf，反正在osgb转3dtiles的工具里，这个功能就是个顺手的事情，所以就把它给放出来了。计划这块以后引入assimp去支持更多的模型格式转换。
模型转换器
矢量转换器： 这个先挖一个小坑，等我有空就用ogr去填上
码农干货：
1， osgb文件的解析
这个直接用的osg的库，顺便说一下，osg库的数学函数（vec 和 matrix）非常棒，只要是图形学相关的东西，这套数学库非常实用。
2，有人问我geometricError怎么计算的
这个直译过来就是几何误差，也就是粗精度模型相对原始模型的几何偏差，单位是米，也就是数据分级（lod）的关键指标。
首先一原则，无论我们的3dtiles怎么计算，3dtiles的叶子节点（无children）的geometricError = 0，因为这就是表示原始模型，当然是无误差的。
说一下我是怎么计算的。
对于点云处理： 点云数据分级（lod）的关键是数据抽稀，我采用的算法是体素抽稀，说简单点，就类似二维图片的像素分辨率，抽稀阈值是 体素密度 N个/米 ，所以目前，我直接直接认定 非叶子节点的 点云块 geometricError = 1 / N 米
对于建筑物矢量面处理： 建筑物矢量面数据分级的关键是数据筛选，对于每个块，我们设定一个建筑物大小筛选阈值，也是直接拿则个阈值当 geometricError
对于osgb数据：osgb由于自带lod，osgb的lod用像素投影大小来定义的，核心问题就是把这个像素大小转为 geometricError，这块先卖个关子，等下次再说。
从上述的处理看出来了吧，其实我的处理方法没什么高深的，把很多问题简化了，绝对没有什么太深的理论算法计算，目前能用就行了，随着以后加深理解再说吧。
3，有人问我说osgb转gltf出不来什么原因
这个原因真的太多了：顶点不正确，包围盒不正确，矩阵偏移不正确都可能导致。
有些人说转出来的gltf是黑色的，这个一般是法向量的问题导致的。
我也是被这些看不见，黑色的问题各种折磨，不过还好我有cesiumlab的3dtiles预览工具，它具有定位，包围盒，位置中心等一键式功能，极大的方便了我的开发，也希望能帮到各位在做osgb转3dtiles工具的码农。
再吐槽一下gltf里的默认材质pbrMetallicRoughness，这个材质计算真是有点难调，怎么调颜色都不亮。我把cesium生成的shader截取出来了，竟然快一百行。几个关键的值：baseColorFactor基础颜色，我现在设定的白色。roughnessFactor 粗糙度我的理解是调整散射颜色的强度，metallicFactor我理解调整的反射颜色的强度。我来回对比了好多组合都没有太好的，下一步打算要么尝试看有没有禁用光照的方法，要么就自己写shader了，对于倾斜来，颜色本来就是照片生成的，已经带了光照信息，最简单的纹理采样就是原汁原味，不应该在shader来回再算光照。如果有简单的禁用光照的方法，望大家告知。
4，这回又被小bug折磨了三小时
最开始保存b3dm大致是这么写的
ofstream of(“c:\1.b3dm”);
of.write()….
of.close
文件正常生成了，可是在cesium中死活就是解析失败，经过跟代码发现buffer长度不对。
最后c++里调试，发现 write一个2000长度的数组，文件长度竟然是 2010多，见了鬼了。
c++高手估计该嘲笑我了，呵呵，我就不卖关子了，直接说原因：
ofstream默认的打开方式是文本，对于文本的话存入的数据系统会经过编码处理，这样有些字符占用的位置就多了。
因为b3dm是二进制解析，所以我们必须二进制打开文件，如下：
ofstream of(“c:\1.b3dm”, ios::binary); 这样就问题搞定。
其实这个问题我还是挺注意的，只是由于代码架构需要，打开文件和写文件并不在一个cpp里，容易被忽略。
一些测试数据：
https://pan.baidu.com/s/1aYWXZntVGx2-MZjiQVqzOg
后记：
终于终于把我前面挖的几个大坑（建筑物矢量面处理，osgb倾斜模型处理）都填上了。现在我又给自己挖了一个巨大的坑，Bim（ifc）数据转3dtiles，这个坑我现在还没底，不知道什么时候才填的上，大家等着吧。
另外我看到太多的同学因为max模型转换而苦恼，这个我原本是打算写max脚本的，但问题是这个脚本没办法集成到cesiumlab中，很难形成一个统一化的产品，所以我也在犹豫。如果有max模型转换的问题，可以私聊。
Cesiumlab是一款专为Cesium开源数字地球平台打造的免费数据处理工具集。目前包含地形数据处理、影像数据处理、点云数据处理、数据下载、建筑物矢量面处理等几大工具。同时提供一套java开发的数据服务器。形成从数据处理、服务发布、到代码集成的完整工具链。希望它能帮到您，欢迎反馈交流。
