文章版權由作者李曉暉和博客園共有，若轉載請於明顯處標明出處：http://www.cnblogs.com/naaoveGIS/

1.題記

2018年對我個人是一個比較有轉折的一年。年初和女友結婚，年中有了孩子，這期間見識了何為家庭瑣事，也見識了育兒不宜，偏偏身體不爭氣，自己還住了幾次院，讓家人更添擔心。生活的波瀾讓人猝不及防，想過那麽多未來，都不如活在當下。

到現在，我應該寫了137篇博文，都是各類技術總結或探討。每一篇的開頭第一章都叫“背景”。這次換一個標題吧，寫一篇不像技術總結的總結。

　　2018年的轉折不止在生活上，工作的範疇也發生了很大的變化。從前，我和幾個小夥伴只有一畝三分地，我們耕耘好即可，現在一畝三分地突然變成了十畝良田，幾個小夥伴也變成了一群小夥伴，他們中既有C++做平臺的，也有C#寫工具的，還有專業處理數據的，更有分別做二維展示、實景展示、三維展示的。我的職責已經不僅僅是把產品整合打磨，更要溝通業務需求、協調各部門研發合作。簡而言之，我可能變成了一個即是研發經理也是產品經理的雜人了。

大概用了半年左右，我才慢慢適應這個角色。而當時我最需要適應的，並不是溝通和交流的高頻次，而是帶三維團隊這件事上。所以，明明我是想寫一篇年終總結，想來想去，不如就寫帶三維團隊的下半場總結吧，畢竟投入精力最多的就是它。

在今年七月時寫了一篇文章《帶三維團隊半年的一點總結和想法》，現在可以書接前文，言歸正傳了。

2.招到一個合適的人

有時候，招到一個合適的人真如撿到寶貝一樣，八月時的我就是這種感受。

在上半年，雖然三維在業務場景上與二維的一體化基本已完成，包括了服務端的共用、前端代碼的整合、平臺端的集成，同時也在多個項目中落地實施。但是很遺憾，就我個人目前的體會看，三維在業務上更多的像個花瓶，真正覺得是有效需求的可能還是地下管網之類。所以當時將三維的方向大致分為了兩塊：業務上配合管線團隊；展示上突出大屏特效。

既然是花瓶，就得做個好看的花瓶。既然想普適項目，就得充分考慮數據的缺失。上半年想重點推動在數據缺失時，只用建築物SHP來建立灰模特效場景，雖然當時有一定方案積累，但是遺憾的是，無論從效率上還是展現效果上，都與我的預期相差甚遠。

而這一切，直到招到這個合適的人，我稱他為zxl吧。

3.合謀

3.1最急切的事情

八月，我列了幾點我最想解決的問題：

a.解決十萬級建築物SHP的灰模特效展示效率。

b.解決管線數據處理的復雜流程。

c.研究三維動態線、動態水域。

十萬建築物的展示是入門級問題，必須解決。三維的動態線和動態水域是為了灰模場景效果做鋪墊。而管線處理流程的簡化則是減輕業務負擔的必須。

3.2 回復

九月時，我所關心的這些問題，在大家反復的討論驗證中，終於都有了回復。

十萬建築物SHP的灰模數據，用4千的筆記本也能在瀏覽器端跑的很流暢，幀率可以穩定在40以上。

而解決這個問題的重點依然是數據處理上，之前采用的方案是將SHP處理為json，然後前端解析json後實時拉伸繪制。可想而知，僅數據的請求獲取以及數據的解析都將耗去太多計算性能，即使在前端繪制上采用LOD方案依然不能根本解決這個問題。現在我們采用優先將shp數據處理成三維模型數據，然後再按照正常流程處理為3dtiles。這樣，前端加載時不用再做計算拉伸這些復雜過程，效率當然會大大提升。

動態水域、動態線則通過shader編寫特效也順利完成。

管線數據的處理簡化，核心點在紋理的一次處理後重復復用以及多個工具流程整合成一個，從而順利將之前處理500M管線數據需耗費4個小時，壓縮至十分鐘可以流程化處理完。

4.上路

終於，十月開始，我們進入了三維特效之路的探索，這段時間剛好也處於公司各項目開始進入驗收回款的階段，項目的壓力比之前大了不少。還好三維團隊成員在上半年的積累中已經越來越嫻熟，所以依然可以保證讓我放心的將zxl抽出來專門研究三維特效。

說到我們研究，那到底要研究哪些東西？在十月的一次匯報中，我給公司總監羅列了這些點：

a.建築泛光和顏色漸變優化：顏色和泛光參數化控制、邊界鋸齒、透明處不可點擊問題等。

b.動態線優化：鋸齒問題、線條長度不一致問題。

c.水域動畫優化：性能優化、對建築物遮擋問題。

d.面向三維的底圖配圖設計。

e.與大屏展示的結合：案卷、軌跡。

　十一月底時，這些問題也終於基本一一解決，呈現在我面前的demo已經讓我興奮不已，那天應該是發了一個朋友圈的。可是我依然很嚴苛的對zxl說，你還有很多不夠的：比如為什麽軌跡的線頭是個箭頭，縮放後堆在一起了，我需要的是百度的蝌蚪狀軌跡，我還需要軌跡粗細可以隨視角變化；為什麽建築物點擊後沒有選中效果；整個場景真的太安靜，如果建築物也能發生些動態變化是否更好？我甩給他很多個為什麽，也給了他不少我收集到的其他公司三維場景案例。

我想那時候zxl可能還是有點郁悶的。七月參加一個培訓，記得講座老師是阿裏雲的某個總吧，就記得兩個核心點，一個是中臺共享，一個是研發人員要皮實。Zxl是個皮實的夥伴。他在十二月時解決了我很多個為什麽。於是有了下面這個截圖：

5.軌跡

依然逃不過軌跡這個話題。

上半年二維團隊做了一系列研究，終於完成了1W輛車的實時軌跡存儲和實時多軌跡展示方案，現在，三維團隊也要來進行展示了，只有這樣，三維的動態軌跡線才能真正和業務結合。

既然二三維一體化了，我們不能再來一套存儲和對接方案。所以，我安排研發進行了軌跡中心的封裝和重構，將軌跡處理和對接部分從二維中抽離成獨立模塊。由軌跡中心完成軌跡數據的推送和前端接收數據，此時，通過事件機制將軌跡分發。二三維模塊均通過監聽該事件來獲取實時軌跡。

但是三維對軌跡數據質量的要求是高於二維的。軌跡線穿墻在二維中不會造成明顯的視覺混亂，但是在三維中，軌跡線穿墻卻是一個很糟糕的視覺感觸。所以實時軌跡的路線匹配糾正是一個不得不進行的研究。以下為目前正在改造的二三維軌跡中心架構設計：

6.細化

時光進入十二月，三維場景展示進入了精細化打磨階段。期間主要針對以下幾個方面打磨：

a.在灰模中構建標誌性建築物；

b.案卷展示場景的研究；

我們先說說標誌性建築物問題。由於灰模均是基於建築物SHP拉伸處理而來，其精細度相對於精模數據是大打折扣的。在一個城市場景中，如果沒有標誌性建築物的展現，就像沒有這個城市的靈魂。打個簡單的比方，沒有東方明珠的上海，即使展現了黃浦江，很多人一樣不能一眼識別出這是上海。那麽如何實現灰模場景中的精模效果呢？這又要回到數據的本身了。我們將此問題歸結為兩類：已有精模數據和沒有精模數據。

當有精模數據時，我們把數據進行處理展示於平臺，然後對模型外部進行高亮蒙皮，效果如下：

當沒有精模數據時，我們對SHP做復雜處理，比如塔，我們可以做多個同心圓然後拉伸建模，效果如下：

但是，基於SHP拉伸不能處理復雜的構造。終歸，我們還是要回到數據建模的路上。再次遺憾，公司的3dmax三維數據建模重來都是外包的。團隊的數據處理人員以前只做二維數據勾畫、配圖等，現在必須上了，還好經過短暫的學習，現在基本可以做簡單的模型：

再說到第二個重點問題，案卷展示場景的研究。熱力和聚類是必不可少的兩種宏觀展示方案，但是，二維的熱力都是平面的，三維的，必須有所不同。百度和高德的三維熱力，是以立面格網來進行展示。我想，我們以真正的裏面熱力來試試。Zxl同學的解決效果如下：

隨著視角的拉進，熱力需要自動消失，此時應該展現出案卷的詳細分布。當然，三維也應該有三維的案卷分布樣子：

7.前行

最後時間翻過了2018，我覺得我還是有很多不滿，很多期待。

期待，三維實時軌跡的完整流程全面落地。

期待，實時軌跡的高效糾正。

期待，三維的數據專家可以獨擋一面，將模型處理做的更精細，將灰模做的更高效。

期待，案卷展示的方式、圖標、甚至高光特效不斷的美化。

期待，三維的長江更像滾滾長江；建築物更有建築物的味道，最好還可以交互出漂亮精致的效果。

期待，三維與圖表的第一次親密接觸。

更期待，第一個三維大屏系統！

最後，奉上一個短短的截止到2019.1.8號的三維特效gif圖：

thanks，my friends and brothers.

　　　　　　　　　　　　　　　　　　　　　　　　　　 -----歡迎轉載，但保留版權，請於明顯處標明出處：http://www.cnblogs.com/naaoveGIS/

　　　　　　　　　　　　 如果您覺得本文確實幫助了您，可以微信掃一掃，進行小額的打賞和鼓勵，謝謝 ^_^

2018年帶三維團隊的一點總結