實時渲染引擎架構

摘要：文章主要分析了實時渲染引擎所要解決的幾個關鍵問題——圖形API、特效管理、空間分割、場景圖結構以及粒子系統等，并根據需求給出了實時渲染引擎的一個參考模型。該參考模型可實現跨平臺的圖形渲染、其特效框架可編寫和重用圖形特效，并且架構中的每個模塊都易于定制和擴展。

關鍵詞：實時；渲染引擎；架構

Abstract： This paper describes some key problems in real-time rendering engines. These problems are related to graphics application programming interface （API）， handling effects， spatial partitioning， scene graph， and particle system. Taking into account these requirements and the designs of some mainstream rendering engines， we provide a reference model for a real-time rendering engine. The model guarantees cross-platform rendering and provides and easily customizable and extendable framework that can help write and reuse visual effects.

Key words： real-time； rendering engine； architecture

三維圖形技術在建筑虛擬、城市規劃、場景漫游、場景制作、展館展示、古跡復原、交通線路設計、3D游戲等各方面都有了廣泛的實際應用。隨著硬件技術的逐步提高，游戲引擎從架構和實現效果上也逐步實現精確細致和高效，并取得了豐富的成果。

作為整個游戲引擎最關鍵的圖形子系統，實時渲染模塊負責圖形數據的實時計算和輸出，生成高效逼真的3D游戲場景，同時硬件和圖形技術的快速變化，使實時渲染引擎框架的需求越來越迫切。然而圖形渲染引擎的框架研究和設計工作卻剛剛起步，目前全球范圍與之相關的研究工作較少。如何構建通用的實時渲染框架滿足游戲引擎圖形渲染的要求，同時保證新的圖形技術產生后很容易添加到框架中是目前迫切需要解決的問題。

文章分析了實時渲染引擎需要解決的關鍵問題，并給出了通用的實時渲染引擎框架參考模型，介紹引擎對各個關鍵問題的解決方案。同時提供了可擴展的機制，使得引擎框架內的具體算法可以實現用戶自行定義、隨意拆卸等，從而保證最新的學術研究成果可以自如地運用于實際工程之中。

1 實時渲染引擎的關鍵問題

1.1 圖形API

實時渲染引擎需要完成圖形的渲染操作，就需要實現中央處理器（CPU）和圖形處理器（GPU）的交互，并對圖形應用程序編程接口（API）進行封裝和3D優化加速。目前使用最廣泛的兩種圖形API分別是DirectX和OpenGL。

1.1.1 OpenGL

OpenGL是Silicon Graphics（SGI）公司在1992年時提出的開放標準圖形庫。它發展自SGI早起的Iris API。由于Irish API的協議問題，它并不是開放的。SGI公司希望開放一套完整的圖形API標準，來留住使用他們硬件的用戶，并保持對市場的占有。因此基于Irish重新設計了一套OpenGL API[1]（Mark Segal，1994）。從此每個廠商只要遵守OpenGL標準開發自己的圖形硬件驅動即可。因此，OpenGL已經被絕大部分的操作系統支持，成為了真正的跨平臺圖形應用程序編程接口。

1.1.2 DirectX 3D

DirectX是Microsoft在Window上平臺上的圖形API。Windows 95推出時，MS公司陸續推出了DirectX 1.0、DirectX 2.0、DirectX 3.0 3個版本。前兩個版本都被認為是半成品，DirectX 3.0被認為是DirectX第一套完整的版本。1996年的Westwood公司基于DirectX 3.0開發的《紅色警戒》大賣1 200萬份，從此DirectX名聲鵲起。2002年微軟的DirectX 9提出了全新的Shader繪圖功能以及高階著色語言（HLSL），OpenGL霸主地位開始被瓦解。目前最新的發行版本是DirectX 11。

1.2 特效管理

圖形渲染引擎應該能方便快速地對市面上最新的特效技術進行支持和管理，同時為開發人員提供一套清晰的API進行相應的工作。Matthias Bauchinger[2]認為，所謂對新的特效進行支持，并不是說開發時就假定這些特效是什么，例如不應該假定只需支持頂點著色器和片源著色器，而應該能對渲染流程的每一個過程都進行支持。

第一種解決方案是由John O’Rorke[3] 于2004年提出，他把每一個著色器程序都寫在一個文件中，每個文件可能是頂點著色器或者片源著色器，且只用于一個渲染通道，這樣引擎只要知道程序的位置和入口函數即可。這種方案很容易添加或者刪除一個著色器文件，但是單純的一些著色器文件可能不足以完成一個新特效的渲染，因為他們難以與系統的渲染狀態相關聯和交互。如果不同的物體在渲染時需要用到不同的渲染通道，而渲染通道又與渲染狀態相關聯，那么就必須對每一個不同的狀態重寫一遍著色代碼。

另一種可行的解決方案是使用特效文件，這些特效文件的格式是確定的，例如Microsoft的特效框架[4]（MSEF），NVIDIA的 CgFX 框架（CgFX）[5]。這種解決方案中，頂點著色器和片源著色器也都被放在一個文件中，但是在特效文件中聲明并使用。特效文件同時可以聲明每一個渲染通道的渲染狀態。這樣的解決方案方便于實現多通道的渲染。

1.3 資源管理

引擎為其應用程序提供一個高效的資源管理模式是十分必要的，尤其是在三維場景渲染中，為了實現較好的視覺效果，大量的資源將從外部導入或者在內部生成。防止資源的冗余，提供高效的資源導入、查找、創建、使用和銷毀是一項繁瑣而重要的工作。清晰的資源控制流將幫助開發人員和用戶對程序進行管理。資源的類型包括：紋理資源、著色器資源、字體資源、模型與動畫。

1.3.1 紋理資源

紋理資源是三維渲染程序最重要的資源之一，包括一維、二維紋理和三維紋理，紋理資源的應用使得GPU能以貼圖等方式更加真實地渲染物體。引擎應該支持不同的紋理貼圖格式，向上層提供統一的紋理使用接口。

1.3.2 著色器資源

著色器資源直接與圖形特效相關。一般著色器資源分為頂點著色器和片源著色器，在Shader Model 4.0中引進了幾何著色器，而在Shader Model 5.0又引入了鑲嵌。這些著色器程序一般都會寫在一個文件中，如果按照Effect Framework的方式進行管理，那么他們就與特效文件相關聯。著色器因語言的不同，作用的底層圖形API也有所不同，引擎應能夠兼容OpenGL著色語言（簡稱GLSL）、高級著色器語言（HLSL）和Cg等多種著色語言。

1.3.3 字體資源

字體可以出現在很多應用場景中。Billboard、GUI和貼圖等都可能使用到字體。三維渲染程序需要對字體資源進行合理的定義、加載以及使用。

1.3.4 模型與動畫

模型和動畫都是引擎呈現的兩個重要單元。好的引擎應該兼容不同的模型格式和動畫格式，同時屏蔽文件格式的不同，給上層用戶提供統一的使用接口。

1.4 粒子系統

三維應用程序中常常有一些特效難以用傳統的渲染技術進行實現，特別是一些典型的模糊現象，例如火、爆炸、煙、水流、火花、落葉、云、霧、雪、塵、流星尾跡等。這些特效是與物理相關的、抽象的。一個比較好的圖形引擎應該有自己的、高效的粒子系統。

通常粒子系統在三維空間中的位置與運動是由發射器控制的[7]。發射器主要由一組粒子行為參數以及在三維空間中的位置所表示。粒子行為參數可以包括粒子生成速度（即單位時間粒子生成的數目）、粒子初始速度向量（例如什么時候向什么方向運動）、粒子壽命（經過多長時間粒子湮滅）、粒子顏色、在粒子生命周期中的變化以及其他參數等等。使用大概值而不是絕對值的模糊參數占據全部或者絕大部分是很正常的，一些參數定義了中心值以及一些允許的變化。

1.5 空間分割策略

把空間進行分割的初衷是為了減少不必要的GPU運算工作，例如我們不需要渲染位于身后的物體。尋找某種特殊的數據結構描述場景中物體的空間關系，以便根據視角錐體把空間中不可見的部分裁剪掉，可以大大提高引擎的工作效率。常見的空間分割八叉樹、KD樹和BSP樹。

1.5.1 八叉樹

八叉樹[6]把任何一個空間看成8個象限的組合，每一個空間節點有8個子節點。如圖1所示，左邊是想象中的空間分割，右邊是對應的八叉樹。每個節點中都存有渲染對象的信息，這些渲染對象或者完全處在該節點中，或者部分處于其中。

這種空間分割的缺陷是：當物體很稀疏時，大部分的節點可能都不含有渲染對象，從而對樹的遍歷操作實際是很浪費的。

1.5.2 KD樹

KD樹[7]是每個節點都為k維點的二叉樹。如圖2所示，所有非葉子節點可以視作一個超平面，把空間分割成兩部分。在超平面左邊的點代表節點的左子樹，在超平面右邊的點代表節點的右子樹。超平面的方向可以用下述方法來選擇：每個節點都與k維中垂直于超平面的那一維有關。因此，如果選擇按照x軸劃分，所有x值小于指定值的節點都會出現在左子樹，所有x值大于指定值的節點都會出現在右子樹。這樣以來，超平面可以用該x值來確定。

1.5.3 BSP樹

BSP樹[8]即二進制空間分割樹，是一類二叉樹結構，它采用任意位置、方向的分割面遞歸地將空間劃分為多個子空間對。對于n維空間，其分割面則為n -1維超平面，如圖3所示。不同的分割策略會導致不同的結果和不同的運行效率。BSP樹的構建或部分更新過程一般都比較耗時，因此很少在運行期內對其進行構造或者更新。BSP樹多用于存儲靜態場景幾何數據。

1.6 場景圖

場景圖是一幅數學上的圖，它把渲染場景相關的對象以一種層次結構組織起來。與空間分割一節中所描述的內容不同的是，場景圖關注的不僅僅是空間渲染中的幾何對象，而是與渲染相關的一切內容。它可能包括如下的內容：渲染的紋理、材質、空間變換、攝像機、光源、動畫、模型、著色器等等。

每次渲染過程中，場景圖都必須被遍歷一遍。遍歷過程中通常需要知道渲染系統的渲染狀體。這個渲染狀態對于場景圖中的每個節點都是可見的，以便在遍歷到任何一個節點時，都可以根據渲染狀態對自身選項進行更新改變，自身選項的改變，又可能影響到系統的渲染狀態。在圖4所示的例子中，場景圖畫得恰好是一棵樹，但是一般出于子節點、兄弟節點間數據共享的考慮，一個節點可能會有很多個附節點，因此就成為了一幅圖。

每一個幾何上的節點都會處在一個包圍盒中，當遍歷過程訪問到該幾何節點時，就會對包圍盒進行測試，以了解包圍盒是否在視錐體之中。如果不在視錐體中，則該節點及其子節點都會被剔除。場景圖的邏輯組織結構很方便進行剔除測試以提高運行效率。

2 渲染引擎架構設計

2.1 設計概覽

圖5所示的架構圖是一個通用的參考模型，底層部分是數學庫，為引擎提供快速地數學運算。輸入/輸出（I/O）庫則為引擎提供高速的文件流操作。GL渲染封裝和D3D渲染封裝以統一的圖形渲染接口重寫兩個圖形渲染API，屏蔽其中的差異。

這個參考模型是根據YARE[2]和OGRE[10]兩個圖形引擎架構提出來的。YARE中把數學庫和I/O并入了核心模塊，而OGRE則把渲染模塊看成核心模塊的一部分。在這里把它們分開的原因是：數學庫和I/O庫都是實際上的引擎底層，各自封裝更有利于重用。而把渲染模塊從核心模塊區分的原因是：希望把圖形渲染的過程和資源管理的過程分開。核心模塊專注于資源的管理，當需要渲染時，再把渲染資源和指令提交給渲染模塊進行渲染操作。在核心模塊和渲染之間還有一個插件模塊。

2.2 核心模塊介紹

2.2.1 渲染模塊

渲染模塊所要完成的任務是管理與GPU交互相關的緩存和渲染選項，定義統一的圖形渲染接口并根據平臺的不同而進行具體實現（例如，分別實現DirectX和OpenGL版本的接口），而后為上層的渲染提供便利。

2.2.2 核心模塊

核心模塊主要負責資源的管理，包括場景管理器和資源管理器。這里說的資源包括正在渲染的場景的場景圖和渲染所需要的各項材質、紋理、模型等。

（1）場景管理器

場景管理器負責維護場景圖，包括場景的空間分割樹、場景圖中的節點、節點內的物體、攝像機、光源、材質等。這里，我們建議場景圖和場景內容需要分離，場景內容不應該直接與場景圖相關。

（2）資源管理器

資源管理器負責從存儲設備中讀取、維護并銷毀資源。這些資源包括：紋理資源、材質資源、文件資源、二維信息板、腳本、字體、模型資源和GPU程序等。

資源管理器應該可以把資源分成多個組，每個組由用戶定義，并加載時根據用戶要求對不同的組進行加載和卸載。把所有資源進行分組的一個好處是便于提高檢索效率，每次的檢索功能都可以只發生在某一資源組內部。而且有利于提高資源的利用率和內存的控制。例如，用戶可以定義關卡1的資源組，而在進入關卡2時卸載關卡1的資源并重新加載關卡2所需的資源。在實際的使用中，很多人常常會把所有的資源統統導入引擎的管理器中，而真正被使用的卻只有一小部分。

2.3 特效框架

在設計三維應用程序的時候，我們希望可以利用多個基本的特效單元（例如散射光、影子、凹凸映射等）來組成大型的、復雜的視覺特效。用戶在不需要知道特效實現的細節的情況下就可以方便地調用，而細節則由引擎自動控制。這就是特效框架的初衷。

2.3.1 特效文件的結構

一般情況下，特效文件的層次結構如圖6所示。

一個特效包含有一個或者多個技術，然而在運行時，只有一個技術會被執行，選擇的過程可以由引擎根據圖形硬件的狀態判斷，也可以由用戶指定。

每個技術有一個或者多個通道，每個通道是GPU執行的基本單元，通道中可以定義光照模型、霧化、剔除、紋理映射等的基本效果單元。

已經存在的特效框架有MSEF和CgFX。MSEF和CgFX并沒有本質上的不同，在文件的格式上幾乎是一致的，唯一的不同在于MSEF只支持HLSL，而CgFX支持的是Cg語言。因為Cg語言是跨平臺的，因此CgFX也就可以同時用于OpenGL和DirectX。通過特效框架，所有的渲染選項、渲染著色器都被統一在一個文件中，從而便于管理。

2.3.2 后處理

后處理是指在一幀畫面被渲染出來之后在幀緩存上進行的特效處理。例如老電影、老照片、模糊、熱圖等等。

一個典型的后期處理框架是合成器框架。合成器框架最初用于OGRE引擎之中，后來被分離出來，成為一個獨立的開源項目[12-13]。

2.4 粒子系統

典型的粒子系統更新循環可以劃分為兩個不同的階段：參數更新/模擬階段以及渲染階段。每個循環執行每一幀動畫。在典型的粒子系統實現方式中，粒子系統的行為可以大致分為模擬和渲染兩個階段[9]。

2.4.1 模擬階段

在模擬階段，根據生成速度以及更新間隔計算新粒子的數目，每個粒子根據發射器的位置及給定的生成區域在特定的三維空間位置生成，并且根據發射器的參數初始化每個粒子的速度、顏色、生命周期等參數。然后檢查每個粒子是否已經超出了生命周期，一旦超出就將這些粒子剔出模擬過程，否則就根據物理模擬更改粒子的位置與特性。這些物理模擬可能會簡單地將速度加到當前位置或者調整速度抵消摩擦，或者是進行復雜處理，例如將外力考慮進去以計算正確的物理拋射軌跡。另外，經常需要檢查與特殊三維物體的碰撞以使粒子從障礙物彈回。由于粒子之間的碰撞計算量很大并且對于大多數模擬來說沒有必要，所以很少使用粒子之間的碰撞。

每個粒子系統都有用于其中每個粒子的特定規則，通常這些規則涉及到粒子生命周期的插值過程。例如，許多系統在粒子生命周期中對粒子的阿爾法值即透明性進行插值直到粒子湮滅。

2.4.2 渲染階段：

在更新完成之后，通常每個粒子用經過紋理映射的四邊形精靈（sprite）進行渲染，也就是說四邊形總是面向觀察者。但是這個過程不是必須的，在一些低分辨率或者處理能力有限的場合，粒子可能僅僅渲染成一個像素，在離線渲染中甚至渲染成一個元球，從粒子元球計算出的等值面可以得到相當好的液體表面。另外，也可以用三維網格渲染粒子。

2.4.3 典型的粒子系統舉例：

粒子的形態可以是四邊形、圓形或者簡單的點，但是其大小應該是可以改變的。粒子的其他屬性還包括數量、材質、重量、速度、生命周期等，這些屬性封裝在一個管理器中。管理器還應管理粒子的顏色衰變和線性力的影響。粒子的產生是有粒子發射器負責的。粒子發射器不一定要有固定的形狀，它可以是點、圓形、方形甚至立方體型的。一個典型的粒子系統結構統一建模語言（UML）如圖7所示。

2.5可擴展插件體系

一個好的渲染引擎需要快速地支持市場上最新或者最流行的某些功能，而這些功能不一定由引擎的開發人員開發完成，用戶可以通過插件進行擴展。引擎也不應該局限地要求用戶使用某一套效果或者某一方案的特定實現方式，而應該為用戶提供更新和改進的自由。用戶可以通過插件指定符合自身需求或者自己喜歡的一套算法或實現方式。通過一套統一的插件接口，用戶開發的插件可以由引擎方便地調用。不論是核心模塊還是渲染模塊都應該為提供插件的接口。一旦有了插件機制，引擎和其應用程序的開發都變成了一種疊磚塊的游戲。

插件機制另一個優勢在于可以把插件和應用程序分開編譯。因此當應用程序很龐大時，編譯通常都會非常耗時，而插件的編譯可能僅僅需要一分鐘。

2.6 場景圖

場景圖一直被認為是適合進行游戲場景管理的方式。在傳統的設計中，很多引擎都傾向于把場景圖和場景內容放到一個繼承體系之中，所有內容都繼承自場景節點的基類。這樣做的一個缺點是場景圖和場景內容的緊密聯系導致當出現新的數據類型（如聲音、磁場、光照環境等）時，場景管理的擴展是很笨拙的。引擎開發者必須修改相應的接口。如今很多設計者認為不應該限制場景圖的組織方式，用戶應該可以選擇自己喜歡的方式來組織場景圖。這里我們也建議設計中把場景內容和場景圖進行分離[11]。

為了實現這個目標，場景管理器中只定義了場景圖的接口，并不關心它的實現。場景圖的接口只負責維護場景結構，沒有具體的方法或者管理方式對節點的狀態進行干涉。

一個可行的解決方案是：讓場景中的物體和場景節點維持組合關系，即一個可渲染的物體不是繼承自某個場景節點，而是場景節點中的一個組成部分，場景節點可以不存在任何場景內容，這降低了架構中的耦合性。場景節點因此與場景內容是無關的，因此用戶可以選擇不同的場景管理方式[12-13]。

2.7 優缺點分析

文章提出的實時渲染架構，有以下主要優點：

·兼容了不同的底層圖形API，是跨平臺的圖形引擎。為跨平臺的圖形應用提供了可能。

·支持目前主流的高級著色語言和特效框架，用戶可以方便地利用GPU地運算能力并自定義特效。特效文件重用性好。

·每一個模塊都是獨立的、可擴展的，用戶可以根據自己的需求修改、定制引擎。

·為圖形提供了一套高效的渲染框架。把資源的管理和圖形渲染作為核心，盡可能充分利用CPU和GPU的計算資源。

當然，沒有任何框架是完美的，該框架的主要缺點在于：

·目前，GPU可以用于通用計算，該架構并沒有充分考慮GPU通用計算的能力，以達到分擔CPU計算任務從而保持負載均衡的目的。

·該架構暫時沒有支持WebGL等新技術，因此不適于開發未來的面向網頁和移動平臺的圖形應用。

3 結束語

文章提出的架構是基于傳統的軟件工程設計，這種設計使得引擎可以屏蔽底層API的不同，向上提供統一的圖形接口。隨著面向通用計算的GPU概念（GPGPU）的出現，GPU的計算能力越來越受到大家重視，除了圖形渲染功能，GPU還可以很好承擔通用計算的功能。下一步我們將充分考慮GPGPU的運用，使更多的工作由CPU和GPU協同完成，保證二者的負載均衡。另外我們會充分考慮WebGL等新技術的加入，使引擎能夠適用于移動平臺的開發。

參考文獻

[1] SEGAL M， AKELEY K. The Design of the OpenGL Graphics Interface[R].Mountain View，CA，USA：Silicon Graphics Inc， 1994.

[2] BAUCHINGER M. Designing a Modern Rendering Engine-Design Decisions and Implementation Details[M].Saarbrücken， Germany：VDM Verlag， 2008.

[3] O’RORKE J. Integrating Shaders into Applications [M]. Reading，MA， USA：Addison-Wesley， 2004.

[4] MSDN， Effects（Direct3D 11） [EB/OL].

http：//msdn.microsoft.com/en-us/library/windows/desktop/ff476136（v=vs.85）.

[5] The Cg tutorial， Appendix C：The CgFX file format [EB/OL].

http：//http.developer.nvidia.com/CgTutorial/cg_tutorial_ appendix_c.html

[6] SAMET H， The Design and Analysis of Spatial Data Structures [M].Reading，MA，USA： Addison-Wesley， 1989.

[7] MOORE A W. An introductory tutorial on KD trees[R]. Technical Report No 209. Pittsburgh， PA，USA： Computer Laboratory， University of Cambridge， 1991.

[8] ERICSON C. Real-Time Collision Detection[M]. Amsterdam， Netherland： Morgan Kaufmann， 2005.

[9] REEVES W T. Particle Systems—A Technique for Modeling a Class of Fuzzy Objects[J].ACM Transactions on Graphics， 1983， 17（3）：359-376.

[10] Ogre3d manual [EB/OL]. http：//www.ogre3d.org/docs/manual/manual_4.html#SEC4

[11] JUNKER G. Pro Ogre 3d Programming[M]. Berkeley ，CA，USA：Apress，2006.

[12] Ogre3d Manual [EB/OL].http：//www.ogre3d.org/docs/manual/manual_29.html

[13] Multiverse [EB/OL].http：//update.multiverse.net/wiki/index.php/Compositor_Framework