osgb转3dtiles之数据篇
炎帝故里
前不久，终于对osgb以及3dtiles的数据结构有了⾜够的了解，成功地利⽤FME将osgb数据转换成了3dtiles数据。于是，我开⼼地决定先来写⼀下如何将osgb转换成3dtiles数据。
为了让⼤家能够⽐较详细的了解这两个数据格式，该系列⽂章⼀共分为上下两篇，我将会从osgb与3dtiles的数据结构以及层级构建两个⽅⾯对其进⾏介绍。下篇仍在酝酿中，所以我们可以先将此篇作为单篇来看。
本篇⽂章，仅讲解osgb与3dtiles的数据结构，不会涉及到层级等等的介绍，但为了能够成功的看到我们最终转换出来的数据效果，因此我们仅挑选osgb中的⼀个层级进⾏转换，这样能有效地排除层级渲染的时候对数据最终效果的影响。
osgb数据与3dtiles数据粗讲
要想正确的对这两个数据进⾏转换，我们需要对这两个数据进⾏⼀些初步的了解。
⾸先什么是osgb数据？什么是3dtiles数据？他们两个数据之间有什么差异？
不知道⼤家有没有想过，为什么市⾯上能够找到osgb数据向3dtiles数据格式转换，却鲜有能够将3dtiles转换成osgb数据的？是否是这两个数据格式之间存在着很⼤的差异？
我也⼀头雾⽔，后来请教了⼀个3dtiles数据的⼤佬。
黑塞作品他跟我说：“理论上，3dtiles是可以转换成osgb数据的，不过成本很⼤。因为诸如osgb数据转3dtiles本质上是将对⼈类友好的对象型数据，裂解为对GPU友好的图形编程型数据；以3dtiles、gltf等格式的数据，是为了怎么渲染快怎么来，从来没有考虑过往回倒的余地。”
嗯，了然，就是说这类型数据就不是创建出来给⼈看的⽽是给计算机看的，可⼆次利⽤率很低。
对教官的评价好了，明⽩了这个道理，我就不再纠结回转了。
现在我们看⼀下，这两个数据的区别。
坐标转换
osgb数据，通常渲染在平⾯坐标场景上，其数据使⽤的是ENU坐标系。我更习惯叫它相对坐标，在其数据本⾝的坐标数值上，再加⼊坐标原点的值，即是正常的载体坐标（通常为2000平⾯坐标）。其坐标原点及坐标系定义存储在名为“l”的xml⽂件内，长宽⾼单位为⽶。
⽽3dtiles数据格式，则是渲染在球⾯场景上，坐标常为wgs84经纬度坐标，（也可能为2000经纬度坐标），其长宽为经纬度，⾼为⽶。
如前⽂所说，这次转换不涉及层级，因此我只提取了其中⼀个层级的数据，如下图所⽰。
人中起痘
废话了那么多，我想说的是，osgb数据要转3dtiles，必须要经过坐标转换。
坐标转换⾮常简单，利⽤Offtter给模型添加上坐标原点的偏移量将其转换为正常的载体坐标，然后Reprojector转换成wgs84的经纬度坐标就完了。
（⼀般在已经定义了原始数据的坐标系的情况下，FME写出3dtiles的时候会⾃动将其转换到经纬度坐标上，之所以加上这⼀步，是为了让⼤家对数据转换过程中到底发⽣了哪些变换有⼀个了解）
转换完成后，如果在datainspecter⾥⾯查看数据，你会发现你什么都看不到。
遇到这个问题不要慌，FME并不能渲染球⾯场景的数据，因此出现这样的问题是正常的，我们暂且不去管它，先写出成osgb数据看⼀下。数据纹理修改
在写出的时候，参数如下设置，这表⽰，我要将每⼀个osgb⽂件⽣成⼀个单独的b3dm⽂件，并汇总到⼀个叫
做“Tile+001+010_L22”的⽂件夹中，由FME⾃⼰创建层级tilet.json⽂件
日月谷在转换后有⼀些osgb数据（如我现在⽤的这个）当你将转换后如果你将数据加载到cesium⾥⾯去看，会看到如下场景。
没错，五彩斑斓的⿊（其实还是能看到模型的颜⾊的，只是因为截图被压缩的缘故，整体会显得更暗⼀点点）。
不过，有⼀点可以肯定的是，转坐标这个思路肯定是没有问题的。
然后我翻了⽹上的资料，影响⼀个模型数据的光亮程度，除了渲染引擎之间的区别、渲染场景的光照等因素；剩下的就只有数据本⾝的纹理了。
在FME打开osgb数据，查看数据的纹理结构，你会发现存在这样⼏个属性
这⾥，就要插⼀点题外话了，FME对⼏何的的分类。
可以看到，在FME中，是将单个.osgb数据当作⼀个三维的IFMEAggregate，这个聚合体（IFMEAggregate），分为多个部分，每⼀个部分下都是⼀个IFMEMesh，⽽每⼀个IFMEMesh都存在对应的⼏何和纹理。
纹理⼀般分为正⾯纹理（FrontAppearance Reference）和背⾯纹理（Back Appearance Reference）。
正⾯纹理则是我们看到的⼀个物体的表⾯，既外部的纹理特征，背⾯纹理则是物体的内部，在转3dtiles中，意义不⼤。
影响纹理的表现特征的⼏个属性，从上到下，依次分为：
· Alpha：纹理的透明度级别
· Ambient Color：环境反射颜⾊
· Diffu Color：漫反射颜⾊
· Emissive Color：⾃发光颜⾊
· Specular Color：镜⾯反射颜⾊
· Shininess：光泽度四字安全标语
查找关于着⾊器的资料，⼤概是这么说的，“物体表⾯的颜⾊是⾃发光（放射 emissive）、环境反射（ambient）、漫反射（diffu）和镜⾯反射（specular）等光照作⽤的总和。”然后罗列了⼀堆计算公式和专业术语……
呃……
看不懂……
⾸先去掉⼏个错误答案，肯定不是透明度和光泽度，⽩⾊光也肯定不会让纹理变⿊。
剩下的就只有EmissiveColor（⾃发光颜⾊）和Specular Color（镜⾯反射颜⾊）均为0, 0, 0（⿊⾊），经过我的细（hu）⼼（luan）验（chang）证（shi），造成模型变⿊的罪魁祸⾸就是这两个属性。
睡觉的朝向的正确方向其实不只是在转3dtiles格式，在转其他格式的时候，如果你发现⾃⼰的模型纹理变⿊了，多半也是这两个属性造成的。
但是如何修改这个属性呢？你会发现这并不是⼀个通常意义下存储在attribute下⾯的属性，传统的修改⽅式并不能奏效。
⼀开始，我想的是通过PythonCaller调⽤FME Objects Python API来实现这个需求，不过官⽅⽂档实在是写的晦涩难懂，也没有实际案例，花了⼏天也没看懂如何操作FMELibrary。
后来⽆意之中，发现了SharedItemRetriever和SharedItemAdder这两个转换器，终于算是实现了这个需求。
修改模型的EmissiveColor步骤如下图所⽰。
和修改普通的属性不同，我们需要先通过SharedItemRetriever提取到模型的SpecularColor属性，修改其值为1, 1, 1，然后再利⽤SharedItemAdder转换器将该属性添加回去，等待⼀切完成后，再将多余的属性要素删除即可。
这⼀步操作可能和平时的FME修改属性操作不太⼀样，理解就好。
然后再在FME中查看，我已经将该属性修改成了⽩⾊，完美。
然后再次转换成3dtiles数据，就可以看到，整个模型的颜⾊已经变亮~~……咳咳咳，我再次重申，这是截图被压缩了的问题，好吧，它确实还是有那么⼀点点⿊。
为了尽善尽美，我们以同样的⽅式，再加上修改EmissiveColor（⾃发光颜⾊），如下图是值为0.01，0.01，0.01的样⼦
全国大专院校排名
再到0.02，0.02，0.02
可以看出，模型已经明显亮了很多，⽋缺的部分，可以通过渲染引擎调整光照等因素来弥补，以达到完美的表现形式。鉴于本⼈不会cesium，下⼀步操作略过。
果然，要想研究好三维数据，需要强⼤的知识储备，我还需要加倍努⼒。
⾄此，osgb转3dtiles数据篇的讲解已经告⼀段落，整体上其实还是⽐较简单的⼀个操作，只是⽹络上相关资料太少，和我们接触的常规的⼆维数据差别太⼤。下⼀篇我们讲层级，⽇期不定，请勿催更
