「渲染地球」引擎實現的原理可能是什麼？

01-04

不廢話先上圖

效果簡單說來就是從外太空到厘米精度的草坪無縫渲染
而且速度極快,即使瞬間從太空拉到地表也不會出現頓卡,貼圖模糊的情況
並且內存一直維持在1G以下,中等畫質在700MB作用,無論是太空還是地表,最多就10MB的上浮,也就是說還不是單純動態載入和釋放,否則內存大小不會這樣穩定
下面是演示DEMO 400MB
Anteworld-0.8.3.4883.exe_免費高速下載
如果說是LOD的話,不能解釋在攝像機外太空依然能觀察到物體的原因,要知道一般的遊戲引擎攝像機可見距離頂死就10KM作用,超出了就什麼都看不到了,這個和模型的大小還沒有關係(試一下在UNITY3D里搞一個高山出來,只要離的遠了立馬被裁掉,和模型大小沒關係,手動增長可見距離內存很快就爆掉)
而在這個引擎裡面,攝像機可見距離似乎遠到忽視掉裁剪距離了(官方自稱是2000KM)
一個物體(比如大湖泊),只會因透視遠大進小,最後到看不見,如此大的可視距離簡直解釋不了內存不增長的原因

還有一種可能是模型流的做法,大概是叫這個名字,遊戲引擎裡面只知道GTA和正當防衛在用這種技術,好像記得第一次看到是在DOOM啟示錄裡面,叫mega model還是mega stream大意就是說巨型地形數據做成類型在線視頻的流傳輸方式,[[[找到資料了
卡馬克大神的基於clipmap的Mega-texture地形流技術(連LOD都不用了)
ID Tech 5 中quot;Megatexturequot;針對地形的D3D9 基本實現原理]]]每次只傳送一小部分,採樣密度從低到高.搞GIS的朋友應該比較懂吧,反正我是找不到這方面資料了,這種搞法有個很明顯的特點是當移動速度很快時,會看到周圍的模型從模糊的低清慢慢到高清,典型就是谷歌地球.而這引擎完全沒有這種情況,就像數據已經預載入在內存里了一樣,完全解釋不通啊

佔一個坑，晚上回去細說。題主可以先搜索proland，開源的數字地球引擎，從太空無級變化到到地面的一棵樹，流暢如絲，且效果比這些圖只好不差，gb以至tb級別的數據量也不是問題。。

====================================

Sorry晚上過來填坑了。首先是才藝展示。多圖預警，手機小流量的朋友慎看……

第一個出場的是今天上午提到的Proland：

Proland

然後是osgEarth，我曾經在另一篇回答中提到的：

如何開始寫一個virtual globe軟體，類似於google earth那樣? - Rui Wang 的回答

它的官方網站為：

osgEarth. Terrain on demand.

這是osgEarth在IOS手機上的運行效果哦：

最後是小弟以前的一些作品，恕水平拙劣，細節上肯定不能和很多大作相比：

在OpenSceneGraph引擎（OSG）自己的官方網站還能看到其它一些小弟的作品截圖（當然只是很少一部分），當然還有其它國外高手的。

Use cases

希望到這裡不會已經有一批朋友失望而去了。其實對於任何一個從事GIS（地理信息系統）以至3DGIS系統和相關項目研發（最典型的就是，數字城市和規劃館類需求）的朋友而言，從外太空到地景細節的實時無死角漫遊，以及在這一過程中對不同天景和地物的真實感渲染需求，都是每天的工作中司空見慣的了。而這些需求，在上述開源引擎或者個人作品中都只是基本的功能實現罷了。

並且Unity亦或Unreal這類遊戲引擎在相關行業當中，通常難有用武之地，也是源自於遊戲引擎本身的特點對於GIS數據管理和渲染不會有過多的關注和支持；而一些開源引擎（例如OSG，WorldWind等），卻精於此道，並且自身的開源特性也吸引相關業內人士和公司深入研究，反過來也大大促進了引擎本身的發展。

而題主在問題中所涉及到的知識面，也正是這類場景管理和渲染當中最為重要的，暫且歸納為三點：

1、海量數字地球場景的空間索引與動態調度；

2、相機遠近裁切面的自動計算與更新；

3、大氣層與地物的真實感渲染。

都展開來說，恐怕又是洋洋數萬字不能止了，事實上小弟的畢業碩士論文就只是大概論述了其中的第三點，就已經有百頁之多，尚不能詳盡。所以在這裡也只好各自點到為止，錯漏之處，盡請指出，萬望見諒。

【海量數字地球場景的空間索引與動態調度】

首先糾正題主的思考過程中一個有誤之處：「如果說是LOD的話，不能解釋在攝像機外太空依然能觀察到物體的原因，要知道一般的遊戲引擎攝像機可見距離頂死就10KM作用，超出了就什麼都看不到了」——LOD技術指的是Level Of Details，簡單來說，就是物體與觀察者的距離不同，就顯示它不同的細節程度。換句話說，如果這個物體距離我們已經超級遠了，比如就像人馬星座與地球的距離，那麼它在我們的眼中：

A) 可以視為不存在；

B) 與其它星雲混為一體，宛若同一張圖存在。

這兩種方案原則上都正確，然而對於地球地物的渲染，其實是第二種。是的，如果北京市的模型在外太空的飛船中看去已經近乎微不足道了，那麼就把它與河北省陝西省山東省乃至全中國的地形地貌都合在一起，當成一個模型來渲染就好了。

這種模型的合併不能不遵循任何規律進行。而它所遵循的規律，就是我們所說的空間索引。而最典型的地形數據空間索引方案，就是四叉樹。

小弟無能，找不到一張足夠切題的圖來表述，期望依然能夠理解其中的基本思想。換句話說，此時一塊地貌模型的LOD，表達已經不僅僅是它自身的幾何信息的細節程度變化，而是隨著四叉樹級數的增加，被逐步切分為瓦片（Tile），並細分其幾何與紋理內容，直到數據最為精確的一層為止。例如0.01米的解析度精度，也就是說此時的地物精度已經可以區分到1毫米的差別，一枚硬幣在觀察者眼中已經清晰可見了。

當然，如果把這一層的全球數據全部加和到一起，那絕對是超越TB以至PB級別的容量大小了，或許還不止。這樣的數據量直接交給任何一台超級計算機去渲染都是災難性的結果。但是別忘了，四叉樹+LOD的本質依然是LOD，決定細節程度的依然是觀察者所處的位置與某個瓦片的距離——距離越遠，所需四叉樹的級數約低，所需渲染的瓦片內容也就約粗糙。

沒錯，一個了不起的念頭應該已經在您的鬧鐘應聲而發了吧？那些不需要渲染的瓦片，就不要放在內存中了唄，丟掉就好；需要的時候再撿回來吧。

這就是動態調度的基本思想了，隨著相機位置和角度的變化，遍歷四叉樹結構所能達到的各個瓦片的級別也是不同的，據此載入和卸載獨立於磁碟上或者網路上的瓦片數據即可。而合理的調度策略，自然也會保證內存和顯存中的數據保持在一個合理的範圍之內，不會突然上漲以至系統吃緊。

當然了，基於靜態四叉樹（也就是所有級別的瓦片都預先處理好了，然後放在磁碟上或者網路資料庫中等待載入）的數字地球調度方法，非常穩定，但不能說完美。如果分級策略不當，那麼很有可能從粗糙級別到精細級別會有跳變，或者因為精細級別的數據量較大需要長時間傳輸，造成遲緩。這裡也可以引入另外一種常見的方法，也是Google Earth中部分使用到的——Clipmaps。

GPU Gems - Chapter 2. Terrain Rendering Using GPU-Based Geometry Clipmaps

它的基本策略並不難理解：把多個級別的地形或者影像載入到Shader當中，然後在著色器的處理過程中根據視點與片元的距離來決定使用哪一級地形數據，這樣產生的地形渲染結果過渡自然，毫無突兀變化，並且不需要設置太多太密集的四叉樹級數，對磁碟或者網路訪問的壓力也有改善。自然是居家旅行，殺人越貨的首選了。

多說一句，這種方案與四叉樹結合起來使用，威力更大：即很大的地景範圍下使用四叉樹進行調度和瓦片顯示，而到了較為精細的層級，則換用Clipmaps的方案，確保觀察細部時的平滑過渡與數據優化。

【相機遠近裁切面的自動計算與更新】

再次把題主的這句話拿出來說事，還望諒解：「如果說是LOD的話，不能解釋在攝像機外太空依然能觀察到物體的原因，要知道一般的遊戲引擎攝像機可見距離頂死就10KM作用，超出了就什麼都看不到了」。這裡題主提出超過一定距離就什麼都看不到了，在Unity這種嚴格規範過渲染參數和流程的引擎中，很可能是超出了預設的遠近平面範圍，也可能是為了確保場景的最優化管理。因為如果越過這樣的規範，開發者就會不得不獨自面臨一種惱人的決策：Z-Buffer的精度損失與遠近裁切面的管理。

這篇文章，還望細讀，用處極大。

Learning to Love your Z-buffer.

讀完相信您應該已經若有所思，Z緩存的精度，會因為遠近平面的設置而發生巨大的變化，因此如果設置近平面為0.1，而遠平面為6378137（地球半徑）或者149697900000（地球與太陽的距離）的話，將其轉換到[0, 1]區間之後的深度測試（Depth Test）功能將形同虛設，您的系統甚至連區分喜馬拉雅山與馬里亞納海溝的能力都會喪失。

而所謂的Z-fighting現象，也是深度緩存精度不足的一種表現。這種情況不只發生在模型的表面是否發生重疊（重疊的表面深度相同，Depth Test的結果不能唯一因此閃爍），在深度緩存精度過低的條件下，那些明明差距很大的表面也可能會產生斑駁閃爍現象，因為在[0, 1]區間中系統依然已經無法區分它們的遠近了。

因此，自己計算一個合適的遠近平面距離，確保深度測試的精度可用性，這對於GIS行業的開發者來說是一個永恆的難題，因為客戶永遠會要求以上帝的視角去俯瞰地球。而對於遊戲引擎，尤其是通常採用第一人稱視角的FPS遊戲引擎來說，只需要直接用大霧或者別的什麼隱掉遠處，然後直接把對象從渲染隊列中去除了事——人與神的區別，在這裡盡顯無遺。

具體的計算方法，那是八仙過海，常見的有以下幾種：

1、投機取巧，以地球半球為遠平面的界限，距離視點最近的物體包圍盒為近平面界限，然而觀察近物時依然瑕疵頗多；

2、使用FBO模擬32bit的深度緩存和深度測試（而非傳統的D24S8），然而這樣對渲染流水線的改動很大；

3、使用Depth Partition方法，將整個視錐體劃分為多個部分，然後按照從遠到近的方式渲染，每渲染一個子視錐體就清除之前的深度緩存。這一方法與陰影渲染的CSM有異曲同工之妙，表達全宇宙也可勝任，只是多次渲染帶來的效率問題，不得不考量；

4、近年來興起的對數深度緩存（Logarithmic
depth buffer）優化法，可以有效改善深度緩存數據的精度分布，然而只是改善，本質上依然存在同類問題：

http://outerra.blogspot.com/2013/07/logarithmic-depth-buffer-optimizations.html

孰優孰劣，還需根據實際情況，量力而為。

【大氣層與地物的真實感渲染】

小弟自覺廢話已太多，這次就不再贅述了。本文開端提到的Proland作為一個學院派的作品，開源而且效果強勁，當然效率和穩定性上還存在問題，並且作者顯然無意繼續更新。它的網站上有多篇論文提到大氣渲染（效果遠勝之前GPU Gems的那一篇）以及地物渲染方案，感興趣的朋友不妨一睹。如有機會，小弟也願意再找題目或者空間將自己關於這部分的拙見傾囊相與。本次就此作罷。

謝邀，應該就是rui wang裡面說的clipmap，這個技術開始時候更多用在這樣的超大數據顯示上，後台數據很大，然後隨著camera拉進，會把當前使用的數據根據細節度構建一個texture pyramid或者也包括其他的信息，然後根據需要的LOD進行顯示。

這個追求流暢度的時候，對於數據壓縮和streaming都比較有壓力，這個在idsoftware的mega texture中也有一些介紹。

這個應該就是不斷的LOD處理了吧，到達一個精度級別就載入下一層的LOD，以此類推，永遠只需要載入當前攝像機能看到的細節內容。

空間劃分，
層次細節，
實時資源載入、卸載。

難點在於從遠到近的時候，能夠平滑變化而看不出突變。

PROLAND LIB 已經有人移植UNITY了，Proland To Unity: Core（牆外）

關於精度： How exactly is hard to explain so I will quote the explanation given in the official Proland documentation.

In theory the transformation q = (R+z) P / ∥ P ∥ can be easily implemented on GPU. There are however two precision problems, even with 32 bits floats. They are linked to the fact that transformed points are computed in a reference frame whose origin is at the planet center. Hence for a planet like the Earth, the coordinates of transformed points are large (of the order of R=6360000m) and do not have enough bits left to represent the altitude precisely. The other problem is when these coordinates are transformed into the reference frame of the camera, whose origin must also be expressed in the planet frame (subtracting two large numbers close to each other leads imprecise results).In order to solve these two problems, the idea is to compute the deformed quad corners and to transform them in the camera frame on CPU, using double precision. The result are points with 「small」 coordinates, that can easily be interpolated on GPU without precision problems. More precisely we compute on CPU the deformed quad corners ci (i=1,…4) and the vertical vectors ni at these corners, in the camera frame, and we use them on GPU. The idea is to compute a deformed vertex as an interpolation of the deformed corners, displaced along an interpolation of the vertical vectors.

只要不是真的完全動態的系統，多「大」其實都不難。

1.只渲染你能看得見的部分，2.預渲染你最有可能下一步看到的東西，3.其他部分按優先順序以不同壓縮和載入程度放在顯存、pipeline、各種通道里。4.看起來是即時演算出來的東西其實是腳本化。

所有即時渲染的優化技術都基於上述這4條原理.。

例如

1.遮蔽剔除：在早期FPS遊戲中，在你的視錐中被你持槍的手擋住的部分，也會被渲染。但最新的CE、寒霜等引擎中，這些部分會被剔除。

2.幾何實例：世界上有很多一樣的東西，比如說可樂瓶。你渲染100個可樂瓶，所做的工作經常是重複的，幾何實例技術能節省屌這些重複的多邊形生成過程。

3.腳本化：你一定以為那些能24小時循環的動態光照系統是即時渲染生成的，但顯然不是！雖然一天中9：00、12：00和22：00的太陽位置不同，所以陰影位置不同，但每一天的9：05分都一樣啊！！！只需要預製好時間軸腳本就可以實現24小時的偽動態光照了。

4.LOD和靠多層材質混疊實現的decal、mask系統：mask和decal被用來實現叢林地表的裝飾物(草叢、落葉、鵝卵石等等)，在不同條件下可以有不同的細節程度(密度、材質解析度、陰影有無等等)，而且可以用實例化技術優化。而LOD就是把材質細節分級，不同距離和視錐下啟用不同的細節等級。

…………

太多了。。

順便說一下，其實LOD技術最開始是用來毀滅地球的

美國的彈道/巡航導彈有光學比對制導技術（TV Match？忘了叫啥名），但由於計算機較老，存儲空間較小，不可能把「google地球」放進去比對，就發明了LOD技術。

所以導彈裡面只裝有紅場、中南海、三峽等場景的level 0不壓縮深度圖，其他位置都只有 level xxx的深度圖。

這導致導彈打有照片的地方和沒照片的地方精度不一樣。

這也就是為啥美國老是派偵察機去拍別的國家照。。。

請問，這種數字地球在導航上比較有用吧，在遊戲《太空工程師里》星球版的地表也可使用類似技術。那麼問題來了，除上述例子外，數字地球還有什麼實用用途？

過程生成系統，不知道是否高端。在遊戲中很有作用。《星際公民》《精英·危險》《無線星辰》都有相當強力的過程生成引擎。

根據《星際公民》公司CIG每個月的月報來看。這個東西相當難，本身就是一個引擎。但是具體怎麼做太空遊戲四大名著各有各的做法，沒法說。

《精英·危險》現在支持無縫登錄無大氣的行星，看來這個系統最大的敵人是風景啊.....

流關卡遠景剔除 lod一起上，

現在不可能，以後應該可以。

這是一個值得深思的問題

地球人已經研發出可以渲染整個地表的引擎了？

講道理為什麼用LOD就不能遠處看到了啦單純是LOD做得不夠多…

單純做一個地球的鏡頭完全可以多做幾層，不像是無限生成宇宙的遊戲 Elite: Dangerous / Star Citizen 或者軟體如Space Engine那樣需要更高級的解決方案…

proland，下載了，但是有環境要求，一直沒跑起來，有研究過的知友希望賜教！

看過一個關於分形的紀錄片里有類似的東西，貌似一九九幾年的電腦就能做到了