《Unity預計算即時GI》筆記:二、光照圖

說明

光照圖

什么是光照圖

  • 光照圖在第三章中有如下的定義,讀起來很是費解。

一個光照圖(Chart)是表示一個光照貼圖的區域,用來映射場景物件的光照貼圖UV。你可以想像是能影響物件的一張小磁磚圖,一張光照圖由兩部分組成:輻照度(照明)和方向性(主要光線方向編碼)。

  • 到了第六章又有如下講解,讀完之后我更加費解了,所以暫時擱置吧。

產生光照圖(Charts)的目的主要是用來包住靜態網格著色器(Static Mesh Renderer)的UV貼圖座標。

如何生成

一個物件所需要的光照圖數量主要是看物件有多少片UV shell需要拆解。所謂拆UV的學問就是保持幾何面上貼圖像素扭曲度和所需的Shell數量之間的平衡。

光照圖是在網格導入流程的一個拆解階段(Unwrapping stage)被產生出來的。對於PRGI來說,這些光照圖會在預計算裡的幾何階段(Geometry stage)被打包到不同的圖集(Atlas)裡,這是為了確保它們不會相互重疊。一旦預計算的幾何階段完成之後就會產生可視化數據,我們就能預覽光照圖。

  • 這個部分要結合原文的圖來看,從這個部分的文章中可以看到,在模型導入時決定了它需要幾個光照圖,而場景裡面有大量的光照圖可能會是PRGI耗時的原因之一。

  • 從上下文的介紹來看,光照圖是光照貼圖的映射,記錄了實時計算的結果,當計算光照時,需要從中提取信息。

  • 看看下列範例圖:

image
image

這樣的UV拆解不會變形,但需要多張UV shells

image
image

用單一UV shell所產生的結果,但貼圖變形很嚴重

image
image

比較理想的結果,單一UV shell且貼圖沒有變形

從上面我們可以看到三個拆UV不同的例子

從第一張圖裡我們可以看到做為貼圖的棋盤格圖案像磁磚一樣保持比例的貼在方塊表面上並沒有變形。試想如果這個棋盤圖案是一個光照貼圖(一個打在物件上的光照圖像),我們會得到一個視覺上看起來沒有問題的結果,只是會需要耗費六個UV shells。那就表示待會用Unity PRGI計算的時候也會產生六張光照圖,不管條件如何,每個光照圖最少都需要4x4個貼圖像素來表示,還沒考慮解析度之前最少就會耗掉96個像素。

在第二張圖裡我們會遇到不同的狀況,物件的UV貼圖座標只用一個UV shell就涵蓋所有範圍,雖然這樣所產生的光照圖最少,但視覺效果卻不是我們要的。我們會看到物件表面上的貼圖歪掉了,貼圖在UV空間裡也相互重疊,代表如果這是一張光照貼圖,物件一面的光照可能會錯投到相反面上。很明顯的這種拆法是有問題的。

**第三張圖的結果比較理想,棋盤沒有扭曲,磁磚比例也保持正方形。而且還成功用一張UV shell覆蓋物體的所有面。屆時透過連接或縫合對應在模型上的邊緣來把位置合上。
如果用技術的邏輯來看,整個過程做了哪些事情呢? 首先,我們會將UV圖用正交投影(Orthogonal Projection)在物件上來產生獨立的Shell,然後我們就會分析哪些Shell和物件的邊緣有相連關係,一旦我們找到了這些邊緣,我們就會把UV shell的內容移進去並和相鄰的Shell縫合起來。 **

如何查看已經生成的光照圖

  • 首先需要生成LightingData數據,將場景中的模型勾選static,然后在light window中點擊build(也可以選擇Auto) 。
  • 場景窗口中選擇,UV Charts模式會把場景裡不同光照圖用不同顏色表示
    image
    image

如何減少光照圖

  • 需要對以下幾個參數進行設置
image
image
  • 先放一下原模型的圖,后續會有大量的結果圖。
image

Auto UV Max Distance(自動最大UV距離)

Unity的拆解演算法會嘗試把不同Shell做調整將UV邊緣拼接在一起來簡化UV貼圖。當Shell放入後還能保持在Auto UV Max Distance規定的範圍內時才會被考慮進來。這個範圍是用Unity的世界空間座標來定義的,在我們的範例裡是1米。

在許多情況下,預設的0.5就能給出不錯的結果,但對於具有大面積的特大物件可能要提高這個值來防止本來應該被縫合的UV圖被演算法排除在外。

增加這個值通常會讓物件所需的光照圖數量減少,而降低這個值通常有助於解決貼圖像素被拉扯的問題,當然就會需要產生更多的光照圖來覆蓋。改變這個值後你可以透過檢視場景UV Charts繪製模式,從覆蓋的棋盤圖來評估並實驗出一個最好的平衡點。

  • 這個屬性應該是用于控制拼接UV圖的,值越大就會使得原本一些間距比較大的shell能夠進行合并,這樣就可以減少光照圖的數量。
  • 做了一個簡單的測試,分別設置為0.1、0.5、0.8。明顯可以看出來,當數值很小的時候會分出更多的光照圖,而且從淺藍色線條可以看出是模型的邊。
image

Auto UV Max Distance:0.1 / Auto UV Max Angle:89

image

Auto UV Max Distance:0.5 / Auto UV Max Angle:89

image

Auto UV Max Distance:0.8 / Auto UV Max Angle:89

Auto UV Max Angle(自動最大UV角度)

提高這個值會讓Unity的演算法更容易組合UV圖,這也表示能透過這個功能來降低單一物件的光照圖數量,但是如果設的太寬鬆有時候會出現貼圖被拉扯的狀況。反之降低這個值會造成演算法不好把相鄰的UV排一起,雖然拉扯的情況會降低但是會產生更多光照圖。相同,檢視UV Charts繪製模式裡的棋盤圖並試出一個最適合的值。

  • 基本原理和Auto UV Max Distance一直,更大的數值使得更多比較扭曲的UV Shell能夠合并,弊端也說的比較明確。

  • 以下仍舊是一組對比圖

image

Auto UV Max Distance:0.5 / Auto UV Max Angle:50

image

Auto UV Max Distance:0.5 / Auto UV Max Angle:89

image

Auto UV Max Distance:0.5 / Auto UV Max Angle:120

Preserve UVs(保留UV)

在某些情況下,自動拆UV如果無法獲得理想結果,可能會產生過多的光照圖或是貼圖失真(GI Charts繪製模式可以做拉扯檢查)。在這種情況下可能需要在模型的UV01通道手動建立UV。這必須要在其他工具完成。

如果這種情況發生,我們可以在Preserve UVs選項讓Unity演算法強制採用模型UV01通道指定的UV Shell。

當需要手動保持UV圖時,Preserve UVs選項很有用

要注意的是這些Shell會被重新打包來節省光照貼圖空間,它們會被單獨解開保留,而不是只有把在光照貼圖內的座標記錄起來而已。

使用這個功能時必須小心,當指定的UV貼圖包含著大量的UV shells時,這個功能可能會讓預計算的時間拉長,因為Unity的拆解演算法被跳過,手動保留的UV Shells到時候會全餵給預計算流程。記住,最好的結果是儘可能的降低UV shells和光照圖並保持可以接受的貼圖拉扯範圍。

  • 感覺大多數時間是不需要這個東西的,即使unity自己UI展開的不好如果不傷大雅也可以不用。

  • 生成的圖放到下面進行對比

Ignore Normals(忽略法線)

在某些情況下,網格匯入器可能會拆開幾何圖形,這也會影響到光照圖的數量。例如,如果有個網格有非常多的三角面,Unity可以為了效能把它分割成幾個獨立的子網格。通常這麼做是為了符合特定硬體需求,例如為了減少每個Draw Call所需要呼叫的三角面數量。分割通常會發生在相鄰的網格面之間法向角度有大變化的區域,比如銳角邊(hard edges)。這樣的拆分網格方式會在模型導入流程時執行,在這個過程中,UV Shell也可能會被拆分開來放到不同的光照圖,造成額外的光照圖消耗。

  • 信息量略大,首先為了減少Draw Call時三角形面數過多,unity在導入網格是進行拆分,自然這就導致了產生一些多余的UV Shell。

Ignore Normals選項可以防止模型在匯入時光照圖被拆開

有時候放著上述的問題不管不太值得,得到的結果讓光照圖數量增加拉長了預計算的時間,還有可能在照明的接縫造成不必要的視覺假象。在這樣的情況下,啟用Ignore Normals選項有助於防止光照圖在預計算的時候被分割開來。

請注意,這個選項只有對預計算即時光照(PRGI)有影響,物件被拆分的網格仍然會被保留以用在其他用途。

  • 挺好,只是為了PRGI,正常的網格還是會被拆分已做別的用途。

  • 最后放下結果對比

image

Auto UV Max Distance:0.5 / Auto UV Max Angle:89 / 使用模型UV

image

Auto UV Max Distance:0.5 / Auto UV Max Angle:89

image

Auto UV Max Distance:0.5 / Auto UV Max Angle:89 / 忽略法線

  • 目測這個模型按照默認設置效果就挺好的。
  • 后續講了一些實際的操作,還是自己讀文章吧。

光照圖總結

  • 目前來看整個PRGI的大頭在于光照圖,而如何減少光照圖是重中之重。
  • 參數雖然都已經很清楚,而且UV Charts中可以看到具體的效果。不過,在多個模型的場景中每個模型做優化也是個很費時間的事情。
最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容