不過這些引擎是如何組織這些像素、如何播放聲音、如何讓你的敵人具有高超的AI以及如何觸發游戲中的事件呢？如果你希望了解這些問題的答案，那么閱讀本文可以找到答案。當然這個答案僅僅是大致的、框架上級別的，至于具體的實現當然需要專業的編程知識。我們主要根據Quake引擎來進行介紹，畢竟這款引擎的應用范圍相當的廣泛，比如Raven Software就在這個引擎的基礎上開發了非常具有爭議性的Soldier of Fortune（命運戰士或者財富戰士）。

游戲引擎和游戲

游戲引擎和游戲之間的關系就象一部汽車和汽車引擎之間的關系。不同型號的汽車可以采用相同的引擎，不同的游戲也可以采用相同的游戲，而且汽車的外型、材料、顏色都可以不同就象不同游戲有不同的人物模型和場景一樣。整個游戲都是以游戲引擎為基礎的，來控制其中各個部分的內容，比如模型、動畫、聲音、AI等等。

在Quake游戲中其引擎就是Quake.exe、QAGame.dll和CGame.dll，如果你不知道它們代表什么意思，不要緊，因為我們在聽到專業人事解釋之前也不知道。不過看完這篇文章之后應該對于這些有了一定的了解，當然這一篇文章肯定不能解決這個問題，所以我們打算寫一系列的文章來解釋這個問題。

渲染

首先我們從游戲開發者的角度來討論一下游戲引擎中的渲染，讓你在閱讀這個系列的文章的時候對于這個問題有個大致的認識：

所以渲染究竟是什么以及為什么重要？如果在游戲中沒有渲染，那么可能在顯示器上看不到任何的東西，對于游戲玩家或者觀察者來說渲染過程決定了顯示器最后顯示的圖像，如果進一步討論這個問題，可能會讓一些剛剛接觸這個問題的讀者覺得難以理解，因為本文僅僅是概述，我們也在討論的時候僅僅是點到即止。

構建一個游戲引擎之后，首先需要確定的就是渲染方法。不過在看不到任何圖形的前提下，怎么知道你的引擎代碼可以正常的工作呢？渲染過程一般要花費處理器50%的處理時間，游戲開發者會對于這個方面進行非常嚴格的控制，因為再好的引擎如果因為渲染算法出現錯誤的結果，那么需要渲染的場景或者人物就會出現非?？尚Φ腻e誤，這在業界應該是非常低級的錯誤（當然也是比較常見的錯誤，只是開發者基本上在開發的過程中就基本上消除了這些錯誤），一款渲染結果會出現錯誤的有些肯定無法得到廣大的玩家的承認，甚至會讓一個公司就此血本無歸。

我們最后在顯示器看到的像素正確與否受到了多個方面因素的影響，其中包括3D加速卡、API、三維算法。不同的3D加速卡的核心是不同的，所以其內部的算法處理過程應該是不同的，一般的它們都符合一個共同的標準比如提供標準的接口來同軟件進行通訊，如果做好同這些硬件之間的兼容問題是渲染過程需要主要注意問題，API也就是應用程序接口，比如我們經常提到的directX、OpenGL或者Glide都是常用的API，硬件就是通過API同一定的驅動程序配合然后支持Windows的運行等等；算法也是非常的重要，如果僅僅是按部就班的進行渲染，那么將會占用大量的處理器資源和內存帶寬，任何高效的利用這個方面的資源是設計渲染算法一個非常重要的因素。

創建3D世界

最近我同一些從事計算機圖形工作多年的業內人事進行過這個方面的交談，讓我對于創建一個3D計算機圖形的過程有了進一步的了解。即使你平時經常的玩PC游戲、游戲主機或者街機，也不一定對于這個過程有深入的了解，因為他們看到的僅僅是最后的結果。在下面我們也將會對于創建3D世界的部分細節進行討論：

記錄一個3D對象起始就是記錄一些關鍵點的位置（也就是我們常說的頂點Vertex），根據這些頂點計算機就可以繪制出來多個線條，然后就形成了很多的面－－簡化一下，可以考慮一般的包裝盒，它是一個六面體，有8個點，6個面組成?？梢娀陧旤c的數據是可以構建模型的，簡單的或者復雜的。對于游戲中的場景和人物只是由更加復雜的頂點和多邊形組成的而已，比如Quake中的人物模型都是由幾千個頂點和幾千個多邊形構成。上圖所示的就是構成一個3D對象的線框圖，相對于構成一個盒子來說，它只是復雜了而已，基本的思路是一樣的。

模型和場景如何儲存僅僅是渲染器的部分功能，而渲染器也僅僅是應用程序或者游戲的部分功能。在這個過程中游戲核心并不需要知道對象如何存儲在內存或者渲染過程是怎樣的或者渲染器如何進行渲染。核心僅僅需要把要做的任務分配給各個渲染器就可以了，當然對于結果控制還是需要核心的檢驗的。

一款好的游戲引擎，它渲染器應該是可以被完全替換的。很多跨平臺的游戲引擎，比如Unreal引擎可以在不同的游戲平臺的運行，只要用不同的平臺上的渲染器替換就可以了。其實這里渲染器的作用就是使用一定的坐標系統來定義各個點的空間位置，通過定義這些空間位置來構成組件3D對象的基本單位三角形（triangle）。當然現在的Nvidia和ATi的高端顯卡還允許你利用所謂的高序表面（higher-order surface）來構成3D模型，雖然這樣的方法的效率會更高但是這畢竟不是業界的標準方法，所以游戲開發商可能會對于這個方法提供支持，但是肯定還會提供基本渲染方法的支持，以保持游戲的兼容性。

選擇（Culling）方法

這個問題其實我們已經討論過多次了，簡單的說就是構建一個3D場景，最后我們還是通過2D的顯示器來觀察，這樣我們只能看到位于最外層的物體。但是對于大部分顯卡來說它并不管你最后會不會看見對于3D場景中的所有頂點、面都進行計算和渲染－－即使我們最后看到的只是一堵墻，如果墻后面還有很多房子，計算機同樣還會對于它們進行計算和渲染－－顯然一般是最后才判斷哪些對象是可見的哪些不是可見，顯然這樣造成了大量的資源的浪費。為了提高系統資源利用率，把判斷對象的是否可見安排在最后渲染之前就可以了，一般的我們把這個過程叫做選擇（Culling），同之前的HSR（隱面消除）是一個意思。

如上圖所示的復雜場景中，很多對象是我們看不到的，比如下面的樓層、圍墻后面的對象，傳統的渲染方法對于整個場景都會忠實的進行渲染?，F在通過Culling功能可以不完全計算這些部分，提高顯卡工作效率。

Culling的方法有很多種，在介紹這些方法之前我們首先需要對于顯卡的填充率指標有所了解，現在最新的顯示核心的像素填充率指標相當的高了，不過需要知道的這個數字僅僅是理論最高填充率，在實際環境中并達不到這個數字。

如果最后屏幕上顯示的都是同樣的材質、同樣尺寸的多邊形的話，顯卡基本上能夠達到它的理論值，但是在實際應用中，顯卡并不僅僅是進行像素填充，還要進行3D變形、光照、調用材質等工作，因此達不到這個理論值也是正常的。

最簡單的culling方法就是把需要處理的場景分成不同的區域，每個區域都有一個相對于其它區域的可見對象的列表。當然生成這個列表的計算方法有很多，也有多種列表格式。

其中BSP（Binary Space Partitioning，二進制空間分區）樹是非常常用的一個方法，在Doom和Quake就應用到了這種方法。這種方法把需要處理的場景分成很多小的分區，然后就可以根據各個分區的關系來判斷哪個是可見的哪個是不可見的。

如上圖所示，A區是任何分區都遮擋不住的，所以在樹型分支表中它的位于最上層
B和C區的可見程度僅僅會被A區遮擋，所以它們排列在第二層，而D、E區的可見程
度要受到其它三個分區的影響，所以位于最地層

Portal是基于專用的引擎之上的方法（在游戲屆相當的知名，是3D Realms流產的項目Prey的“殘留物”），在構建每個區域的時候就考慮到其是否能夠被看到，然后渲染器對于每個場景進行獨立的渲染。同現在的Nvdiia采用的“occlusion culling”有一個共同點就是在進行工作之前把所有的不必要的工作都刪除。

基本的圖像管線流程

下面介紹的處理流程比較接近于實際情況了：

通常把多邊形按照所使用的材質進行排序然后把結果放入列表，然后根據材質對于這些列表進行排列。對于使用同一種材質的多邊形還要根據它到攝像機的距離進行排序，最遠的首先會被渲染，不過現在使用Z緩存之后這一步并不是很重要了。對于那些透明的多邊形，需要在不透明的多邊形渲染之后再渲染，因為它們是透明的其最終結果要根據這些透明多邊形后面的多邊形來確定－－這是一個相當耗費資源的過程。不過好在FPS游戲場景中的透明多邊形所占據的比例一般很少。

一旦應用程序（也就是游戲）把這些需要處理的場景傳送給API（應用程序接口），API將會利用硬件T&L功能來處理器－－現在主流的顯卡都具有這個功能。這其中需要進行頂點計算、光照運算－－這些計算在過去都是有CPU來完成的，現在具有硬件T&L功能的顯卡都具有這個功能，這樣可以讓CPU做更加有價值的工作，比如提高游戲的AI等等。

Patches (Higher-Order Surfaces)

三角形渲染方法是計算機圖形業界比較傳統的渲染方法，顯卡廠商為了進一步提高顯卡的效能開始采用了 patches（面片）。 Patches (也就是 higher-order surfaces)它通過數學公司描述幾何體，而不在是記錄每個頂點的位置。根據這個公式可以按照對象的表面生成一個網格狀的框架。這種方法相同的節約資源，因為需要傳送的數據相對于需要傳送各個頂點的數據少多了。 SOF2（命運戰士2）就是采用了這種方法構建的地形系統。

ATI的TruForm功能就利用這個功能，但是它還是基于三角形渲染系統，中間利用 higher-order surface讓需要渲染的對象更加平滑，最后再轉換為更多數量的三角形模型，這種方法在渲染很多物體的時候都可以讓物體更加逼真，比如渲染生物對象，像是上面的海豚、FPS游戲中的怪獸或者人，都可以讓它們更加逼真，但是也會讓一些有棱角的物體變得圓滑而失真。