硬體光追（Hardware Ray Tracing）
- 加速結構（Acceleration Structure，AS）
  - AS 策略
- Ray Tracing Pipeline
  - Ray Generation Shader
  - Intersection Shader
  - Hit Shader
- Ray Query
軟體光追（Software Ray Tracing）
- Screen Space Ray Tracing
- Height Field Ray Tracing
- Voxel Tracing
  - Voxelization
  - Voxel Ray Marching
  - Voxel Cone Tracing
- SDF Tracing / Sphere Tracing
  - Global SDF + Mesh SDF
  - AABB Tree + Local Distance Field
  - Enhanced Sphere Tracing
  - Accelerating Sphere Tracing
  - Segment Tracing
  - SDF Cone Tracing
一些實踐
- Primary Ray
- Shadow Ray & Visibility Ray
  - 半透明陰影 - ray query
- Material Ray
- Low-Accuracy Ray + Short Ray
參考

實時光追（Real-time Ray Tracing）往往是綜合了 sampling、ray casting、denoising 等各方面的方案，本文主要記錄的是 ray casting 這部分，但是術語可能更多仍然稱為 ray tracing，

硬體光追（Hardware Ray Tracing）

ray tracing 最經典的實作莫過于 ray traversal：投射一條 ray 然后遍歷所有 triangles 去做 ray-triangle 相交測驗，并得到對應的 hit point，但是場景中的 triangles 數量往往數量龐大，ray traversal 也變得非常耗時，而后為了加速相交測驗，便引入了加速結構（BVH，八叉樹，k-d樹等），來剪枝掉一些不可能發生相交的 triangles；但即便如此，軟體實作 ray traversal 仍然是件耗時的事，

再后來，Nvidia 推出了 RTX 系列顯卡，開始提供硬體單元來大大加速 ray traversal 這一程序，使得 real-time ray tracing 成為了可能，從此之后，GPU 廠商都逐漸開始普及硬體光追的支持，

加速結構（Acceleration Structure，AS）

硬體光追提供了兩大層級的 AS，我們可以對這兩大層級（BLAS 和 TLAS）進行配置，但不用關心 AS 具體采用哪種空間加速結構或者具體實作，

BLAS（Bottom Level Acceleration Structure）：底層加速結構，一個 BLAS 對應一個 instance，其葉結點為一個 primitive（一般就是一個 triangle，如果使用自定義圖元則就是一個把該圖元包起來的 AABB box），
TLAS（Top Level Acceleration Structure）：頂層加速結構，一個 TLAS 對應一個場景，其葉結點為一個 instance，

注：我們在 GPU 里通過 ray traversal 得到 hit point 后，要獲取 hit point 的材質屬性是非常困難的，因為材質函式和引數等都是在 CPU 端的，而粗暴的直接根據 geometry id 和 material id 去 CPU 拉取對應的 shader 和引數無疑是不可行的（通信時間過長），

為了解決這個問題，才有了 shader table 的機制：GPU 里的 shader table 預先存盤著一堆 shader records，每個 record 包含一個或多個 shaders（其實就是 hit group）以及引數；再得到 hit point 后，根據 geometry id 和 material id 去索引到相對應的 shader record，并直接執行對應的 shader，無需通知 CPU，

AS 策略

盡可能將相同性質的多個 mesh 合并到一個 BLAS 中，而不是一個 mesh instance 一個 BLAS，這樣可以減少 BLAS 的數量，從而降低 TLAS 包含的 instances 數量，例如：由多個 mesh 組合的物件（往往需要同時rebuild或者update），可以將這多個 mesh 塞進一個 BLAS 里；所有靜態 mesh 都塞進一個 BLAS 里.....
TLAS 的質量遠比 BLAS 要重要：因為所有 ray traversal 都會經過 TLAS 先，因此對于 TLAS，我們更傾向于 rebuild 而不是 update；對于 BLAS，我們更傾向于 update 和壓縮 BLAS，
盡可能減少運行時的 build/update AS 次數：物體有發生變化時，才去觸發 build AS/update AS；對 skinned meshes，可以考慮預先構建多個高質量的 AS，在不同的關鍵姿勢采用不同的 AS，而不是采用一個每幀更新的 AS，

	PREFER_ FAST_ TRACE	PREFER_ FAST_ BUILD	ALLOW_ UPDATE	Properties	Example
1	no	yes	no	盡可能快速的 build AS，trace 性能會低于 #3 和 #4，	完全動態的幾何物體，如粒子、破壞物、移動劇烈的物體（爆炸）等，這種往往都需要每幀重建 AS，
2	no	yes	yes	build AS 比 #1 稍微慢一些，但允許非常快速的 update，	LOD level 低且不那么容易被 ray 命中的動態物體，
3	yes	no	no	trace 性能最好，但 build AS 會比 #1 和 #2 都慢，	靜態物體，
4	yes	no	yes	trace 性能很好，只比 #3 慢一點點，AS 的 update 也只比 #2 慢一些，	重要的角色模型（如玩家主角）；LOD level 高且比較容易被相當數量的 rays 命中的動態物體，

Ray Tracing Pipeline

ray tracing pipeline 是與 graphics pipeline，compute pipeline 并列的一種新流水線，主要提供有 ray generation shader，intersection shader，和三種 hit shader 可編程，

Ray Generation Shader

在該 shader 里可以呼叫 TraceRay() 介面來使用 ray tracing pipeline 硬體光追：對 AS 進行 ray-traversal，并根據 intersection 的情況來自動呼叫對應的 hit shader 來完成 hit point 的著色，

TraceRay() 一般不可以在別的 shader 中呼叫，只能在 ray tracing pipeline 的相關 shader（RGS，MS，CHS之類的）中被呼叫，但一般推薦只在 RGS 中呼叫，不推薦遞回呼叫（如 RGS 呼叫 TraceRay() 觸發 CHS，CHS 再呼叫 TraceRay()），因為遞回呼叫往往不如改造成多輪 pass 迭代，

Intersection Shader

如果我們需要的不是默認的 ray-triangle intersection，而是 ray 與自定義的圖元（例如可以是 sphere）做 intersection，那么就需要撰寫 intersection shader，不過注意的是，使用 ray-triangle intersection 是最高效的，因為它將使用硬體內置的 intersection 函式，因此除了特別需求之外，我們最好盡量使用 ray-triangle intersection，

Hit Shader

any hit shader（AHS）：當 hit point 命中的是半透明 triangle 時，來決定是否 ignore 掉本次 hit point，通常用于累積 hit point 的 alpha 值，如果累積 alpha 值較低則選擇 ignore ，否則終止 tracing 提交本次 hit point，
closest hit shader（CHS）：負責對生成出來的最終 hit point 計算著色結果，通常用于計算 hit point 的 radiance 或 material 等，
miss shader（MS）：如果沒有生成最終的 hit point，則會運行 MS，通常用于計算天空盒環境光照，或者 visibility ray 中的 shadow factor 等，

Ray Query

ray query 則相當于一個各個 pipeline 都能呼叫的查詢介面（在 CS，PS 乃至于各種 hit shader 等都能呼叫），而不是像 ray tracing pipeline 那樣獨立的一套管線，

通過呼叫 TraceRayInline() 介面來使用 ray query 硬體光追：同樣對 AS 進行 ray traversal，但與 ray tracing pipeline 不同的是，ray query 只會提交 intersection 的資訊（position，primitive id，instance id 等），并不會呼叫任何其它 shader，

ray query 明顯就是 ray tracing pipeline 的閹割版，或者也可以說是 ray tracing pipeline 的子部件，基本只負責了 ray-traversal 的操作，而 ray tracing pipeline 不僅做了 ray-traversal 的操作，還能自動呼叫合適的 shader 對 hit point 進行著色（一般是用于計算材質），

軟體光追（Software Ray Tracing）

Screen Space Ray Tracing

SSRT 可能是大家都比較熟悉的軟體光追方式，它主要就是將螢屏所看到的表面幾何資訊當成一個場景，利用螢屏的 depth texture 來做 ray marching：每次 marching 一步后就可以檢測當前點的 z 值與在 depth texture 中對應的 depth 哪個更小，如果 depth 更小則說明 marching 碰到了螢屏中的 pixel，就可以訪問對應的螢屏資訊作為 hit point 的屬性，

而在實踐中，還可以借助 hi-z（depth texture 的 mipmap）來優化 marching 性能，因為 mip 層級高的 depth texture 相當于為更高層級的 bounding volume 表示，這樣就可以實作大步的 marching，

顯而易見的問題是：如果 marching 最終走出了螢屏外，那么 SSRT 將無能為力去處理（因為只記錄了螢屏上的資訊），并且 SSRT 的命中判斷是保守的：即 SSRT 產生 hit 了則 ground truth ray tracing 必定會產生 hit，但 SSRT miss 了但 ground truth ray tracing 不一定會 miss，

以上內容均在我以前的博文（基于螢屏空間的實時全域光照（Real-time Global Illumination Based On Screen Space） - KillerAery - 博客園 (cnblogs.com) ）也有大概介紹，

此外，SSRT 還有一個效果問題：由于相交檢測是簡單的深度比較，這就相當于把攝像機所看到的 depth texture 都當成了完全實心的場景，但是這樣在一些 case 下是不正確的（特別是一個小物體放進攝像機的近處，然后遮擋了大部分場景），

為了改進這一點，在 marching 的時候我們不能簡單地認為 depth texture 的 depth 值小于 z 值就是發生碰撞了，而是同時還要額外檢測 z 和 depth 的相差值 delta，如果大于一定閾值 $\epsilon$（$\epsilon$ 可以與 depth 相關），我們是無法斷定是否發生碰撞的（因為不知道這個 pixel 的 “深度柱” 是實心的還是空心的），應當選擇放棄本次 SSRT（視為 SSRT miss），

Height Field Ray Tracing

HFRT（height field ray tracing） 中的 height field 基本是用來描述大地地形的，而地形往往是表面平滑的且實心的，不會像 screen space depth texture 那樣可能有鏤空問題或者表面突變問題，

與 SSRT 相同的是，HFRT 的命中判斷也是保守的：即 HFRT 產生 hit 了則 ground truth ray tracing 必定會產生 hit，但 HFRT miss 了但 ground truth ray tracing 不一定會 miss，

與 SSRT 不同的是：

HFRT 的 ray tracing 方式類似 relief map（浮雕貼圖），即一般采用 ray marching + 二分找零點，效率往往更高：
1. 先用 marching 走固定的大步長，直到遇到更低的地形，
1. 再用二分法找到交點，一般是小于一定閾值便認為成功命中，結束演算法：

depth texture 無法保證其表示的表面是連續的，從而也不能轉換成找零點問題，

height field 基本只有高度資訊，而不像 SSRT 那樣擁有豐富的幾何、材質和顏色資訊（螢屏上的 G-Buffer 等），因此往往僅用于判斷 ray 是否被命中地形物體以及命中點的位置和法線，

Voxel Tracing

Voxelization

voxelization 涉及的內容太多（投影、孔洞問題等），存盤的結構也由很多種（3d texture clipmap，sparse octree 等），由于本文主要涉及 ray tracing 本身，因此不多展開，

其實是懶得寫了XD，以后再補，

Voxel Ray Marching

最簡單的方法便讓 marching 步長固定為一個 voxel 的邊長，每 marching 一步就采樣當前位置所在的 voxel 并且累加 alpha 值（不透明物體占據 voxel 時alpha 值為 1，半透明物體占據 voxel 時 alpha 值為0到1間的某個值，不存在物體在 voxel 的位置時則 alpha 值為 0），如果累積的 alpha 值仍然小于一定閾值則繼續 marching：

但是由于 voxel 并不像球那樣中心點到表面都一樣的距離，在斜方向的情況下很容易出現 marching 后仍然停留在同一個 voxel 從而產生重復采樣，

當然，可以通過判斷當前 voxel 是否和上一個 voxel 一樣來決定是否放棄本次采樣并繼續 marching；但更好的 marching 方式應當是使用直線繪制演算法中的 DDA (Digital Differential Analyzer) 演算法來決定步長：將 ray 方向分別映射到 x,y,z 三個軸，取最大值的軸作為主步進軸；每次 marching 必須要滿足在這個主步進軸走 1 個單位距離（即 1 個 voxel 邊長），而另外兩個軸對應的步進距離也能通過比例算出：

// 僅偽代碼，不做邊界檢查
vector3 voxelMarchingStep_DDA(vector3 origin, vector3 end)
{
    vector3 offset = end - origin;
    vector3 dir = normalize(offset);
    float maxScalar = max(max(abs(dir.x), abs(dir.y)), abs(dir.z));
    vector3 step = dir / maxScalar * voxelSize;
    return step;
}

如果有層次結構的 voxel（如含 mipmap 的 3d texture），還可以采用 HDDA（Hierarchical Digital Differential Analyzer）演算法：大概思想就是先在高層級的 voxels 上進行 marching 和采樣，如果發現存在非空 voxel，再降級到底層級的 voxel 進行 marching 和采樣，

The ray uses the hierarchical VDB tree to achieve empty-space skipping.

Voxel Cone Tracing

將一堆從相同 origin 點出發的 rays 近似成一個 cone 的形式，

類似 voxel ray tracing，voxel cone tracing 累積的 alpha 值小于一定閾值則繼續 marching；不同的是隨著 marching 越來越遠離 origin 點，cone 的直徑也越來越大，而 voxel cone tracing 聰明地對 voxels 的 3d texture 生成預過濾的 mipmap：在 cone 半徑小的時候在 mipmap level 低的 voxel texture 去采樣，在 cone 半徑大時候在 mipmap level 高的 voxel texture 去采樣，

當然，本身 voxels 便是不準確的場景表達，而預過濾的 texture 更進一步會導致高頻資訊的丟失，尤其是 mipmap level 高時，因此 voxel cone tracing 往往僅適用于搜集不那么準確的光照，

以下是一些 voxel cone tracing 的數學關系，

一次 marching 步長 $step$ 取決于 cone 的直徑 $d$：

\[step = max(d, voxelSize(level)) \]
當前應該去哪個 mipmap level 采樣 voxel 也需要取決于直徑 $d$ ：

\[level = \log_2(\frac{d}{voxelSize(maxLevel)}) \]
而直徑 $d$ 又取決于 marching 總共走過的距離 $t$ 和 cone 的張角 $ψ$：

\[d = 2 * t * tan\frac{ψ}{2} \]

SDF Tracing / Sphere Tracing

所謂的 SDF tracing（或者更正式的叫法為 sphere tracing），其實就是基于 SDF 的 ray marching，其基本原理非常簡潔，也非常聰明：從點 $x_{0}$ 開始投射一條 ray，然后進行若干次 marching，每次 marching 的起點為上一次 marching 的終點，而 marching 的步長取為起點 $x_{n}$ 的 SDF 值 $f(x_n)$ ，

SDF 代表著離該點最近的幾何表面有多遠，也就是說在 SDF 值范圍內，這個 ray 絕對不會與任何幾何表面相交，

當然 $f(x_n)$ 在有限步數下無法收斂到剛好為 0，實作中往往用一個小的閾值 $\epsilon $ 來做命中判斷，

在實踐中，最常用 3D texture 來存盤 SDF，也就是說 SDF 是以均勻網格的形式存盤的，每個 cell 存盤一個 SDF 值，容易想到，對整個場景構建高精度的 SDF 將會耗費巨量帶寬和存盤空間，并且在實時渲染領域往往是不可以承擔的，

Global SDF + Mesh SDF

UE5 Lumen 為了解決場景的 SDF 表示問題，為每個 mesh 單獨預生成了一個高精度的 sdf（稱之為 mesh sdf），然后將場景中每個 mesh sdf 實時合成一個低精度的場景 sdf（稱之為 global sdf），

這樣就可以先在 global sdf 進行低精度的 sdf tracing，當 marching 到存在 mesh sdf 的區域時，就可以訪問對應的 mesh sdf 進行高精度的 sdf tracing，

global sdf 可視化：

mesh sdf 可視化：

AABB Tree + Local Distance Field

源于 AMD 的方案（Real-time Sparse Distance Fields for Games | GDC2023），由于篇幅有限，這里只講個大概，實際上還有更多細節和優化策略，感興趣的建議看參考的原文，

為每個 mesh 預生成 mesh sdf 會限制 mesh 的動態性（不允許動態拉伸或者頂點偏移等），而 AMD 給出的方案則是實時根據區域區域的 triangles 去生成 local DF，并將這些 local DF 以 3-level AABB Tree 的形式組織起來（一個 local DF 就是一個葉結點），

其具體流程如下：

對場景中各種 mesh 進行體素化（voxelization），并將 triangle ID 添加到對應 voxel 的 triangle list，

對每個非空的 voxel 創建一個對應的 brick，一個 brick 就是一個所謂的 local DF，包含 8x8 個 brixels（brixel 存盤了 DF 值），

對每個 brick，遍歷對應 voxel 的 triangle list：
- 計算出 brick 內的 AABB box（紅線框），
- 先對與 triangles 有相交的 brixels 填充 DF 值（其實就是離最近三角形的距離），
- 而沒有相交的 brixels 在隨后使用 Eikonal / Jump flooding 演算法來填充 DF 值，
- 對于邊界的 brixels，則參與所有鄰接 bricks 的計算，
對計算出來的 AABB boxes 構建出一棵 3-level AABB tree，以供后續 sdf tracing 查詢使用，

Enhanced Sphere Tracing

傳統 sphere tracing 演算法中，在點 $x_n$ 的 ray marching 步長應取為 SDF 值 $f(x_{n})$，而這種 marching 其實是保守的，

實際上我們可以采用更激進的步長倍數 $\alpha$ ，只要 $x_n$ 的SDF 值加激進 marching 后到達 $x_{n+1}$ 后的 SDF 值 $f(x_{n+1})$ 大于本次激進 marching 的步長 $\alpha f(x_n)$（即 $f(x_n) + f(x_{n+1}) > \alpha f(x_{n})$，在幾何上實際就是表現為兩個 sphere 相交），那么就說明 ray 可以安全通過本次激進 marching，否則應當退回到點 $x_n$ 的位置重新進行保守的 marching，

當然，過于激進的步長倍數會導致過多的回退，而過保守的步長倍數則不會帶來效率的提升，因此應該針對自己的場景調整 $\alpha$ 引數（引入一些動態調整 $\alpha$ 的方法，如下面的 accelerating sphere tracing），而原 paper 的作者推薦大約 $\alpha = 1.2$ 倍步長為性能最佳，

Accelerating Sphere Tracing

更進一步的激進策略是：永遠假設前兩次 marching 所形成的 sphere 都相切于同一平面，那么下一次可以嘗試 marching 這樣一個 sphere：與該平面相切，也剛好與上一次的 marching sphere 相切；如果嘗試失敗則回退至保守 marching，

那這個嘗試 marching 的具體步長應該是多少呢？

由相似三角形易得 $\frac{d_i}{r_i+r_{i+1}}=\frac{r_{i-1}-r_i}{r_i-r_{i+1}}$

那么嘗試的步長應為：

\[d_{i+1}=r_{i+1}+r_i=r_i \cdot \frac{2 d_i}{d_i+r_{i-1}-r_i} \]

這種策略比 enhanced sphere tracing 回退次數減少了許多，有更好的加速效果，

Segment Tracing

一堆數學定義（如 Lipschitz），還要假設場景是 $C^2$ 連續（如果有棱角基本就容易出問題），并且不一定有優化（甚至可能是負優化，因為需額外多次采樣 SDF 來求導），不推薦用，

實在好奇，也可以這樣感性地理解：segment tracing 實際上就是在 ray 的方向分成一段段線段（segment），然后算 segment 的頂點和末尾點的 SDF 一階導，并由此推算出這段 segment 附近的大概安全區域（SDF 一階導相當于往最近表面的反方向，由兩個導數資訊就可以推算出大概的表面資訊），并算出 ray 如果要經過這塊區域，其最遠的安全步長是多少，

SDF Cone Tracing

如果有多條從相同起點出發且出射方向相近的 rays，可以將它們合并成一個 cone，先進行 SDF cone tracing，hit 到物體時再分裂成原始的多條 rays 并分別進行 SDF ray tracing，

SDF cone tracing 的程序基本和 sphere tracing 差不多，只是步長不一樣：第 n 次 marching 不是走到 $x_{n} + f(x_{n})$ 的位置（對應下圖 $P'$ 的位置），而是走到 $(x_n+f(x_n))* A$ 的位置（對應下圖 $P''$ 的位置），

這是因為 ray tracing 本質上是一個點在 marching 而 cone tracing 是一個半徑逐漸變大的球在 marching，$P''$ 是能保證這個球絕對安全的最遠位置，

可以看到 SDF cone tracing 的 marching 往往是比 SDF ray tracing（sphere tracing）要短的，會導致更多步長，但如果 rays 共享 cone tracing 從而減少的總步長次數大于 cone tracing 帶來的額外步長次數，那么這個策略便能有很大用處（尤其對于一堆集中方向的 glossy/specular rays），

一些實踐

ray tracing pipeline 算是最理想的 ray casting 方法，它能獲得 hit point 的材質，并且得益于硬體加速，其性能也并不亞于軟體光追，因此基于 ray tracing pipeline 往往就可以設計出一套相當理想的實時光追演算法，然而在硬體不支持或部分支持（僅支持 ray query）的大部分平臺，如移動端，nintendo switch等，無論是 ray query 還是軟體光追都不能直接獲得 hit point 材質，因此往往還需要設計一套低精度的 material cache，

下面的實踐主要是圍繞 ray query 和軟體光追來介紹，基本不介紹 ray tracing pipeline（因為它可以直接簡單粗暴的做好），

Primary Ray

可以通過傳統的光柵化流程去做，而不是真的往螢屏投射 primary ray，

Shadow Ray & Visibility Ray

我們在常常需要計算某些著色點受到的直接光照，就往往需要從該點往光源投射 shadow ray 來檢測是否被遮擋，我們可以通過一套類似流水線的流程去處理 shadow ray：

若光源自帶 shadow map 且著色點在 shadow map 范圍內的，可以優先使用 shadow map 來進行遮擋測驗，而非投射一條 shadow ray，
若光源沒有 shadow map，亦或者著色點不在 shadow map 的范圍內，則可以使用性能開銷低的軟體光追方案：
- 針對螢屏范圍內的著色點，可以嘗試進行 screen space ray tracing，若命中則視為被遮擋，
- 如果場景含有 height field，可以嘗試進行 height field ray tracing，若命中則視為被遮擋，
若以上流程均未命中，則使用離屏的光追方案來做最后的遮擋測驗（命中為被遮擋，不命中為不被遮擋）：
- 其它軟體光追，
- 硬體光追：ray query，

半透明陰影 - ray query

當陰影需要考慮半透明物體（例如樹葉）時，意味著我們的 shadow ray tracing 不能只考慮是否被遮擋，還得考慮遮擋物體的 opacity，并且這一次 ray tracing 還可能將發生多次 intersection，

當我們通過 ray query 去做半透明陰影時（需要設定 RayFlags 為 NoOpaque），每當產生 intersection 時，需要中斷回傳到我們自定義的程式，該程式需要計算出交點 uv 坐標采樣 alpha mask texture，并累積 alpha 值，若低于 opacity 閾值就繼續進行 ray tracing，

一個優化方式是：我們可以進行多次非透明的 ray query（需要設定 RayFlags 為 Opaque）：每次 ray query 產生 intersection 就 commit，然后做 alpha 相關測驗（和上面一樣），如果還需要繼續 ray tracing，那就更新發射點位置為 intersection 的位置并進行新一次的 ray query，

這個優化方式的性能往往能提升2倍甚至更多的性能，一方面是 RayFlags 設定成 Opaque 后 ray query 的流程會簡化很多，另一方面是因為 ray query 是特定的硬體流程，中斷回傳會導致額外的 latency，因此盡量讓 ray query always commit，

Material Ray

而除了計算直接光照以外，我們還往往需要計算著色點受到的間接光照，這時候往往需要投射 material ray，獲取 hit point 的材質資訊以計算 radiance：

對于硬體光追 ray tracing pipeline 來說，material ray 是容易實作的：直接通過 closest hit shader 來計算出 hit point 的材質資訊，并之后通過 payload 來獲取材質資訊即可，

若著色點位于螢屏范圍內，可以優先嘗試 screen space ray tracing，若命中則可以獲取螢屏上的 normal, albedo, color 等材質資訊，
若著色點不在螢屏范圍內亦或者 SSRT 沒命中，則可以使用 visibility ray + material cache：由于缺少 closest hit shader，我們只能通過投射 visibility ray 得到一個 hit point 的 position，而得不到幾何資訊或者材質資訊，但是我們可以借助 material cache（例如：lumen 里的 mesh card；voxels 等）來獲取 hit point 的材質資訊，

注：幾何資訊有部分還是可以強行獲得的，如通過 SDF 梯度算 normal ，或者 triangle id 獲取 3 個 vertex 從而算出 face normal 等，

Low-Accuracy Ray + Short Ray

參考

DirectX Raytracing (DXR) Functional Spec | DirectX-Specs (microsoft.github.io)
Vulkan ray tracing 與 rasterization 管線對比 - 知乎 (zhihu.com)
[Lumen Siggraph 2022 realtimerendering.com](https://advances.realtimerendering.com/s2022/SIGGRAPH2022-Advances-Lumen-Wright et al.pdf)
Relief texture mapping | 2000
Interactive indirect illumination using voxel cone tracing | Symposium on Interactive 3D Graphics and Games 2011
Hierarchical Digital Differential Analyzer for Efficient Ray-Marching in OpenVDB | SIGGRAPH 2014
Real-time Sparse Distance Fields for Games | GDC-2023
Enhanced Sphere Tracing | STAG 2014
Accelerating Sphere Tracing | EUROGRAPHICS 2018
Segment Tracing Using Local Lipschitz Bounds | 2020
Rendering (Signed) Distance Function - 知乎 (zhihu.com)
GPU-based clay simulation and ray-tracing tech in Claybook Sebastian Aaltonen Co-founder of Second Order | GDC2018

作者：KillerAery 出處：http://www.cnblogs.com/KillerAery/

本文著作權歸作者和博客園共有，未經作者同意不可擅自轉載，否則保留追究法律責任的權利，

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/555569.html

標籤：其他

上一篇：To ChatGPT：讓你更加隨意地使用所有ChatGPT應用

下一篇：返回列表

實時光線追蹤（3）Ray Casting