每次到寫文章的時候就很高興，意味著又有重大功能更新了，也意味著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格式做測試。
匯出工具：

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部分，這回效果基本滿意了。再這過程中，真的也是沒有及時回覆很多小夥伴的訊息，真的抱歉了。

模型優化是個無底洞，這個工具也不是放之四海而皆準，依然還有較大的優化空間。有人問我支不支援幾百平方公里的模型？ 我不好回答，因為這要看模型製作的精細度，以及模型現在的場景結構。如果轉換有問題，請發測試資料給我。