個人結論:目前,在演示層面,3D Tiles問題不大,但項目應用上就不夠成熟了,所以問問自己,你是想吃瓜呢還是想吃螃蟹?
好的方面
數據規范
我非常喜歡glTF的整體設計,概括有四點:第一,數據塊(Buffer)連續,保證了讀寫性能;第二,提供了視圖(View)和訪問器(Accessor)的概念,在不損失數據塊完整性的前提下提供類型信息和讀取規范,保證了兼容性;第三,邏輯層和數據層分離,兩者盡量分離,比如用戶想要增加一種風格,只會牽連到邏輯層的調整,不會影響數據層的讀寫,保證了獨立性;第四,邏輯層,也就是業務層是JSON形式,保證了擴展性。
3D Tiles在邏輯層,也就是JSON部分增加了FeatureTable和BatchTable,以及LOD(tileset)概念,並對應提供了header(二進制存儲)。從數據規范角度來看,繼承了glTF優秀的部分,同時考慮了傾斜,點雲,后續也會支持OSM,從數據類型的支持上也比較到位。
Cesium渲染調度
目前,WebGL技術+三維球開源框架+大數據渲染,如果拿這三個條件來過濾,除了Cesium並沒有其他選擇,所以這塊要求不能太高。
在這個要求下,通過前兩篇的介紹,Cesium在這塊的框架設計很清晰,基於狀態而不是事件驅動的方式來管理,簡化了代碼復雜度,在邏輯上沒有明顯的沖突。
在代碼設計上,提供了RequestScheduler,管理請求隊列的數量和優先級,debugShowContentBoundingVolume用來查看TileBounds,Cesium3DTileStyle可以通過表達式指定渲染風格,這些產品思路和技術細節都值得我們學習和借鑒的。
tileBounds效果,對開發人員很友好
風格表達式,提供可視化效果
欠佳
LOD
Cesium提供了Add和Replace兩種LOD策略。我認為只需要Replace一種就足夠了,Add是一個雞肋,不能解決大數據下性能的問題,而Cesium偏偏對Replace支持的不好。整個樹結構自始至終都完整保留,卸載時只會刪除數據內容,節點屬性信息仍然存在。另外刪除邏輯過分簡單,某些瀏覽方式下應該會有閃爍問題。
剛才提到節點的屬性信息是初始化一次性加載,如果數據量很大,比如城市級別,這個tileSet會很大很復雜,這點在設計上有點耿直。
數據規范
這個真的是成也蕭何敗蕭何。首先,glTF是針對單個模型的情況,強調數據的完整性,獨立性。但3D Tiles是一個樹關系,每個Tile只是其中的一個Node。打個比方,一棵樹上,節點是葉子,但現在節點對應的是一顆小樹。所以,站在3D Tiles的角度,glTF有很多過度設計的部分。比如shader,animation,scenemanager等,還有紋理部分,不能說做不到紋理公用,但確實在設計上沒有體現。
在渲染調度上,3D Tiles和glTF都是基於狀態,你可以想象,雖然在代碼邏輯上清晰,但在運行時上,對瀏覽器來說是一個負擔。明明一次性能做好的事情,非要分成好幾個任務,還美其名曰敏捷。我覺得一個Tile的解析盡可能在兩個Promise,一個Workers搞定,不拖累主線程,事情也做的干凈利索。
FeatureTable實例化的存儲設計沒有問題,Cesium對應的接口欠妥,要么提供清晰通用的規范,要么只關心存儲結構,讓用戶自己擴展實現實例化部分的Render。
作為一個大數據的數據規范,glTF可以提供壓縮機制,當然Web端解析性能的損耗需要評估,個人認為壓縮的收益太大而無法拒絕。
可用性
缺少免費好用的生成工具,並沒有形成一個成熟的解決方案。基於大數據的擴展能力也很少,只有單體化和實例化,屬性查詢這些基本能力。不知道是否支持2.5維場景,如果能支持,那就牛了。
總體感覺3D Tiles推出的有點倉促,很多地方還需要打磨,感覺戰略壓力大於實際價值,屬於占坑行為。希望后續能夠大力推動,能夠早日有成熟的完整方案和高級功能。
開源
有感於最近的一些親身經歷,也看了看threejs,Openlayers,Leaflet,Echart等項目,也在思考這些優秀的開源項目之所以優秀,到底有沒有一些共性。
就用兩句話來概括:所謂的開源(或規范),不是把自己的東西拿出去,而是把別人的東西拿進來。當我們把一個東西放到github上開源,我們以為這個工作到此結束了,其實它才剛剛開始。
最后,又想到了論語里面的那句“君子務本,本立而道生“,算是從人的角度,對上面兩句話的解釋吧。