開發筆記：如何製作渲染引擎？
翻譯：趙菁菁（軒語軒緣）
審校：李笑達（DDBC4747）
記住，孩子們，在你的渲染循環中添加間接指針不是個明智之舉。更嚴重的是，如果在DirectX 11中，降低渲染代碼性能與GPU驅動程序無關，那麼可能就是你的代碼很糟糕。順便提醒，你會發現，DX11中的多線程指令緩衝區讓你的代碼更慢，不會更快（因為它們可以用來提高引擎的並行性，但目前只是驅動用起來慢，你的瓶頸應該是驅動）。
因為每次我寫一些關於這些系統的東西，人們就開始問同樣的問題……我想是因為這麼多的書仍然是關於「立即」和「保留」3D圖形API的，「保留」通常是某種場景圖……同樣，場景圖也是非常面向對象編程的，而且書籍都愛面向對象編程。
鍵中的位通常是一組狀態矩陣的下標（如相機/視口/ 渲染目標狀態、紋理設置，等等）或是直接指向底層3D API數據結構的指針。
所以下面是我們的指針，不管怎麼說，不是嗎？當然可以，但是魔術就是這樣的，它不僅有助於最小化狀態的變化，而且保證數組中的所有訪問都（儘可能）是線性的！
當然，如果你是嚴格排序深度的（不是深度塊里的），那麼你必須接受每次繪製時在不同材質之間跳躍，而且這些訪問很可能是隨機的。
· 如果是這樣的話，盡量避免這些的間接指向，在繪製結構中存儲相關數據位。
· 本案例另一個解決方案是以一種粗糙深度一致的方法排序材質數據，即所有的材料在一個房間里彼此貼近地存儲。從理論上講，你還可以動態地排序和恢復指向遊戲代碼中材質數據的指針，但是我們現在太複雜了……
同樣不能保證資源指針（GL，DX…），即使指針是線性排列的，它們可能在內存中離得很遠，這是不可避免的。在控制台上，你甚至可以控制GPU東西資源分配的位置，這樣你就可以將它們打包在一起，但更重要的是，你可以直接存儲GPU所需的中間CPU數據結構的指針。
· 你不需要使用鍵數組並排序！
使用桶，也就是說，鍵的一些位會索引到具體的桶。為每個渲染目標/通道準備一個桶是明智的。
「桶」，即單獨列表。換句話說，不要因每個子系統都有一個列表而害羞，沒有人說引擎中的所有繪製都應該有一個解決方案。
· 這通常是一個好主意，也因為繪製發射工作可以而且應該按通道排序，例如：在延遲渲染器中，也許我們想先要一個粗略的深度光子圖，然後g緩衝，然後陰影……這些可以從可見性系統中按通道順序得到。
· 每個通道做一次發射意味著我們可以在第一個通道完成後就儘可能快地得到GPU。實際上，如果我們不關心完美的排序，我們只希望儘快進行繪製，我們甚至可以把每個通道分成片段，第一個片段完成之後就馬上進行繪製。
· 我本不應該說，但是為了以防萬一……這些系統允許並行繪製，很明顯，也可以並行排序，並行生成GPU命令，非常容易。只保留每個線程的列表，對每個線程排序，然後將它們合併（唯一的同步點），然後分成塊，每個線程創建GPU命令列表（如果你有一個API，完成這些步驟會很快……）
· 不需要為所有鍵使用相同的編碼！
有些位可以決定其他位的含義。通常每個渲染目標/通道你需要做的是完全不同的東西，例如一個陰影貼圖渲染通道不需要關心材質，但可能需要一些位作為深度排序的z-鍵。
同樣，你也應有專門的解碼循環。
· 並非鍵中的所有位都需要用於排序。
狀態位直接映射到GPU，不需要額外設置狀態而帶來開銷，狀態位不應該是排序的一部分，它們只會降低排序速度。
· 剔除：讓鍵成為可見系統的一部分。
當邊界基元最終被認為可見時，它應該添加所有與繪製內容相關的鍵。
在這一點上，你還需要補上與投影深度相關的位，以便進行深度排序。
· 層次變換。
許多場景圖用作層次變化。這是愚蠢的，在大多數引擎中，一小部分的對象需要，主要是動畫/皮膚系統的骨頭。骨頭確實表達了一個圖形，但是它不足以成為讓你的整個渲染系統建立在層次變換之上的原因。
· 把那些（幾乎）總是按相同位設置在一起的狀態分為一組。
比如說，不為視口設置單獨的位（指單獨的狀態結構）、渲染目標、視圖世界投影常數等，在一個狀態結構中把所有數據合併。
· 我的列表不需要其他渲染「命令」嗎？清理呢？緩衝區拷貝呢？非同步處理器的工作等待呢？計算著色器？非同步計算著色器……
所有這些都可能是狀態某些部分「綁定」屬性的一部分。例如，當指向渲染目標/通道的指針改變時，我們會查看狀態結構，看看新設置的渲染目標是否必須清除。
在實踐中，你應該把你的鍵「裝桶」，分在不同解碼循環處理的不同陣列中，這些解碼循環會知道做什麼（例如：陰影貼圖解碼將確保CPU皮膚工作在繪製等工作之前完成）。
· 還有其他方法嗎？
當然，但是這是一個非常好的起點……
視遊戲而定。當你不知道你會擁有什麼時，像這樣的系統很好，通常是因為它們來自一個可見性系統，可能由於並行處理，這種系統不能以正確的順序完成。
在遊戲/系統中，你可以很輕鬆地按照正確的順序生成GPU命令，你確切地知道需要哪些狀態變化，顯然可以避開所有這種架構。例如，國際足聯是一個足球遊戲，不需要做太多的可視性，並且確切地知道每個玩家是如何根據材質製作的，因此可以編寫代碼以正確的順序處理事情……像這樣的東西對寒霜是合理的，但你不會為國際足聯使用寒霜引擎……
【版權聲明】
原文作者未做權利聲明，視為共享知識產權進入公共領域，自動獲得授權；
----------------------
點擊展開全文
