http://blogs.unity3d.com/2013/12/02/occlusion-culling-in-unity-4-3-the-basics/
這篇博文由Umbra Software的Jasin Bushnaief所寫，旨在解釋Unity4.3遮擋剔除的更新。
Unity4.3包含了大量的改進。全新的子系統之一包括遮擋剔除。不但簡化了界面，剔除運行本身也改寫了，還添加了一些列的新功能。
在這個系列的三篇博文里，我將介紹Unity4.3的新遮擋剔除系統的使用方法。第一篇講完成遮擋剔除以及使用用戶界面的基本方法；第二篇主要講有效遮擋剔除的最佳實踐；第三篇講一些常見問題以及解決方案。
先從基本的開始講起。遮擋剔除是指消除隱藏在其他對象中所有對象。這意味着在隱藏的東西上不會浪費資源，讓游戲運行更快更美觀。在Unity里，遮擋剔除依靠中間件組件：Umbra，由Umbra Software開發。Unity中控制Umbra的UI，在Window -> Occlusion Culling,Bake Tab下。
Umbra如何工作
Umbra的遮擋剔除過程大致可以分為兩個不同的階段。在編輯器里，Umbra處理游戲場景，游戲運行時使可見查詢在播放器中執行。所以第一，Umbra需要把游戲場景作為輸入，並bake成一種輕量級數據結構。Bake的過程中，Umbra首先把場景解構成voxel，然后把voxel組成cell，並將其與portal結合。這個數據，除了一些其他的重要片段，被稱為Unity的遮擋數據。
運行時，Umbra執行軟件入口格柵化為深度緩沖，與可被檢測的對象可見性相反。實際上，Unity給了Umbra一個相機位，Umbra回饋為可見對象 的列表。可見性查詢通常是保守的，意味着不會返回假陰性。另一方面，有些對象被Umbra視為可見，即使在現實中明顯不是。
注意到這一點很重要，這個系統類似於以前的Unity版本，整個系統已經基本被重寫了，很多地方都變得更好，無論是內部還是外部。
如何使用Umbra
獲得遮擋剔除的最佳實踐有幾個明顯的顧慮。理想的，你想盡快得到最小限度保守的結果。然而，關系到權衡。越想要精確，就越要產生更高分辨率的數據。運行時 遍歷高分辨率數據很慢，產生較慢的遮擋剔除。如果遮擋剔除比它剔除保存的需要更多幀時間，這明顯沒有意義嘛。另一方面，非常快速的剔除也沒有什么幫助，除 非只有幾個對象被剔除。所以這是一個權衡的問題。
Umbra權衡的方式是定義一對bake參數。參數決定bake過程應該期待什么樣的輸入類型，產生什么樣的數據。在運行時，使用Umbra很簡單，如果你已經bake了遮擋數據，並且相機有在Inspector啟用遮擋剔除，Unity就會自動使用Umbra。
最小的孔
輸入由最小的孔參數控制。當三維像素化遮擋幾何，最小孔映射幾乎直接到體素尺寸。這意味着如果幾何體包含你意料之中的孔、缺口或裂紋，使用比這些還小的最 小的孔是個不錯的想法。另一方面，很多時候，幾何包含許多意外的裂紋，這些是你不希望看到的。一個合理的提速分辨率將修補這些。它或許把最小孔作為烘焙的 “輸入分辨率”。
注意設置最小孔為小值意味着烘焙會慢的令人無法接受，或者占用大量的編輯器內存。在某些罕見的情況下，它甚至會由於烘焙不足導致烘焙失敗。使用一個較大的 值則會快很多，並且內存友好，它可能導致Umbra識破不了壁爐或柵欄之類的東西。所以更大並不一定總是好的。通常，一個沒有不可見錯誤的盡可能大的最小 孔是可取的。實際上我們發現5cm到50cm對大多數游戲來說效果非常好。Unity的默認值是25cm，這是一個很好的起點。
最小遮擋
最小孔主要處理輸入幾何體的類型，最小遮擋決定產生什么樣的輸出數據。本質上說，你可以把最小遮擋看做數據的輸出分辨率。值越大，運行時執行遮擋剔除的速 度就越快，但以增加守恆性（誤報）為代價。值越小，產生的結果越精確，但是更加耗費CPU時間。顯然高分辨率數據將意味着更大的遮擋數據規模。
較小的值意味着遮擋數據里捕獲了非常好的特性。Hood之下，這直接映射到Umbra建立多大的cell。許多小的cell意味着它們之間有很多小的入口，自然，這將花費更多來格柵大量的小入口，反之亦然。
改變最小遮擋的效果可以在下圖中看出來，請注意如何深度緩沖，這基本上是Unbra看到的，隨着最小遮擋的增大細節逐漸損失。
在大多數游戲里，保持最小遮擋比player稍大，所以在幾米范圍之內是不錯的。所以2-6米之間是可以的，只要游戲規模不是特別小或特別大。Unity的默認值是5.
背面閾值
也許最難掌握的參數是背面閾值，在大多情況下不需要改變，有些情況可能會派上用場，幫助了解它如何影響數據的產生。
首先，注意參數存在的目的只有一個：遮擋數據大小的優化。這意味着入伙遮擋數據沒有問題，你只需無視背面閾值。第二，該值被譯為百分比的形式，所以90意味着90%，等等。
那么背面閾值的價值所在是什么？想象一個典型的場景，由實體對象組成，此外，還可能有正常向上的地形網格。這樣一個場景，相機應該在哪里呢？肯定不在地形 下面。你肯定也不想相機在實體對象里面。這些無效的地方也是你傾向於看的背向三角形。所以在很多情況下，在場景的任何地方做假設是安全的，從相機看到了很 多背向三角形，是無效的一個，意味着游戲中的相機永遠不會結束在這些位置。
背面閾值有助於利用這一事實的優勢。通過定義從任何有效相機位置可以看到多少背向幾何極限，Umbra可以剝去超過這個閾值數據的所有位置。這在事件中如 何工作只要通過拍攝光線在所有cell做隨機抽樣，然后看那些線有多少擊中背向三角形。如果閾值超過，數據會丟棄cell。有一點要注意：只有遮擋有助於 背面測試，並且遮擋面不承擔任何相關性。100的值完全禁用背面測試。
所以，如果背面遮擋若設為70，例如，對Umbra來說意味着場景的所有位置，超過70%的可見遮擋結合沒有面對相機，會被遮擋數據剝離，因為現實中相機 絕不會在那里結束。自然不需要從地形之下正確執行遮擋剔除，例如，無論如何相機都不會在那里。在某些情況下，這可能產生相當重要的數據大小存儲。
從遮擋數據中剝除這些位置意味着遮擋剔除在這些地方未定義。“未定義”，在這里意味着結果可能是正確的、不正確的（非常隨機），或者返回錯誤。在錯誤的情況下，所有的對象都是簡單的視錐剔除。
當然在某些情況下，恰好是在有效的相機位置有一些數量的背向幾何。或許有一個片面的網格，可能錯誤地被標記成遮擋。如果是一個大的，或許會觸發附近區域的背向測試觸發器，造成剔除錯誤。這就是Unity中背面閾值的默認值為100的原因，意味着該功能是默認禁用的。
隨意實驗參數。試着將值減少到90，例如放棄地形下的大量數據。看看在遮擋數據規模上是否有明顯的效果。如果你願意，你甚至可以把值設置的更小。記住這只是你自己的冒險嘗試。如果你開始渲染，把值設置回100，看看是否能解決問題。
未完待續……
在下一篇博客中，我將給出一些最佳實踐以及獲得最佳遮擋剔除的建議。同時，請訪問www.umbrasoftware.com獲得Umbra的相關信息。