實時渲染引擎架構(gòu)

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

關(guān)鍵詞：實時；渲染引擎；架構(gòu)

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

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

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

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

1 實時渲染引擎的關(guān)鍵問題

1.1 圖形API

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

1.1.1 OpenGL

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

1.1.2 DirectX 3D

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

1.2 特效管理

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

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

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

1.3 資源管理

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

1.3.1 紋理資源

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

1.3.2 著色器資源

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

1.3.3 字體資源

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

1.3.4 模型與動畫

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

1.4 粒子系統(tǒng)

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

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

1.5 空間分割策略

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

1.5.1 八叉樹

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

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

1.5.2 KD樹

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

1.5.3 BSP樹

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

1.6 場景圖

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

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

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

2 渲染引擎架構(gòu)設(shè)計

2.1 設(shè)計概覽

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

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

2.2 核心模塊介紹

2.2.1 渲染模塊

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

2.2.2 核心模塊

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

（1）場景管理器

場景管理器負責(zé)維護場景圖，包括場景的空間分割樹、場景圖中的節(jié)點、節(jié)點內(nèi)的物體、攝像機、光源、材質(zhì)等。這里，我們建議場景圖和場景內(nèi)容需要分離，場景內(nèi)容不應(yīng)該直接與場景圖相關(guān)。

（2）資源管理器

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

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

2.3 特效框架

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

2.3.1 特效文件的結(jié)構(gòu)

一般情況下，特效文件的層次結(jié)構(gòu)如圖6所示。

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

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

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

2.3.2 后處理

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

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

2.4 粒子系統(tǒng)

典型的粒子系統(tǒng)更新循環(huán)可以劃分為兩個不同的階段：參數(shù)更新/模擬階段以及渲染階段。每個循環(huán)執(zhí)行每一幀動畫。在典型的粒子系統(tǒng)實現(xiàn)方式中，粒子系統(tǒng)的行為可以大致分為模擬和渲染兩個階段[9]。

2.4.1 模擬階段

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

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

2.4.2 渲染階段：

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

2.4.3 典型的粒子系統(tǒng)舉例：

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

2.5可擴展插件體系

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

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

2.6 場景圖

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

為了實現(xiàn)這個目標(biāo)，場景管理器中只定義了場景圖的接口，并不關(guān)心它的實現(xiàn)。場景圖的接口只負責(zé)維護場景結(jié)構(gòu)，沒有具體的方法或者管理方式對節(jié)點的狀態(tài)進行干涉。

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

2.7 優(yōu)缺點分析

文章提出的實時渲染架構(gòu)，有以下主要優(yōu)點：

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

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

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

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

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

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

·該架構(gòu)暫時沒有支持WebGL等新技術(shù)，因此不適于開發(fā)未來的面向網(wǎng)頁和移動平臺的圖形應(yīng)用。

3 結(jié)束語

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

參考文獻

[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