本論文第三章介紹整合系統的功能以及處理函式的方法，而第四章將會介紹
整合系統另一個重要的部分，也就是光線追蹤的kernel 端程式，接下來本論文會
分成數個小節討論所本系統使用的光線追蹤演算法細節。
第一節 演算法概述
光線追蹤是一種模擬光線在三維空間中根據物體的表面特性所發生的互動 行為，Whitted [8]提出了 Whitted Ray Tracer 模型來定義光線追蹤的流程，其演算
法的順序如下，首先以觀察者位置與成像平面的各個像素點形成方向向量，而這
些向量可以產生等同於對畫面取樣的光線。接下來光線透過與三維空間的物體作
交點測試而得到碰撞點，再利用碰撞點檢查與光源之間是否有物體遮蔽，這個階
段產生的是陰影光線並且利用光照公式計算出成像的顏色資訊。最後根據物體的
表面特性，從交點出發並應用物理的反射或折射公式再產生新的光線繼續進行新
的一輪追蹤，而達到終止條件時會將光源攜帶的資訊回傳成為像素點的顏色。
第二節 實作細節
回到圖 3 整合系統流程圖，在圖右邊是平行化光線追蹤流程，第一步的動作，
會針對場景資料製作加速結構，進行光線追蹤時略過不必要的交點測試，可以讓
21
運算效率大幅提升，由於光線追蹤昂貴的運算成本，加入場景加速結構已經是不
可或缺的一環。至於流程後面的部分，本整合系統的設計參考Whitted Ray Tracer
模型，唯一不同之處是 OpenCL 語言不能使用遞迴函式呼叫，所以必須以迴圈作
為代替，滿足原本模型中遞迴的光線產生。
本論文的光線追蹤實際程式以 OpenCL 語言撰寫，並讓整合系統導向和擷取
原本OpenGL 函式的參數，這些已經在第三章充分敘述過，擷取出的資訊會被用
來作為光線追蹤的前置準備，而目前實作的方式是將場景資料以 OpenCL 全域記
憶體的階層送入裝置，另外只有光源數據是放入私有記憶體，因為對應 OpenGL
固定功能的定義，光源一定會有 GL_LIGHT0 至 GL_LIGHT7 共 8 個數量，因為
數量不多所以光源的數據直接讓所有的工作單位各自持有。
計算交點測試
雖然 legacy OpenGL 固定功能呼叫模式支援點、線、多邊形…等其他物體型
態，但後來在modern OpenGL 後幾乎全部被移除並且只留下三角形為基礎物件形
態，所以本論文的光線追蹤以三角形作為主要支援場景型態。
交點測試對於光線追蹤來說佔了很大比例的運算資源，所以交點測試的演算
法好壞會影響運算效率，因此利用Möller and Trumbore [9]提出的演算法(詳細的
程式碼見附錄A)，可以快速的算出光線與三角形之間的交點，而且不需要求出三
角形在三維空間所形成的平面方程式，然後才讓光線向量與平面方程式求解。
22
除了三角形之外，光源採用光線對球面的交點測試，因為 OpenGL 固定功能
的光源是點光源，因此可以將光源設計成極小的球面來模擬點光源的效果。
光照模型
當交點測試後確定了光線擊中的物體，並且實現成像的顏色，而這個光照模
型最被人所熟知的是Phong [10]提出的 Phong lighting 模型，此模型定義了粗糙表 面的散射光(diffuse)、光滑表面的鏡面反射光(specular)以及場景中固定量值的環境
光(ambient)，其中散射光以物體到光源的向量和觀察點到物體的向量做內積並乘
上物體表面的顏色所形成，本整合系統也參考此模型的散射光作為光照的作法。
場景加速結構
雖然光線追蹤已經使用 OpenCL 操作 GPU 做平行化加速，但其運算量仍相
當龐大，因此光線追蹤必須減少對場景資料的交點測試次數，而這種加速結構中
最常見的是KD 樹與 BVH 樹，本系統參考 PBRT[4]書中的 KD 樹加速結構，根據
場景資料中三角形物件的分布對三維空間分割出樹狀節點並記錄其中擁有的三
角形。而在光線追蹤時先對樹狀結構進行探訪，根據樹狀節點每次進行二分的路
徑選擇，最後只對光線會經過的葉節點其擁有的三角形進行交點測試，這樣其他
光線到達不了的空間所包含的三角形就完全不會做交點測試，因此可以大大的減
少不必要的運算。
23