一轉眼又是一週的時間，我們的實驗室功能又強大了。
照舊我們先放毒，放圖，圖，太晚了，字都敲不到一起了
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開發的數據服務器。形成從數據處理、服務發佈、到代碼集成的完整工具鏈。希望它能幫到您，歡迎反饋交流。
