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

關(guān)鍵詞：實(shí)時(shí)；渲染引擎；架構(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ī)劃、場(chǎng)景漫游、場(chǎng)景制作、展館展示、古跡復(fù)原、交通線(xiàn)路設(shè)計(jì)、3D游戲等各方面都有了廣泛的實(shí)際應(yīng)用。隨著硬件技術(shù)的逐步提高，游戲引擎從架構(gòu)和實(shí)現(xiàn)效果上也逐步實(shí)現(xiàn)精確細(xì)致和高效，并取得了豐富的成果。

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

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

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

1.1 圖形API

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

1.1.1 OpenGL

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

1.1.2 DirectX 3D

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

1.2 特效管理

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

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

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

1.3 資源管理

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

1.3.1 紋理資源

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

1.3.2 著色器資源

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

1.3.3 字體資源

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

1.3.4 模型與動(dòng)畫(huà)

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

1.4 粒子系統(tǒng)

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

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

1.5 空間分割策略

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

1.5.1 八叉樹(shù)

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

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

1.5.2 KD樹(shù)

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

1.5.3 BSP樹(shù)

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

1.6 場(chǎng)景圖

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

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

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

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

2.1 設(shè)計(jì)概覽

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

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

2.2 核心模塊介紹

2.2.1 渲染模塊

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

2.2.2 核心模塊

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

（1）場(chǎng)景管理器

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

（2）資源管理器

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

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

2.3 特效框架

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

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

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

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

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

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

2.3.2 后處理

后處理是指在一幀畫(huà)面被渲染出來(lái)之后在幀緩存上進(jìn)行的特效處理。例如老電影、老照片、模糊、熱圖等等。

一個(gè)典型的后期處理框架是合成器框架。合成器框架最初用于OGRE引擎之中，后來(lái)被分離出來(lái)，成為一個(gè)獨(dú)立的開(kāi)源項(xiàng)目[12-13]。

2.4 粒子系統(tǒng)

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

2.4.1 模擬階段

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

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

2.4.2 渲染階段：

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

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

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

2.5可擴(kuò)展插件體系

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

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

2.6 場(chǎng)景圖

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

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

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

2.7 優(yōu)缺點(diǎn)分析

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

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

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

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

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

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

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

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

3 結(jié)束語(yǔ)

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

參考文獻(xiàn)

[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