遊戲引擎剖析（五）

原文作者：Jake Simpson
譯者： 向海

第5部分: 物理，運動，效果

世界建造
　　常常在建立一個含有任何3D成分的遊戲時，你最終要試圖建立一個將會在裡面產生遊戲動作的3D環境。 不知怎麼的遊戲開發人員提供了一個建立這種環境的方，它容易修改，有效率，有較低的多邊形數量，對於遊戲既容易渲染又容易運用物理學。很簡單，對嗎？當做這個的時候我用左手在做什嗎？當做這的時候 , 我對我的左手做什麼? 是的。不錯。

　　雖然那裡有許多3D結構程式，從CAD/CAM程式到3D Studio Max，建造遊戲世界是不同於建造內部或外部世界的模型的尷尬。你有三角形數量問題 -- 任何給定的渲染器一次只能渲染這麼多的多邊形，這對於天才的關卡設計師來說永遠都不夠。不知這些，你也只能每個關卡儲存預定數量的多邊形，所以即使你的渲染器能夠在視野中處理250，000個多邊形，即使你只能在合理數量的空間中儲存500，000個多邊形，那麼取決於你怎麼處理它，最後你的關卡價值像兩個房間那麼小。不好。

　　任何方法，開發人員需要提出一個創作工具 -- 最好足夠靈活，允許遊戲引擎需要的各種事物 – 比如，在世界中放置對象，在進入遊戲以前對關卡的適當預覽，以及準確的光照預覽。在他們花三個小時預先處理關卡來產生一個 '引擎可消化的' 格式之前 , 這些能力允許遊戲開發人員看到關卡將在遊戲中看起來怎麼樣。 開發人員需要關於關卡，多邊形數量，網格數量等等的相應資料。 他們需要一個合宜而友好的方式能夠讓世界有紋理背景圖，容易存取多邊形數量縮減工具，如此等等。這個清單可以繼續列下去。

　　在先前已經存在的工具中找到這個功能是可能的。許多開發人員使用Max或者Maya建造他們的關卡， 但即使3D Max需要對它的功能有一些任務特定的擴充來有效率地完成關卡建造工作。甚至可能使用關卡建造工具，像QERadient（見），而且把它的輸出重新處理成你的引擎能夠解釋的格式。

不能看見它? 別煩擾…
　　回想一下我們在第一部分討論的BSP (二叉空間分割) 樹，你也可能聽說過潛在可視集合（PVS）這個術語正被四處談論。兩者都有相同的目標，不去探究涉及到的繁雜的數學，它是一種把世界分解為你能從世界任何給定位置看見的牆壁的最小子集的方式。在實現時，它們僅僅返回你能看見的那些，而不是那些隱藏在可能被遮擋的牆壁後面的。你能想象出這給軟體渲染器帶來的好處，渲染的每個像素(可能是這樣的情形)極為重要。它們也按從後到前的順序返回那些牆壁，在渲染時這是很方便的，因為你能夠在渲染次序中確定一個對象的實際位置。

　　大體而言，BSP 樹最近正不受歡迎，由於它們的一些古怪，而且因為我們從當今3D顯示卡獲得的像素輸送量，再加上Z緩衝像素測試，BSP 常常成了一個多餘的過程。它們在計算出你在世界的確切位置和正在你周圍的幾何物體方面是便利的，但常常有比BSP樹更好而且更直觀的方式來儲存這些資訊。

　　潛在可視集像它聽上去一樣非常好。它是這麼一個方法，在任何給定時間，給定你在世界的位置，它決定世界的哪些表面，哪些對象實際上可以看得見。這時常用來在渲染之前剔除對象，也剔除它們來減少AI和動畫處理。畢竟，如果你實際上不能看見它們,為什麼還要費腦筋處理呢。多半這真的是不重要的，如果一個非玩家角色（NPC）現正播放動畫，或者甚至在運行它的AI思考。

遊戲物理學
　　既然我們已經在記憶體中得到了世界的結構，我們必須防止我們的角色從裡面掉落出去，並處理地板，斜坡，牆壁，門，以及移動平台。加之，我們必須正確地處理地心引力，速度變化，慣性，和放置在世界裡面的其它對象的碰撞。這被看作是遊戲物理學。而且在我們進一步深入討論之前，我想現在就在這裡消除一個神話。任何時候你在世界中看見物理，或者任何人在一個複雜的遊戲環境中宣稱“真實的物理”，很好，它是BS。超過80%的建造一個有效率遊戲物理系統的精力花在簡化用來處理世界中對象的真實方程式上面。甚至那時，你時常忽略什麼是‘真實的’，並創造一些‘有趣的’東西，畢竟，這是目標所在。

　　經常地遊戲者將會忽視真實世界的牛頓物理學，並扮演他們自己的，更有趣的真實版本。例如，在QuakeII裡面，你能夠立即從0加速到35MPH，並快速停下來。沒有摩擦力，而且斜坡不提供真實斜坡提供的相同類型的重力問題。身體沒有它們應該的作用在所有關節上的地心引力 -- 你看不見身體像真實生活中那樣倒在桌子上面或者邊緣 -- 而且地心引力它本身甚至可能是可變的。 面對現實吧，在真正的世界中，空間中的飛船不像二戰飛行戰鬥員在它們的表面操作那樣實行。在空中，全部是力和反作用力，力在重量點周圍作用，等等。不像 X-Wing中的Luke Skywalker那樣嘯叫。儘管那樣做更加有趣！

　　作為遊戲開發人員來說，無論我們做什麼，我們需要能夠檢測牆壁，檢測地板，在世界中處理和其他對象的碰撞。這些是現代遊戲引擎的必備 – 我們決定對它們進一步要做的取決於我們和我們的遊戲需要。

效果系統
　　如今絕大多數的遊戲引擎建造有某種效果產生器，這允許我們表現出有洞察力的遊戲者期盼的所有可愛的吸引眼球的東西。然而，效果系統幕後所進行的東西能夠急劇影響幀速率，所以這是我們需要特別關心的地方。如今我們有很棒的3D顯示卡，我們能夠傳送大量的三角形給它們，而且他們仍然要求更多的三角形。並不總是那樣。 在Heretic II，使用它的可愛的軟體渲染模式，由於他們漂亮的符咒效果，Raven遇到了相當嚴重的過度繪製問題。回想當你在螢幕上繪製相同的像素超過一次時，過度繪製就發生了。當你有許多效果進行中，按其性質你有許多三角形，多個三角形可能相互堆疊在彼此上面。結果是你有許多重複繪製的像素。加上Alpha，這意味著在重新繪製之前你必須讀取舊像素並和新的像素混合，這會消耗更多的CPU時間。

　　Heretic II的一些效果能說明這點，我們在一幀裡對整個螢幕重複繪製了四十遍。很驚訝，是嗎？因此他們在效果系統裡面實現了一個系統採樣在過去30幀的幀速率，如果速度開始減慢，它就自動地縮減任何給定效果繪製的三角形數量。這樣使主要工作完成了，幀速率保持住了，但一些效果看上去很醜陋。

　　無論如何，因為如今絕大多數效果傾向使用大量很小的粒子類比火和煙等等，結果你在效果代碼裡面每幀要處理許多的三角形。你必須把它們從一幀移動到下一幀，決定它們是否完成了，甚至還要在它們身上運用一些物理學以便讓它們在地板上面適當的反彈。這在PC上面都是相當昂貴的，因此甚至現在你必須對你所能夠做的有一些實際限制。舉例來說，用一個像素粒子產生火的效果可能會很好，但當你這麼做的時候就別期望在螢幕上做更多別的事情。

　　粒子被定義為擁有它們自己的世界位置和速度的非常小的可繪製的物體。它們不同於有方向的精靈，大的粒子使用這些精靈 -- 比如噴出的一團團煙霧。它們面向照相機自動而典型地旋轉，縮放，改變它們的透明層級，因此它們能夠隨著時間淡出。我們容易看到大量的粒子，但我們卻限制精靈的數量—儘管兩者之間的真正不同如今正在模糊。將來，特別是在 DX9 和更加進階的圖形硬體表面以後，我們可能看到更多的人們使用過程shader來產生跟粒子系統相似或者更好的效果，創造非常棒的動畫效果。

　　當談論效果系統時，你可能聽說過‘圖原’這個詞。一個圖原是你的效果系統將處理的效果的最低層級的物理表現。更進一步解釋，一個三角形是一個圖原。那是絕大多數引擎最終在底層繪製的 -- 大量的三角形。當你沿著系統向上時，你對圖原的定義隨著變化。比如說，頂層的遊戲程式員不想考慮處理個別的三角形。他僅僅想說,"這個效果在這裡發生" 並讓系統以一種黑盒方式處理它。因此對於他來說，一個原就是‘讓我們在世界的這點持續這麼長時間用這樣的引力產生一束粒子’。在效果系統內部，它可能認為一個原是它那時正在產生的每個單獨的效果，像一組遵循同樣的物理學規則的三角形—然後它傳送所有這些單獨的三角形到渲染器進行渲染，因此在渲染器層次，圖原就是一個單獨的三角形。有一點困惑，但你知道總的思想了。

　　以上就是第五部分，下一個部分是關於聲音系統，和各種不同的音頻APIs，3D音頻效果，處理閉塞和障礙，各種不同材料對聲音的影響，音訊混合等等。