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

時間 2019-11-13

標籤 2018年三維團隊一點 1點總結简体版

原文原文鏈接

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

1.題記

2018年對我我的是一個比較有轉折的一年。年初和女朋友結婚，年中有了孩子，這期間見識了何爲家庭雜事，也見識了育兒不易，恰恰身體不爭氣，本身還住了幾回院，讓家人更添擔憂。生活的波瀾讓人猝不及防，想過那麼多將來，都不如活在當下。前端

到如今，我應該寫了137篇博文，都是各種技術總結或探討。每一篇的開頭第一章都叫「背景」。此次換一個標題吧，寫一篇不像技術總結的總結。json

　　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同窗的解決效果以下：

隨着視角的拉進，熱力須要自動消失，此時應該展示出案卷的詳細分佈。固然，三維也應該有三維的案卷分佈樣子：