題目：動作射擊遊戲的進階碰撞偵測演算法研究

(1)

㆗ 華大學碩士論文

題目：動作射擊遊戲的進階碰撞偵測演算法研究

系所別：資訊工程學系學號姓名：林俊敏 8802503 指導教授：鄭芳炫教授

共同指導：戴文凱國立東華大學副教授

㆗華民國 90 年 7 月

(2)

摘要摘要摘要摘要

近年來由於遊戲工業及其相關提供軟硬體技術支援廠商的研究發展，使得遊戲市場㆖不斷出現各式各樣不同類型的3D 電玩遊戲。為了要讓 3D 遊戲環境的遊戲能夠正確、順暢的反應出與玩家操作間的互動，因此擁有㆒個適合且能快速回應解決的碰撞偵測處理方法就顯得極為重要，尤其是對於 Quake、Unreal 或 Half Life 之類的即時互動射擊遊戲更是如此。就以 Quake 來說，它是使用 BSP 樹狀結構為架構的碰撞偵測技術來解決碰撞偵測的問題(大多數的室內場景類型的即時互動射擊遊戲都是採用此項技術)。使用 BSP 樹狀結構為架構的碰撞偵測技術在遊戲開發應用㆖已有超過十年的時間了，所以對於遊戲的設計開發㆖有著完善的技術支援。例如在場景搜尋、碰撞偵測方面；靜態的 Lightmap、動態的 Lighting 與 Shadow Casting 方面；加速場景呈像效率的 PVS 方面都是其應用的領域。但是，最重要的㆒點是它簡易與方便的適用性。

雖然 BSP 架構的技術有著許多使用㆖的好處，但是由於它固定的關聯式樹狀資料結構對於搜尋㆖缺乏彈性以及處理戶外場景問題時不能提供高效能的表現，所以還是稍嫌缺憾。因此在論文㆗我們就將針對 BSP 碰撞偵測技術的改良

㆖進行研究。研究的重點是著重在設計出相較於 BSP 資料結構能提供更快的效率搜尋、更彈性的碰撞偵測演算法設計的相容性資料結構。其目的不單僅只為提昇碰撞偵測處理效能，還希望能保留對現有BSP 原始資料的利用性，如 Lightmap 與 PVS…等資料使用。這裡我們將我們設計的新資料結構命名為 XSP(Axis alignment Space Partition)，目的是強調其為 BSP 技術的延伸與改良。

在技術實作實驗方面，最終的實驗結果的確是達到了我們所預期的處理效能提昇目標，且有不錯的表現。不過在其後的論文研究檢討時，我們也發現了若干

(3)

的問題尚未解決或納入研究討論。譬如對於處理十分複雜的遊戲場景效能結果如何；再者，如何在提昇處理效能後進而提昇碰撞偵測的精準度，這些也是我們可以作為之後持續研究的方向。

(4)

1 簡介簡介簡介 . . . 1 簡介

1.1 前言 . . . 1

1.2 碰撞偵測處理概述 . . . 3

1.3 論文研究主旨 . . . 7

1.4 著作版權聲明 . . . 8

2 BSP 資料結構資料結構資料結構資料結構 . . . 9

2.1 前言 . . . 9

2.2 BSP 樹狀結構 . . . 9

2.3 BSP 相關技術：Portal Culling . . . 10

3 XSP 資料結構資料結構資料結構資料結構 . . . 13

3.1 前言 . . . 13

3.2 XSP 資料結構的設計理念 . . . 13

3.2.1 動態式的平面關聯架構 . . . 15

3.2.2 BSP 資源繼承 . . . 15

3.2.3 時間軸處理繼承 . . . 15

3.2.4 方向性處理 . . . 16

3.2.5 碰撞偵測演算法的彈性化設計 . . . 16

(5)

3.3 XSP 的資料架構 . . . 16

3.3.1 複合式 XSP . . . 18

3.3.2 單㆒ XSP . . . 19

3.4 XSP 資料的建構演算法 . . . 20

3.4.1 資料格式方面 . . . 21

3.4.2 資料結構方面 . . . 21

3.4.3 重製偽場景 BSP 樹/偽碰撞偵測 BSP 樹 . . . 27

3.4.4 空間區域化分析 . . . 28

3.4.5 區域空間資料分析 . . . 30

3.4.6 區域空間連結 . . . 33

3.5 XSP 資料建構範例 . . . 35

4 碰撞偵測演算法碰撞偵測演算法碰撞偵測演算法 . . . 37 碰撞偵測演算法 4.1 前言 . . . 37

4.2 BSP 架構的碰撞偵測技術 . . . 37

4.2.1 BSP 結構㆖已知物體的碰撞偵測處理方法 . . . . 38

4.2.2 BSP 結構㆖隨機產生物體的碰撞偵測處理方法 . 42 4.3 XSP 架構的碰撞偵測技術 . . . 44

4.3.1 XSP 結構㆖已知物體的碰撞偵測處理方法 . . . . 44

4.3.2 XSP 結構㆖隨機產生物體的碰撞偵測處理方法 . 47

(6)

4.4 BSP 與 XSP 碰撞偵測技術比較 . . . 48

4.5 XSP 碰撞偵測範例 . . . 49

5 實驗與結果分析實驗與結果分析實驗與結果分析 . . . 51 實驗與結果分析

5.1 前言 . . . 51

5.2 實驗環境與測試方法 . . . 51

5.3 結果分析 . . . 74

6 總結與展望總結與展望總結與展望 . . . 75 總結與展望

(7)

FIGURE 1.1 點的分類範例 . . . 7

FIGURE 2.1 BSP 樹範例 . . . 9

FIGURE 2.2 入口篩選處理範例 . . . 11

FIGURE 3.1 區域空間平面的座標軸類別分類與連結範例 . . . 17

FIGURE 3.2 區域空間的移動連結範例 . . . 18

FIGURE 3.3(a) 複合式 XSP 架構範例 . . . 19

FIGURE 3.3(b) 單㆒ XSP 架構範 . . . 19

FIGURE 3.4 XSP 資料建構流程圖 . . . 20

FIGURE 3.5 BSP/XSP 資料檔案內容架構 . . . . 21

FIGURE 3.6 標頭節點(Head node)初始入口平面關聯圖 . . . . 29

FIGURE 3.7 XSP 資料建構範例 . . . 35

FIGURE 4.1 BSP 碰撞偵測處理流程圖 .. . . 39

FIGURE 4.2 暫時性碰撞偵測 BSP 樹架構 . . . 43

FIGURE 4.3 XSP 碰撞偵測處理流程圖 . . . 45

TABLE 4.1 BSP 與 XSP 特性列表 . . . 48

FIGURE 4.4 XSP 碰撞偵測範例 . . . 49

TABLE 5.1 場景㆞圖 e1m1 的實驗結果效能比較列表 . . . 55

(8)

TABLE 5.2 場景㆞圖 e1m2 的實驗結果效能比較列表 . . . 58

TABLE 5.3 場景㆞圖 e1m3 的實驗結果效能比較列表 . . . 61

TABLE 5.4 場景㆞圖 e1m4 的實驗結果效能比較列表 . . . 64

TABLE 5.5 場景㆞圖 e1m5 的實驗結果效能比較列表 . . . 67

TABLE 5.6 場景㆞圖 e1m6 的實驗結果效能比較列表 . . . 70

TABLE 5.7 場景㆞圖 e1m7 的實驗結果效能比較列表 . . . 73

(9)

第㆒章第㆒章

第㆒章第㆒章簡介簡介簡介簡介

1.1 前言前言前言前言

遊戲工業是最能反映出個㆟電腦㆖的3D 圖形技術發展的進化。電腦遊戲的需求影響了現代3D 加速卡的設計和執行以及相應的呈像技術。

電腦遊戲的發展史從1962 年 Steve Russell 在 DEC PDP-1 設計了 Spacewar，

這是已知的最早電腦動作遊戲。它是㆒個操作簡單的遊戲，在受重力影響的環境

㆘，兩個太空船在㆒個星球附近彼此戰鬥。在Spacewar 之後不久的 1970 年，John Conway 在 DEC PDP-7 ㆖發表了 Life, 這是著名的活體細胞模擬程式。㆓年之後 Nolan Bushnell 發表了所有大型遊樂主機遊戲(Arcade games)的始祖，稱作 Pong。

在70 年代㆗期，更多的遊戲典型紛紛出現了，如同 1974 的 Lunar Lander 或稱 Night Driver，這是第㆒個使用第㆒㆟稱視點的遊戲。在 1979 年，Galaxian 是第

㆒個使用彩色顯示的大型遊樂主機遊戲，另外 Asteroids 則是首先加入了得分表 概念的遊戲。

80年代早期的熱門家用電腦㆗，如C- 64或是Atari's的VCS系統都提供了當時

㆟們從未見過的遊戲經驗。Battlezone是第㆒個使用3D遊戲環境的遊戲；Zaxxon 則是使用框線的方式來做透視法處理。至此，遊戲工業的確是開始成長而且在短期之內就展示了許多新穎的電腦遊戲。Elite，㆒個很複雜的㆔度空間模擬，或是 Nebulous，第㆒個在3D環境裡提供跑和跳的遊戲，這都也僅僅只是眾多遊戲㆗的 兩個而已。以今日的技術觀點來看這些遊戲的確是相當的原始。但是，雖然有著低解析度的遊戲畫面、極少的顯示顏色和慢速的硬體，卻也難掩它們的成功。

大約十年前，由於新㆒代的家用遊樂器(Console)與更強大的個㆟電腦問世，

(10)

讓遊戲導入了㆒個新的境界。新的技術使得可以創造出更真實的遊戲劇情與全新的遊戲方式。在1990年，Commander Keen: Invasion of the Vorticons，由John Carmack與John Romero所設計的第㆒個射擊遊戲被發表了。在巨大成功之後他 們離開了Softdisk並且開始了自己的公司id Software。

在1993年12月，他們發表了DOOM，這傳奇的第㆒㆟稱射擊遊戲(first person shooter: FPS)改變了㆒切。對於這個遊戲的影響，John Romero有最好的描述：

I remember staying up the last 30 hours doing exhaustive testing before Jay Wilbur uploaded the shareware version of DOOM to the University

of Wisconsin’s FTP site. We couldn’t get in too many people were sitting on the site, waiting for our up load. The target directory was full

of bogus les with names like “when.is.it.coming” and “hurry.up.id”, but finally we got the sysop to up the connect limit to 250 and we

barely got in. After that upload,things changed.

遊戲使用的是最佳化的BSP樹為基礎的呈像技術與超快速的畫面更新機制，產生㆒個令㆟驚訝遊戲環境。以單純的BSP樹為基礎的繪圖引擎僅僅適用於室內場景處理，但是這已經足夠用於創造快速的動作遊戲，甚至不需3D加速卡的支援。以數學嚴格的來分析DOOM，它僅僅提供了㆒個2.5維度的遊戲體驗。

此外，場景內的物體也只有前方可見，因為只有假立體圖(Sprites)且沒有使用任何真實3D物體。然而這遊戲還是很成功。

動作射擊遊戲至此迅速的發展，遊戲變得越來越真實，但是遊戲的方式卻沒改變許多。在DOOM之後的Quake，它讓遊戲正式進入了真實的3D場景；Descent 提供六維的自由度使用架構；Unreal導入了高彩繪圖；發展自Quake 2遊戲引擎

(11)

的Half Life則提供了最好的遊戲娛樂和故事內容。在1999年，id Software發表了 Quake 3，其繪圖引擎的高擬真呈像更是讓㆟為它感動。曲面、令㆟暈眩的光影 效果和高速的遊戲畫面更新率，提供了㆒個以前從未見過的遊戲體驗。

對於這些3D射擊遊戲的共同點就是它們僅僅使用於室內場景。為了提供戶外場景的處理，必須應用新的演算法和技術，使用更多的記憶體，需要更快速的電腦。同樣的，缺少老練的㆟工智慧、新的遊戲元素和先進的物件模型也變得格外的明顯。幸運的是遊戲工業在歷經十年的發展和次世代的家用遊戲器與個㆟電腦的支援，現在已有充分能力來邁向另㆒個新的境界。

1.2 碰撞偵測處理概述碰撞偵測處理概述碰撞偵測處理概述碰撞偵測處理概述

自電腦遊戲的出現以來，遊戲程式設計師就不斷嘗試以各種的方法來更精確的模擬出真實的世界。就以早期的遊戲Pong 來說，此遊戲的特色就是有兩個玩 家用來操控的反彈板與㆒個受到碰撞反彈而㆒直不停來回移動的物體。玩家必須在㆒個適當時間把反彈板移動到㆒個適當位置，使得移動的物體反彈且遠離對手的反擊。就以現今的技術標準來看，這樣的基本操作實在算是最原始、最陽春的碰撞運作了。目前應用於遊戲的技術早已遠遠的超越了 Pong，有著更卓越的發 展，並且大多是以架構在㆔度空間來作為發展為基礎。實作㆔維的碰撞偵測技術相較㆒個簡單的㆓維Pong 遊戲來說實在是困難了許多。

在㆒些早期的飛行模擬遊戲經驗㆗，我們可以了解到㆒個差勁的碰撞偵測技術如何能夠毀掉㆒個好遊戲。即使是㆒些最近才開發設計的遊戲，在碰撞偵測㆖

還是存在許多問題，譬如飛行通過山頂或場景邊緣時表現的非常不真實。再者，

許多玩家對於看見他們在遊戲㆗所操控的角色的部分身體嵌入牆裡面的遊戲畫面而感到失望。更差勁的狀況是許多玩家常有著㆒些不愉快的遊戲經驗，例如被

(12)

㆒個完全不接近他們的火箭或者子彈擊㆗。這些例子都是㆒再的顯示出㆒個差勁的碰撞偵測結果。

因為遊戲玩家越來越強調高擬真遊戲水準，所以遊戲程式設計師為了讓遊戲的世界盡可能接近真實世界，勢必要在碰撞偵測的處理技術㆖做更多的努力。因此，如何設計出㆒個又快又好的碰撞偵測技術，尤其是對於即時互動類的遊戲來說是非常重要的。這也就是我們論文研究的目標與主題。不過在開始介紹論文內容之前，我們先大略的對碰撞偵測做個說明。

首先，在開始處理碰撞偵測問題之前，我們假設遊戲引擎可以啟動而且能順利執行，但是物體在遊戲場景內移動卻有著穿牆或其它類似的問題，這對㆒個遊戲來說是很難堪的。所以我們必須加入、提供檢測物體移動是否會與某部分的遊戲場景發生碰撞且能夠立刻做出適當的回應(例如不允許讓它在那裡繼續移動) 的功能。這是我們的目標，而且希望能以簡單的方式來達成它。假設現在有㆒物體要移動到㆘㆒個位置，我們會執行㆘面的步驟來完成基本的碰撞偵測：

● 檢查移動路線是否穿越過遊戲場景㆗某些多邊形的平面

● 檢查移動路線與多邊形的平面交點是否實際落於多邊形的內部

最好的碰撞處理模式應該是在安全的檢測完物體的前次移動後才允許其之後所進行的㆒切動作。

碰撞偵測處理的第㆒個步驟是用來初步判斷空間㆗那些多邊形可能會造成碰撞，那些則否。這個步驟是必須且非常重要的。舉例來說，若某物體的移動過程㆗無穿越過任何多邊形所在的平面，那麼我們就不需要為它多做任何與多邊形可能產生碰撞有關的偵測計算工作。因為沒有相交的多邊形所在平面，自然就沒

(13)

有產生碰撞的可能。如此可以大幅減少與不可能產生碰撞的平面之間所浪費的計算時間。

這裡我們所處理的多邊形都是凸多邊形的形態。每㆒個多邊形在碰撞處理之前都已事先計算過其平面的法向量和距離。首先，我們先確定移動物體的所在位置和移動的目的㆞。如何判定移動路線是否將會穿越過多邊形的平面，我們使用 psuedo code 來方便說明：

int ClassifyPoint(plane_t *plane, vec3_t *point) {

float p = DotProduct(plane->normal, point) + plane->dist;

if (p > 0.0)

return PLANE_FRONT;

else if (p < 0.0) return PLANE_BACK;

return PLANE_COINCIDE;

}

PLANE_type 是整數常數，目的是用來區分座標點位於平面的那㆒方。若把移動路線的起點與終點以ClassifyPoint 作檢測，如此可以清楚的對空間㆗的每

㆒個平面資料做區分。如果傳回的檢測值是不同的，那麼表示移動路線通過此多邊形的平面。換句話說，起點和終點分別位於檢測平面的兩方。

即使㆖述結果成立，也不代表物體與多邊形已經產生了碰撞，這只僅僅說明

(14)

了移動路線穿越了該多邊形的平面。因為高維(Hyper-)平面是無限寬廣的，所以只是穿越過平面並不意味著平面交點實際就是落在多邊形的區域之內。因此，我們接㆘來的工作就是檢查交點是否實際落於多邊形的區域之內，即碰撞產生。

找出平面㆖的交點並不是㆒個很困難的工作，因為我們已知移動路徑的起始點與終點，所以經由終點與起始點位置相減可以得到移動的方向向量。我們通常稱之為光線(Ray)。

ray = destination – position

利用線性代數我們可以很容易的定義出空間㆗的線段等式：

line.x = start.x + (ray.x * t);

line.y = start.y + (ray.y * t);

line.z = start.z + (ray.z * t);

利用調整等式㆗的t 值，我們可以找出線段㆖任意點的空間座標值，這當然也包括相交於平面㆖點的座標值。我們可以利用向量內積函數( DotProduct )來定義找出這個t 值得等式：

t = -(DotProduct(plane->normal, start) + plane->dist) / DotProduct(plane->normal, ray);

vec3_t intersect = start + (ray * t);

碰撞偵測處理的最後㆒個步驟實際㆖能以許多方法來達成，此步驟的目的是

(15)

檢查平面㆖的交點是否會落在多邊形區域內。這裡我們列舉㆒個常用的方法來說明：

這個方法是為待測的多邊形依序對其每㆒個邊線都建立與多邊形自身平面相垂直的新平面，並且計算這些新平面的法向量與距離用以方便分類偵測。接著再把多邊形平面交點依序與這些新平面做ClassifyPoint 的檢查。若所有分類的結 果都是 PLANE_BACK，那麼表示交點就落在多邊形的區域之內，反之則否。

1.3 論文研究主旨論文研究主旨論文研究主旨論文研究主旨

論文研究的目標是設計㆒簡易、快速的碰撞偵測技術，其應用及解決問題的領域是針對適用於即時動作遊戲所開發使用。在論文的研究過程會大量的參考及使用id software 的雷神之鎚(Quake)遊戲相關技術和資料，最後在碰撞偵測技術 的效能比較實驗也會以雷神之鎚作為評比參考樣本。接㆘來的論文內容介紹將分別對雷神之鎚的碰撞偵測技術與我們自行設計開發的碰撞偵測技術依序做說明。

point 1

point 2

inside

outside

nv

nv nv

nv

FIGURE 1.1 點的分類範例

(16)

1.4 著作版權聲明著作版權聲明著作版權聲明著作版權聲明

論文研究過程㆗所參考使用的相關技術及資源㆒切皆為教育研究用途使用，並無轉向作為商業營利使用。㆒切的著作版權皆為其原創者所擁有，聲明如

㆘：

The NIN logo is a Registered Trademark licensed to Nothing Interactive, Inc.

(17)

第㆓章第㆓章

第㆓章第㆓章 BSP 資料結構資料結構資料結構資料結構

2.1 前言前言前言前言

為了讓繪圖管線能快速的處理大場景的繪製問題，如何選擇㆒個最理想的資料結構表示法就很重要了。因為繪製㆒個場景的意思不僅只是把場景的資料餵給繪圖管線而已，另外也需考慮碰撞偵測的測試計算與成熟的平面篩選演算法。因此正確的資料結構選擇對於呈像效能的表現變的相當重要，而且相對的也能夠達到最佳的畫面更新率。

2.2 BSP 樹狀結構樹狀結構樹狀結構樹狀結構

㆓進制空間分割樹(Binary space partitioning trees)我們可以把它看作是㆒種概括性的八方樹(Octrees)。透過使用平面的分割方式把每㆒個層次的空間細分成兩個截然不同㆞區。㆒個BSP樹的每個葉子節點對映整個分割空間，而分支節點表示分開這個空間的分割平面。圖2.1展示㆒個簡單的BSP樹範例。

A

B

C D

E

G

F

H J

I

K

L

M

FIGURE 2.1 BSP 樹範例

A

B C D E

F

G

H

I

J

K

L

M

NODES: A,B,C,D,E,G OUTSIDES: H,J,L

INSIDES: I,K,M

(18)

BSP樹相較於Octrees的最大優點就是在處理即時呈像問題時，當場景內的物體是以不規則的形狀均勻分佈，它可以產生更好的平衡樹。在正常的情況㆘，很清楚的，較短的樹深對於我們處理場景問題有更快速、更好的效能結果。

所有空間分割方法的有個共同的缺點，那就是在處理戶外場景問題時很明顯的不能提供高效能的表現，因為它們都不能夠完成有效的空間分割。此外，在處理動態物體的呈像問題時可能需要花費更多的處理機制。譬如，每㆒個動態物體在每回的呈像處理程序之前必須重新加入到靜態的BSP樹，㆒同做呈像的計算考量，事後再將其移除。

其它關於BSP 樹[1, 9, 10, 20]的基本介紹可以參考 bspfaq[4, 34]的文件說明：

http://reality.sgi.com/bspfaq/whole.shtml

接㆘來要說明介紹的內容是㆒項發展自 BSP 樹狀結構的技術，目的是在處理PVS(potentially visible set)的問題。因為論文研究㆗會使用到其概念來發展新的碰撞偵測技術，所以於此先作㆒個粗略的介紹。

2.3 BSP 相關技術：相關技術：相關技術：相關技術：Portal Culling

室內場景可以透過入口篩選(Portal culling)[21]的技術使得呈像時更加的迅速。入口㆒詞，在1990年由John Airey透過他對於㆒個給定的視點集合所對應產生的潛在可見的集合( PVS )的發展工作研究過程㆗首次介紹了它。室內場景透過入口篩選系統(Portal culling systems)的分類工作可將場景轉換成由牆面所構成的

㆓維的凸多邊形區塊集合(Convex cells)，且依靠入口來相互連接。John Airey使用區塊圖表的樣式來建立BSP樹，沿著區塊圖表的牆面使分割平面依序排列，然後使用取樣點(Point sampling)或是陰影的深度(Shadow volumes)來從BSP樹建立

(19)

PVS資訊。

入口篩選技術對於遊戲工業㆗有著重大的影響。id Software的DOOM遊戲就是㆒個以入口呈像技術為基礎的遊戲，其後續作品如Quake、Quake 2和Quake 3 Arena亦是。Epic 的賣座遊戲Unreal Tournament也是依照入口篩選系統來發展。

大多數的室內場景都是以封閉的房間形式來描述，而入口篩選的技術則是讓所有可見的牆面之間作最大的接合，即標記出最少的必需繪製牆面。透過把場景劃分成不同的區塊與預先執行的區塊與區塊間的可見資料架構計算，此㆒技術對於提昇複雜架構的場景呈像繪製效能佔了相當大的份量。如圖2.2所示。

Algorithm Steps：：：：

Step 1 Locate the current cell Step 2 Render this particular cell

Step 3 Recursively test if any adjacent cells are visible because of possible existing portals

Step 4 Render the additional visible cells

FIGURE 2.2 入口篩選處理範例 Cell 1

Cell 2

Cell 3 Cell 4

Cell 5 Cell 6

Camera

(20)

演算法的範例說明㆒簡單的呈像繪圖步驟流程，當然，在實際實作之時將必須朝著使用的資料結構與遊戲的劇情方向來做最佳化處理。而且，全然是室內場景的情況是很少見的，經常都是需要把室內和戶外場景的呈像技術相結合。

(21)

第㆔章第㆔章

第㆔章第㆔章 XSP 資料結構資料結構資料結構資料結構

3.1 前言前言前言前言

就以室內場景型態的即時動作射擊遊戲所使用的碰撞偵測技術來說，遊戲工業界打從十多年前開始直到現在，大多數還是以 BSP 的處理架構為主。當然，

在這些處理架構之㆗也包含了不少是 BSP 變形所衍生出的新架構，不過大部分都只是為了應應遊戲特性而所做的修改，並非單純技術㆖的突破。另外有少部分的架構變化的確是有所改進於遊戲進行時碰撞偵測的整體效能，不過其碰撞偵測的方法還是沒有跳脫BSP 原始的碰撞偵測方式。充其量只是減少了 BSP 樹狀結構的大小，但並沒有改進處理碰撞偵測問題時的複雜度。(關於 BSP 的相關技術與討論，我們在前㆒章節已有做概略的說明)。

因為在碰撞偵測的處理技術㆖並沒有進步，所以在目前大多數的即時動作射擊遊戲的場景設計㆖，遊戲關卡設計師也只好做了某些妥協，期望達到良好的遊戲運作順暢度，或是說可接受的運作速度。譬如說，在大關卡、大場景的遊戲㆞

圖設計㆖就不能太過強調場景的細緻度，必須簡化場景內物體的幾何圖形結構；

若場景內的活動㆟物較多，同樣的場景㆞圖也不能太過細緻，或是被迫必須縮小場景大小…等等。因此，為了解決此類問題，我們就希望能設計出新的資料結構來取代常用 BSP 架構，以及開發應用於此結構㆖的碰撞偵測技術，進而能夠在相同的運算速度環境㆘，能提供更佳的碰撞偵測處理效能，並且減低處理碰撞偵測問題時所需的時間複雜度。

3.2 XSP 資料結構資料結構資料結構的設計理念資料結構的設計理念的設計理念的設計理念

以 BSP 的架構設計來說，在㆔維空間的情況㆘，它是經由㆒連串的平面分

(22)

割方式而劃分出㆒塊塊獨立的區域空間(Area，Cell)。換句話說，場景空間(World space)㆗的每㆒獨立區域空間是由㆒連串具有相關聯性的空間切割平面所定義出的，且這連串的切割平面是以固定的序列方式所串聯的，彼此之間並無可變動的彈性。既然無可變動的彈性，那麼在演算法的設計㆖就很難有所突破，從而獲得處理效能㆖的提昇。另外，BSP 的架構無論在處理碰撞的偵測，或是單純的尋找所處的區域空間等問題方面，在時間軸(Time domain)進行的觀察㆖，其架構並無貢獻。也就是說此次所運算出來的結果對於㆘次將要處理的運算是毫無助益的。

這樣的資訊利用方式對於處理問題的效能提昇也是不太好的演算法設計與做法。為了改進㆖述 BSP 架構㆖的缺點，我們必須設計㆒新的架構來替代它，因此也就產生了XSP(Axis alignment Space Partition)的設計動機。

XSP 資料結構所具備的重要特性：

˙動態式的平面關聯架構

˙BSP 資源繼承

˙時間軸處理繼承

˙方向性處理

˙碰撞偵測演算法的彈性化設計

XSP 的設計觀點可說與 BSP 恰好相反。我們可以想像 BSP 的觀點是由切割平面的角度來看區域空間；XSP 的觀點則是由區域空間的角度來看其凸多邊形構成表面(Face)。XSP 架構設計所依據的主要理由是因為在正常的條件情況㆘，㆒ 物體假設在遊戲場景㆗移動，若此刻正位於某㆒區域空間內，那麼在經驗法則的分析㆘，㆘㆒個時間點物體理應還是位於該區域空間或其相鄰可穿越的區域空間內。所以在物體移動的過程㆗，我們真正需考慮做碰撞偵測計算的應該只有所在區域空間內或其相鄰可穿越的區域空間內的凸多邊形構成表面，而非整個遊戲場景內的所有空間切割平面。

(23)

XSP 的主架構是以區域空間作為其基本的構成單位，且將每㆒個區域空間的凸多邊形構成表面以系統座標軸(World coordinate axes)來將其分類，然後空間區域彼此之間再以入口表面(Portal face)，即可穿越表面來達成相互連結的接點。因此 XSP 結構是利用區域空間之間的快速轉換來達成加速物體在遊戲場景移動後所在位置的更新計算。接㆘來依序說明的是XSP 架構㆘所具備的重要特性：

3.2.1 動態式的平面關聯架構動態式的平面關聯架構動態式的平面關聯架構動態式的平面關聯架構

因為在 XSP 的架構㆘，區域空間才是主角，由它來掌控其凸多邊形構成表面的資料存取，且依系統座標軸來將其分類。因此每㆒構成表面彼此之間並沒有特定的組成關係順序，只有類別的歸屬關係，即屬於某㆒座標軸的類別集合。如此的設計可增加表面間關聯性組合的彈性，打破BSP 的固定式關聯架構(但表面資料內容並無破壞)，用以獲得演算法更能彈性化設計的可能。

3.2.2 BSP 資源繼承資源繼承資源繼承資源繼承

在XSP 架構設計之初，就已考慮希望 XSP 能在資料變動最少的情況㆘繼承所有原有的 BSP 來源資料，以達到最大的資料重複使用性，也就是說能以非破壞性的方式來繼承。如此，遊戲引擎只需在相對應的碰撞偵測處理程式碼做部分的修改就能夠達到計算效能提昇的效果。

3.2.3 時間軸處理繼承時間軸處理繼承時間軸處理繼承時間軸處理繼承

以往在 BSP 的架構㆘處理碰撞偵測之類的問題，每次運算出來的結果都無法對其接㆘來將發生的碰撞處理提供幫助，也就是說每次的碰撞運算都是㆒個獨立發生的事件。如果說我們能妥善的利用前㆒次運算結果，這勢必將對我們在碰撞處理速度㆖達到提昇的效果。所以在 XSP 的設計架構㆘，提供了碰撞處理演算法能夠設計出運算結果的傳遞效果，也就是說在時間軸㆖觀察，資料的碰撞處理結果能夠向㆘繼承，而非單獨偶發的單㆒事件。

(24)

3.2.4 方向性處理方向性處理方向性處理方向性處理

在 BSP 的架構㆘，我們只有前、後的兩種可能的方向性移動，對於㆓維、

㆔維的空間是無法提供完善的碰撞資料篩選技術使用。關於資料篩選，我們以經驗法則來分析，只有面對物體移動方向的表面才有產生碰撞的可能。所以針對此

㆒特性，若能以移動方向來事先篩選出所有可能產生碰撞的表面，然後再行做碰撞偵測運算，就能大幅減少所需的資料運算量，從而達到效能提昇的目的(但計算的時間複雜度並無降低)。為了在 XSP 的架構㆘提供具有較好的方向性移動及整合外框盒(Bounding box)的碰撞偵測的技術，所以我們使用系統座標軸作為平面方向類別分類的基準。同樣的技術也能轉而運用於 PVS ㆖，減少畫面更新時所需繪製的多邊形資料量，提昇即時繪圖的速度。

3.2.5 碰撞偵測演算法的彈性化設計碰撞偵測演算法的彈性化設計碰撞偵測演算法的彈性化設計碰撞偵測演算法的彈性化設計

XSP 的資料架構相對於 BSP 來說是以較寬鬆的方式來組成。因為 XSP 採取以單㆒分割空間為單位，內含利用㆔維座標軸所分類而成的六類標記表面群組資料。由於每個單㆒資料群組的使用於否取決於即時運算時的需要，不同於 BSP 的固定式樹狀資料搜尋結構。換句話說，如此的設計㆘能提供較有效率的資料使用率。再者，應用於碰撞偵測演算法的設計㆖也較 BSP 更為彈性，發展空間更大。

3.3 XSP 的資料架構的資料架構的資料架構的資料架構

XSP 的資料是以區域空間作為基本的構成單元。如圖 3.1(a)所示，㆒個簡單的正六面體的區域空間範例，顯示區域空間實際㆖的視覺圖樣。而圖3.1(b)所示其構成平面的分類狀況。因為我們採以系統座標軸來作為分類的基準，所以正六面體的六個表面就洽好各分屬於每㆒個座標軸類別。兩 XSP 區域空間的連接方式是靠相鄰表面的聯集方式來達成，如圖3.1(c)所示，㆒亮灰色的表面同屬於左

(25)

方和右方的區域空間內。若此亮灰色表面左方的區域空間屬性為非實心空間，那麼此表面就為㆒入口表面，即可穿越性的表面，且右方區域空間的屬性也同是如此，那麼就意旨我們能經由此入口表面來往這兩區域空間。因此把這左右兩區域空間標示成它們可透過此㆒亮灰表面相互串接。XSP 是發展自 BSP 的，並保留使用BSP 原始表面資料的相容特性。因為 BSP 的建構方式是以凸多面體的切割原則來分割空間，所以在此不會發生有多區域空間共用㆒相鄰表面的情況，至多只有兩區域空間共用單㆒表面而已。

接㆘來我們舉㆒簡單的例子來說明如何在 XSP 所產生的區域空間㆗移動。

圖3.2 範例㆗所標示的區域空間 A、C、D、E 和 F 為非實心的區域空間，所以我們可以在其內部活動。另外，再藉由區域空間彼此所相鄰的入口表面相連接，因此我們可以輕易的來往於A、C，C、D，C、E，D、F 和 E、F 之間；區域空間

(a)

+x +y

+z

FIGURE 3.1 區域空間平面的座標軸類別分類與連結範例 (b)

+x +y

+z

(c) +x +y

+z

+x +y

+z portal face

AREA 1 AREA 2

(26)

B 為實心的區域空間，所以我們無法進入且不能在其內部活動。區域空間 B 實際

㆖是並不存在於XSP 的資料內的，這裡只是為了便於舉例說明所以才標示出來；

區域空間 G 也是屬於非實心區域空間，但是由於它在空間分割處理的過程㆗已知發生了問題，所以倘若允許物體可以進入此區域㆗移動，就很可能會造成往後在碰撞偵測處理㆖的錯誤產生。因此我們會強迫的把區域空間 G 標示為實心區域空間來防止問題的發生。

至此我們可以對於BSP 與 XSP 資料結構來做個特性比較。BSP 強調於切割平面的樹狀結構與切割後的實心區域空間之間的關係。反之，XSP 強調於入口表面與入口表面連接以及非實心區域空間之間的關係。而這兩種不同的資料結構的設計理念恰好相反，㆒個針對在實心部分，另㆒個則在非實心部分。對於 XSP 的架構，在此提出兩種不同結構型態。㆒種是複合式的結構，另㆒種是單㆒的結構。複合式與單㆒結構的最大不同點是在於是否要讓XSP 完全取代 BSP 在遊戲引擎內所扮演的角色。

3.3.1 複合式複合式複合式複合式XSP

複合式 XSP 架構只是為了針對碰撞偵測處理效能提昇的單㆒目的所考量而設計的。在這個架構㆘，XSP 只負責快速處理碰撞偵測，其它的問題還是交由 BSP 來解決。所以在如此的設計㆘，遊戲引擎只需做小幅的程式碼修改就可完成支援。

G A

B

C D

E F

FIGURE 3.2 區域空間的移動連結範例

(27)

複合式 XSP 的架構如圖 3-3(a)所示，㆒層為原始的 BSP 結構，另㆒層則是 XSP 的結構。兩層的結構彼此之間在運作㆖實際是獨立而分別進行的，而資料的對應關係則是每㆒個BSP 的切割空間都有㆒ XSP 區域空間與其對應。XSP 的區域空間是以多對多的關係連結，且此連結關係是依靠 XSP 區域空間的入口表面來達成。又因為入口表面連結關係存在的唯㆒性，所以我們可以使用全域搜尋的方式來完成連結的動作。

3.3.2 單㆒單㆒單㆒單㆒XSP

單㆒XSP 結構是為了整合 PVS 與其它所有原先需要使用 BSP 做搜尋處理計算而設計的，也就是希望能完全取代 BSP 的資料結構。不過在此設計架構㆘，

遊戲引擎需做大幅度的程式碼修改才可完成支援，所以在論文研究㆗我們並沒有繼續發展㆘去，但是卻也提供了㆒個讓整體系統效能提昇的想法。圖3.3(b)概略的表示單㆒XSP 的結構。

FIGURE 3.3(b) 單㆒ XSP 架構範例 FIGURE 3.3(a) 複合式 XSP 架構範例

BSP Level

XSP Level

area connection

°

logical map for BSP to XSP

¬

(28)

3.4 XSP 資料的建構演算法資料的建構演算法資料的建構演算法資料的建構演算法

接㆘來要說明的是XSP 資源檔建立的演算法，其演算法流程就如圖 3.4 所表示。

XSP 資源檔建立的演算法在開始之初會先讀取原始的 BSP 檔案資料作為初始資料，然後再依序對每㆒個存在於BSP 檔案裡的可見模型(Visible model)來做 BSP 轉換成 XSP 資料格式的動作。關於 BSP 與 XSP 的資料格式與結構，我們在此做個簡單的說明：

FIGURE 3.4 XSP 資料建構流程圖 Load BSP File

Build Fake World BSP Tree

Portalize World

Build Fake Clip BSP Tree

Register Faces / Areas

Link Areas recursively build all of the visible models pre-test each area for

sticking prevention

Analyze Areas Write XSP File

Â

rebuild the fake BSP tree for the XSP data construction

Á

Â

(29)

3.4.1 資料格式方面資料格式方面資料格式方面資料格式方面

BSP 與 XSP 的檔案資料儲存格式方面都是採用單㆒檔案，內含複合式資料單元的方式儲存。資料的儲存方式是以資料的類別依序堆疊儲存。BSP 檔案內儲存的內容大致可以劃分為最佳化的BSP 場景樹資料集合與最佳化的 BSP 碰撞偵測樹資料集合以及其它公用的資料內容；同樣的，XSP 檔案內的儲存內容也可大致劃分為最佳化的XSP 場景區域連結資料集合與最佳化的 XSP 碰撞偵測區域連結資料集合以及其它公用的資料內容。

3.4.2 資料結構方面資料結構方面資料結構方面資料結構方面

Inhe ritanc e/ Exte ns ion Shar e Private Header

BSP Lump Header

BSP/XSP Lump Entities BSP/XSP Lump Lighting BSP/XSP Lump TexInfo BSP/XSP Lump Visibility BSP/XSP Lump Textures

BSP Lump Nodes BSP Lump ClipNodes BSP Lump Leafs

XSP Lump Header

BSP Lump Edges BSP Lump SurfEdges BSP Lump MarkSurfaces BSP Lump Faces

BSP Lump Planes BSP Lump Vertexes BSP Lump Models

XSP Lump Areas

XSP Ext-Edges XSP Ext-SurfEdges XSP Ext-MarkSurfaces XSP Ext-Faces

XSP Ext-Planes XSP Ext-Vertexes XSP Ext-Models

FIGURE 3.5 BSP/XSP 資料檔案內容架構

(30)

BSP 與 XSP 的資料檔案內容架構如圖 3.5 所示，其重點說明如㆘。

Header：：：：

資料檔案的檔頭部分主要是紀錄檔案內每㆒筆 Lump 資料的長度、讀取位址、Lump 內的組成單位資料個數以及其它參考資訊。

C Description：

typedef struct {

int fileofs, filelen;

} lump_t;

int version;

lump_t lumps[HEADER_LUMPS];

} dheader_t;

Private：：：：

圖 3.4 ㆗所示的私有部分是用來表示 BSP 與 XSP 檔案㆗各自獨立擁有的 Lump 資料內容。在 BSP 方面有 Nodes、ClipNodes 與 Leafs Lump；在 XSP 方面則有Areas Lump，這些 Lumps 都是屬於私有類別的部分且用來儲存描述空間分割狀態的資訊。Nodes Lump 用於描述㆒般狀況㆘的 BSP 空間分割節點資訊；

ClipNodes Lump 是針對碰撞偵測問題處理的 BSP 空間分割節點資訊；Leafs Lump 紀錄了BSP 空間分割的端點資訊；Areas Lump 則是 XSP 用來描述空間分割的統合資料內容。

(31)

C Description：

int planenum;

short children[2]; // negative numbers are -(leafs+1), not nodes short mins[3]; // for sphere culling

short maxs[3];

unsigned short firstface;

unsigned short numfaces; // counting both sides } dnode_t;

int planenum;

short children[2]; // negative numbers are contents } dclipnode_t;

// leaf 0 is the generic CONTENTS_SOLID leaf, used for all solid areas // all other leafs need visibility info

int contents;

int visofs; // -1 = no visibility info

short mins[3]; // for frustum culling short maxs[3];

unsigned short firstmarksurface;

unsigned short nummarksurfaces;

(32)

byte ambient_level[NUM_AMBIENTS];

} dleaf_t;

unsigned short areanum;

int contents;

short mins[3];

short maxs[3];

unsigned short firstmarksurface[6]; // marked axis alignment faces entry index unsigned short nummarksurfaces[6]; // number of axis alignment faces per axis group } xsp_area_t;

Share：：：：

圖3.4 ㆗所示的公用部分是指 XSP 對於 BSP 檔案所繼承使用的 Lump 資料內容。這些 Lumps 資料都是與碰撞偵測處理的問題無關，比如紀錄遊戲場景內表示物件參數資料的Entities Lump、紀錄光影資料(Lightmap)的 Lighting Lump、

紀錄貼圖紋理資料的Textures 與 TexInfo Lump，以及紀錄 PVS 資料的 Visibility Lump。

C Description：

int nummiptex;

int dataofs[4]; // [nummiptex]

} dmiptexlump_t;

(33)

#define MIPLEVELS 4 typedef struct miptex_s { char name[16];

unsigned width, height;

unsigned offsets[MIPLEVELS]; // four mip maps stored } miptex_t;

typedef struct texinfo_s {

float vecs[2][4]; // [s/t][xyz offset]

int miptex;

int flags;

} texinfo_t;

Inheritance/Extension：：：：

圖3.5 ㆗所示的繼承與擴充部分是指 XSP 對 BSP 檔案除了繼承使用原始的 BSP Lump 資料外還附加擴充了 XSP 本身所使用的 Lump 資料內容。這些 Lumps 都是用來紀錄遊戲場景內幾何結構物件的資料內容，如 Edges、SurfEdges、

MarkSurfaces、Faces、Planes 與 Vertexes Lump，另外還有紀錄遊戲場景內物件模組的Models Lump。

C Description：

float mins[3], maxs[3];

float origin[3];

int headnode[MAX_MAP_HULLS];

int visleafs; // not including the solid leaf 0

(34)

int firstface, numfaces;

} dmodel_t;

typedef struct { float point[3];

} dvertex_t;

typedef struct { float normal[3];

float dist;

int type;

} dplane_t;

// note that edge 0 is never used, because negative edge nums are used for // counterclockwise use of the edge in a face

unsigned short v[2]; // vertex numbers } dedge_t;

承接㆖述可見模型的內容，每㆒個可看見的模型都會有㆒個基本的 BSP 樹來描述其所在的空間分割狀態，我們通常稱這個BSP 樹為場景 BSP 樹(World BSP tree)。另外，這可見模型還可能附帶著幾組針對碰撞偵測而預先最佳化處理所建立的BSP 樹，我們通常稱這種 BSP 樹為碰撞偵測 BSP 樹(Clipping BSP tree)。因為我們無法確定指定轉換的 BSP 檔案內所紀錄的資料格式是否還是以標準的 BSP 結構方式儲存(答案通常是否定的)，所以我們必須重建出原始的 BSP 樹，以方便我們後續作為XSP 轉換時使用。

(35)

3.4.3 重製重製重製重製偽偽偽偽場景場景場景場景BSP 樹樹樹樹////偽偽偽偽碰撞偵測碰撞偵測碰撞偵測碰撞偵測BSP 樹樹樹樹

重製場景BSP 樹或碰撞偵測 BSP 樹是為了建立出原始的 BSP 樹來方便我們對場景空間做重新的分割，目的是找出XSP 資料結構時所需要的入口表面(Portal face)資料，因為入口表面通常是不予以紀錄於實體 BSP(Solid BSP)類型的 BSP 樹狀結構。

Algorithm Steps:

Case 1 Build fake world BSP tree

Step 1.1 recursively trace the world BSP tree data in game to prepare to reconstruct the standard BSP tree

Step 1.2 use Portalize method to reconstruct the standard BSP tree and find out the portal faces

Case 2 Build fake clipping BSP tree

Step 2.1 recursively trace the clipping BSP tree data in game to prepare to reconstruct the standard BSP tree

Step 2.2 use Portalize method to reconstruct the standard BSP tree and find out the portal faces

演算法步驟說明：

重製BSP 樹的演算法使用兩個程序步驟來完成。首先，在重製場景 BSP 樹與碰撞偵測BSP 樹的第㆒步驟會擷取原始 BSP 檔案資料內的切割平面樹狀結構資訊。接著在第㆓步驟就是由此BSP 樹狀結構資訊依序做 BSP 的空間分割動作，

也就是空間區域化分析(Portalize)，其目的就是找出原本不存在紀錄於實體 BSP 樹的入口表面(Portal face)，另外也是為了達到 BSP 資源繼承的目標。

(36)

3.4.4 空間區域化分析空間區域化分析空間區域化分析空間區域化分析

在完成了偽 BSP 樹的建立程序後，接著就是開始執行空間區域化(Portalize) 的分析動作，即標準的BSP 分割動作。利用偽 BSP 樹所提供的資訊來重製空間分割，可以把原始的場景空間(World space)劃分成㆒塊塊的凸多面體區域。把所有劃分出的凸多面體區域做交集，其結果必定是㆒個空集合區域；把所有劃分出的凸多面體區域做聯集，其結果必定是還原完整的場景空間。同樣的我們也是以實作應用於雷神之鎚遊戲引擎的程式碼來做為演算法與實作說明範例。

Step 1 Portalize World

Step 1.1 make head node portals for the global outside node

Step 1.2 recursively build the exact polyhedrons for the nodes and leafs

演算法步驟說明：

空間區域化分析的演算法使用兩個程序步驟來完成。首先，演算法第㆒步驟會產生㆒個外節點的入口表面群組，它是利用場景的外框盒加㆖適當的偏移距離所產生的六個平面。加㆖偏移距離的目的是防止零空間葉節點(Null volume leafs) 的問題產生。利用這六個平面的相互切割可以產生六個入口表面，其結構關聯圖如圖3.6 所示。

演算法的第㆓步驟是把初始化的六個入口表面(平面)與 BSP 樹狀切割平面資訊依序做新的入口平面動態產生與切割程序，其切割的規則如㆘：

(37)

1. 首先，對於目前處理的 BSP 節點產生其廣域平面(Winding plane)，然後再依序與連結於此節點㆖的入口表面(平面)群組相切割。若經過㆒連串的切割後產生了節點表面，則把該表面(平面)連結於目前節點的子節點，作為子節點的廣域平面切割之用，反之則是產生表面(平面)切割錯誤。

2. 對於連結於目前處理的 BSP 節點㆖的入口表面(平面)群組以節點平面切割。其結果可劃分為兩類：

若入口表面沒有被節點平面切割處理：

•入口表面完整的位於節點平面的前方，則把入口表面(平面)連結於前端子節點(Front-side node)與原入口表面所連結的非目前處理節點的另㆒節點㆖。

•入口表面完整的位於節點平面的後方，則把入口表面(平面)連結於後端子節點(Back-side node)與原入口表面所連結的非目前處理節點的另㆒節點㆖。

BSP tree Outside node

+z portal

-z portal -y portal

+y portal

-x portal +x portal

FIGURE 3.6 標頭節點(Head node)初始入口平面關聯圖 back-side link front-side link

(38)

若入口表面被節點平面切割處理：

•入口表面的前端切割表面(平面)連結於前端子節點與原入口表面所連結的非目前處理節點的另㆒節點㆖；後端的切割表面(平面)連結於後端子節點與原入口表面所連結的非目前處理節點的另㆒節點㆖。

以此切割規則依序處理，即可得到最終的每㆒區域空間的構成表面，當然也包含我們想要的入口表面。

3.4.5 區域空間資料分析區域空間資料分析區域空間資料分析區域空間資料分析

每回對偽 BSP 樹做空間區域化分析後，都可以得到㆒組與其相對應的完整區域空間(Area，Cell)幾何資料。接著再把這些幾何資料依序作進㆒步的檢查，

查看該筆資料是否早已存在，若已存在就將其忽略，否則就把資料給註冊儲存。

目的是避免重複性資料造成儲存空間的浪費。另外，我們也會針對每㆒區域空間內所有的標示的平面(Global marked surfaces)做方向性的分類(Axis alignment)。分類的方式是以平面的法向量(Normal)與系統座標軸(World coordinate axes)為基準來分類。接著我們就以我們實作應用於雷神之鎚遊戲引擎的程式碼來做為演算法與實作說明範例。

Step 1 Recursively register all the areas and their constructed faces Step 1.1 if the current BSP tracing node is not a leaf one, then go to

Step 1.5 to continue

Step 1.2 if a leaf node is marked to a solid area, then don’t register it cause of we can never enter it

Step 1.3 test all the registering faces constructed a non-solid area and then

(39)

mark with global index

Step 1.4 if a non-empty area is found, then register its all marked faces with axis alignment

Step 1.5 recursively trace into front/back-side child node for leaf node searching

演算法步驟說明：

區域空間資料分析的演算法首先會嘗試找出葉節點，然後才開始進行區域空間內的構成表面的座標軸分類，如步驟㆒與步驟五的處理程序。在找出葉節點即區域空間後，演算法會先檢查此區域空間是否為非實心區域。因為在實心區域內物體是無法進入移動的，所以我們不須對其檢查且紀錄空間資料，如步驟㆓所示。區域空間是否會被標示為實心區域是根據 BSP 原始資料檔案所提供的資訊而產生的，或是 XSP 在做空間重新分割時為了防止不良的分割區域空間會造成碰撞偵測處理㆖的錯誤產生而強迫標示的，目的是將此不良區域空間剔除。若找到非實心區域則將其所有的構成表面登錄儲存，並以全域的標號標示，如步驟㆔ 所示。在非實心區域構成資料標號後就是執行標號表面的分類動作，分類的方式是以表面的法向量與座標軸來分類，譬如法向量為n(0.7071, 0.7071, 0)則此表面 被標示分類於+x 與+y 的座標軸群組，若法向量為 n(0.5346, -0.2673, 0.8019) 則標示分類於+x、-y 與+z 的座標軸群組，其程序如步驟㆕所示。

設計要記設計要記設計要記

設計要記:::: 把所有構成區域空間的平面來事先加以分類的目的是希望在進行遊戲時碰撞偵測程序的執行能達到以最少的可能碰撞平面來做檢測且做最有效的利用。在進行平面分類時，為何我們會選擇使用系統座標系來作為我們分類的依準?其原因有如㆘幾點:

˙大多的即時動作遊戲都是以外框盒(Bounding box)來用以檢測兩物體間

(40)

是否有碰撞產生的方式。其㆗又以系統座標軸的外框盒(Axis Alignment Bounding Box/AABB)更是適合用於雷神之鎚之類的動作射擊遊戲遊戲。所以我們希望把外框盒設計的優點納入平面分類之㆗。

˙描述物理系統㆘的物體移動時包含兩個主要的向量。㆒個是目前物體所受到的作用於本身合力的施力大小/方向。在即時動作的環境條件㆘，也可以想成目前物體的運動速度的大小/方向(可由簡易的物理力學定理推導說明)。另㆒個向量就是目前物體嘗試要移動距離與方向，這是由㆖㆒次的運動速度所推測出來的結果。這兩個主要向量可以作為我們挑選可能產生碰撞平面的選擇依據。這兩向量通常也是以系統座標軸的方式表示。

˙平面分類維度的準則就是希望不使碰撞偵測演算法的設計複雜度增加㆘

達到最好的碰撞偵測計算效能，所以如何選擇適當的分類維度就需要仔細的考慮了。

綜合以㆖幾點，所以我們在此選擇以㆔維的系統座標軸(六類)為分類基準。

除了分類的維度外，每㆒類別所涵蓋的範圍也是㆒個設計考量的重點。就以我們選擇㆔維的系統座標軸來說，每㆒類別的可校調範圍是 +54.73561032° ~ +90°

(可由簡易的幾何空間轉換計算得知)。但是經由實作結果分析，因為每㆒區域空間的幾何形狀幾乎都不相同，所以很難找出㆒個能統㆒適用的最佳範圍。因此我

維度高優點:

類別資料特性集㆗

類別重複性資料少缺點:

演算法設計難度高資料結構複雜計算效能由高漸低維度低

優點:

演算法設計難度低資料結構簡單計算效能由低漸高缺點:

類別資料特性不集㆗

類別重複性資料多資料結構複雜

最佳維度

(41)

們只好放棄資料最佳化的可能而被迫採用安全度最高、相容度最高的 +90° 範圍。

3.4.6 區域空間連結區域空間連結區域空間連結區域空間連結

完成了空間區域化分析與平面分類後，接著就是進行區域空間連結的動作。

在此之前我們曾提過若有兩區域空間相鄰，則它們必定具有共同使用的表面，且表面共用的情況也只會以㆒對㆒的形式出現，不可能有兩個以㆖的區域空間以㆖

共用㆒表面的狀況發生。因此我們就可以放心、大膽的使用入口平面來完成連接的動作。同樣的，我們也以我們實作應用於雷神之鎚遊戲引擎的程式碼來做為演算法與實作說明範例。

Step 1 Link all areas generated by each visible model Step 1.1 link two areas via share portal face searching

演算法步驟說明：

區域空間連結的演算法目的是依序對每㆒個可見模型所產生的所有 XSP 區域空間執行串接的動作。串接的方法是利用入口表面來連結，而入口表面的定義是該表面同時存在於兩區域空間，反之視為實心表面(Solid face)。每㆒表面都會

+90°

優點:

簡易的類別選擇方式，計算效能影響最低

缺點:

類別資料重複度最高 +54.73561032°

優點:

類別資料重複度最低缺點:

複雜的類別選擇方式，

計算效能可能因此降低

最佳範圍

(42)

擁有㆒雙向連結的索引指標，若為入口表面則此雙向連結指標將分別指向兩區域空間的全域索引，如此即完成所謂區域空間連結的動作。反之此表面的雙向連結指標都會標示為參考無效指標(Null reference pointer)。

設計要記設計要記設計要記

設計要記::::在做區域空間的連結之前，也曾考慮做CSG 合併的動作。目的是為了減少區域空間的個數，而且也可藉此修正因為不良的 BSP 演算法所產生的細碎或不必要的區域空間分割。雖然空間的合併可以達到㆖述的好處，但是也會無形

㆗造成單㆒區域空間的平面數的增加，造成計算量的變大而降低計算效能。若把區域空間內的平面也做 CSG 合併來克服平面數增加的問題，又會破壞舊有的 BSP 資料架構，而影響遊戲引擎的運作。除非是改採單㆒的 XSP 資料架構，但是為此遊戲引擎要做的轉換修改工程十分浩大，所以論文㆗就不多做討論了。

在完成了區域空間的連結動作後，最後只剩㆘㆒個步驟就可完成完整的XSP 資源檔的建構工作。那就是對每㆒個區域空間都做其安全性的檢查。因為在XSP 的架構設計㆘，每㆒個區域空間都會接受來自鄰近其它區域空間所貢獻的計算結果資訊；每㆒個區域空間都會提供鄰近其它區域空間自己的計算結果資訊。所以假使有㆒個不安全的區域空間存在於連結之㆖，那麼就很有可能造成以後在遊戲進行時碰撞偵測計算的錯誤發生。解決不安全的區域空間的方法很容易，只須把不安全區域空間的內容屬性標示成為實心的區域空間(Solid area)，那麼往後我們在遊戲場景的移動過程㆗就無法進入此㆒不安全的區域空間之內，所以也就不會造成計算錯誤的產生了。而可能造成不安全區域空間產生的原因有幾點，例如，

在原始的 BSP 樹建構時就不是以完全符合凸多面體構成原則來建立的，所以在重製空間分割時自然就會產生不安全的區域空間。再者就是區域空間實在是太小了(Tiny area)，小到無法正確的分類其構成平面的類別與正確的向外方向向量…

等等都是可能的原因。

(43)

3.5 XSP 資料建構範例資料建構範例資料建構範例資料建構範例

a

b c

d

e f

g h i

j k

L N M

p q

r

s

t u

v w x

(a) (b)

(d) (c)

M L

N a

b c

d e

f g

h i

j k

(e)

FIGURE 3.7 XSP 資料建構範例 (f)

(44)

這裡我們舉㆒簡單的場景㆞圖來說明解釋 XSP 如何來建構其場景分割資料。首先，如圖3.7(a)所示，㆓維場景㆞圖內隨意分布㆔個實心物體。經由 BSP 的空間分割程序處理，我們可以得到對應的場景㆞圖空間分割結果。圖3.7(b)為 BSP 空間分割平面的圖樣；圖 3.7(c)為 BSP 空間分割後所產生的㆔個實心區域空間，且相同於原始分布於場景內的㆔個實心物體區塊；圖3.7(d)為 BSP 空間分割的樹狀資料結構。其㆗，分支端點為分割平面，葉端點為實心區域空間。因為此 BSP 樹狀資料結構只有在葉端點為實心區域空間時才會記錄其區域空間的構成表面資訊，所以我們也稱這種BSP 樹為實心 BSP 樹(Solid BSP tree)。最後，如圖3.7(e)所示為 XSP 場景分割結果。XSP 資料結構所計錄的場景區域空間資料為 p、q、…、w 與 x 編號的區域空間。在經由入口表面的方式連接，所有被標示的 區域空間可以相互流通，其結果如圖3.7(f)所示。

(45)

第㆕章第㆕章

第㆕章第㆕章碰撞偵測演算法碰撞偵測演算法碰撞偵測演算法碰撞偵測演算法

4.1 前言前言前言前言

經由前兩章節的介紹，我們已把論文研究㆗所使用的空間分割技術約略的做了㆒個說明。接㆘來於本章節所探討的內容，也就是論文研究㆗的重點，快速碰撞偵測的演算法設計[11, 22, 27, 29, 31, 32, 33]。在論文㆗我們使用兩套演算法來作為實驗效能的比較。對照組是id software 在雷神之鎚遊戲㆗所開發使用的 BSP 碰撞偵測技術，而實驗組就是我們自行所研究設計的 XSP 碰撞偵測技術。在內容的編排㆖，我們將以 BSP、XSP 依次說明介紹，並對其演算法的利、弊及時間複雜度加以分析。

4.2 BSP 架構的碰撞偵測技術架構的碰撞偵測技術架構的碰撞偵測技術架構的碰撞偵測技術

首先要說明的是BSP 碰撞偵測技術，在這裡所提的 BSP 碰撞偵測技術雖然是應用於id software 的雷神之鎚遊戲，但是不管它的資料架構，還是資料搜尋的 方式都是以標準的 BSP 方式來去製作的。雖然細節部分會因遊戲而做些許的改變，但主體還是㆒個標準的BSP 架構。

BSP 的固定式樹狀關聯資料結構在應用於偵測處理空間㆗某㆒段欲移動的路線是否會產生碰撞是很容易的，只需做 BSP 樹的資料搜尋動作，也就是做㆒ 連串的移動路線線段分割。但是，實際運用於遊戲時就沒有這麼單純了，因為在遊戲場景㆗會有許多可移動的物體，譬如㆒些自發性移動的物體，像是㆟物，動物，機械化裝置…等等；而觸發性移動的物體，像是㆒些道具，裝置物品，陷阱機關…等等。為了達成讓這些所謂可移動的物體移動，通常我們都各自給予其擁有獨立的 BSP 樹(包括場景樹和碰撞偵測樹)，然後就以這些獨立的 BSP 樹來描

(46)

述物體在空間㆗的狀態。另外，還有㆒種是隨機產生的物體，例如使用武器時所發射出子彈，機關觸發時發射出的暗器…等等。㆖述兩種型態的物體都會影響我們 BSP 架構㆘的碰撞偵測方法。為了方便說明，接㆘來我們就分成兩個部分來說明BSP 架構㆘處理碰撞偵測的方法。

4.2.1 BSP 結構㆖已知物體的碰撞偵測處理方法結構㆖已知物體的碰撞偵測處理方法結構㆖已知物體的碰撞偵測處理方法結構㆖已知物體的碰撞偵測處理方法

所謂已知物體是指不管碰撞或被碰撞的物體在遊戲場景設計之初就已預先做了碰撞偵測最佳化處理的計算。最佳化處理的理由，譬如，㆟型物體就㆟型物體的特性，如身材比例(身高比體寬長)，行動方式(兩腳站立)，犬型物體也有犬型物體的體型比例(身高比體長短)，行動方式(㆕肢著㆞)。換句話說，當我們在遊戲場景編輯器編輯㆞圖時就能預知哪些物體是否會出現，在什們情況㆘會出現，且能對這些物體做預先計算而產生碰撞偵測處理的最佳化BSP 碰撞偵測樹。

所以屆時我們在遊戲的進行過程㆗，只需選擇最適合的碰撞偵測 BSP 樹來做測試即可。如此可以簡化、降低即時運算時所需的計算量，進而達到快速偵測的目的，而且還能突顯物體的行動特性。接㆘來我們就以id software 實作於雷神之鎚 遊戲引擎的程式碼來做為說明範例[15]。演算法首先會對遊戲場景做碰撞偵測，

因為遊戲場景是主要的碰撞產生來源，之後再對其它可能發生碰撞的物體依序做碰撞檢查。

設計要記設計要記

設計要記設計要記:之前的內容說明㆗曾提到遊戲場景是即時互動的，所以在場景內的物 體是可自由移動的，那麼在 BSP 的固定式樹狀關聯資料結構㆘，要如何達到即時互動碰撞呢？其實要達到這樣的效果是很容易的，因為我們描述㆒個物體在空間㆗移動是不需要重新建構其BSP 樹，只需更新 BSP 樹的區域座標系的原點即可(origin of local/private coordinate system)，就像我們在空間㆗移動也只是座標位置的改變而已，對於我們本身的型態㆖並沒有改變。所以針對不同的物體做碰撞偵測，就是對不同的碰撞偵測BSP 樹做測試罷了。重點是在我們測試之

(47)

前需做座標轉換的動作(coordinate transformation)，也就是移動路線座標減去系統座標系和區域座標系原點之間的差值。如此就能將㆒堆原本彼此獨立的BSP 樹串聯起來，達到即時互動碰撞的效果。

- Clip to world -

Step 1 Clip to entity begin

Step 1.1 select the clip hull for entity

Step 1.2 make the bsp coordinate translating offset Step 1.3 translate the move path

Step 2 Recursive clip hull check

FIGURE 4.1 BSP 碰撞偵測處理流程圖

first check with the world entity and then other links

Á

if the trace is fully stay on the next front/back side child node, then check forward with it

Â

if the content of the other side child node is solid, then stop checking and return

otherwise continue recursive check on it

ÁÂ

Move

Clip Move to Entity

Hull for Entity

Recursive Hull Check

Hull Point Contents check the sibling node

by any possibility of forward checking

Â

(48)

Step 2.1 if the node is a leaf, then Step 2 is done Step 2.2 find the point distances with clip plane

Step 2.3 if the current start and end points are both on the front-side (of clip plane), then switch the check process to the front-side child node and go back to Step 2

Step 2.4 if the current start and end points are both on the back-side (of clip plane), then switch the check process to the back-side child node and go back to Step 2

Step 2.5 calculate the cross point with DIST_EPSILON on the near side if a cross point is the next current start point, then switch check

process to the back-side child node and go back to Step 2 if a cross point is the next current end point, then switch check

process to the front-side child node and go back to Step 2 Step 2.6 if the current trace state is solid then Step 2 is done, cause we

never got out of the solid area

Step 2.7 if the other side child node of the current node is not a solid one, then continue checking with this child node and go back to Step 2

Step 2.8 do the same as Step 2.6 Step 2.9 stuck fixing, if needed Step 3 Clip to entity end

Step 3.1 add the translating offset to make translated back - Clip to links -

Step 4 Clip to linked entities

Step 4.1 if a linked entity is not itself, then enforce Step 1 to Step3 for clipping check

題目：動作射擊遊戲的進階碰撞偵測演算法研究

㆗ 華 大 學 碩 士 論 文