redflash [portal] renderer / Raytracing Camp 10

レイトレ合宿10でOptiXを用いて開発した自作レンダラーのプレゼンスライドです。
ポータル用のBSDFを実装し、レンダラー本体のポータル専用処理を最小限に抑えました。
https://gam0022.net/blog/2024/10/23/rtcamp10/

Google Slides版
https://docs.google.com/presentation/d/1IRcyHyze1QlRMq5KFJQLhltmN2310svw-IMybdgobKY/edit#slide=id.gbd0ef54b81_0_79

Transcript

1. redflash [portal] 2024-10-12 レイトレ合宿10本戦 @gam0022 / Sho HOSODA
3. 使用ライブラリ 
 • NVIDIA OptiX 6.5
 • stb_image
 • TinyObjLoader
 3
4. 基本機能
 • Unidirectional Path Tracing
 ‣ implemented in NVIDIA® OptiX 6.5
 • Materials（BSDFs）
 ‣ Disney BRDF, Lambert Diffuse, Glass, Poral（後述） 
 • Primitives
 ‣ Sphere, Mesh, Distance Function (Raymarching )
 • NEE（Next Event Estimation) + MIS（Multiple Importance Sampling）
 • ACES Filmic Tone Mapping
 • Deep Learning Denoising
 4
5. レンダラーの出力設定 
 • 解像度
 ‣ 1920x1080
 
 • 300フレーム 💪
 ‣ 30FPS × 10秒（上限）
 ‣ 1フレームあたり0.85秒 くらい
 5
6. 目指したもの 💪
 ポータル（どこでもドア）表現、非現実で面白そう！💡
 6
7. ポータルの実装の流れ 
 1. シーンを2つ用意 
 a. OptiXのSceneGraphを2つ用意
 b. scene0（前半の屋内）とscene1（後半の屋外）
 
 2. rtPayload構造体にscene_idを定義 
 a. scene_idでトレースするシーンを切り替え
 
 3. ポータル用の特殊なBSDFを用意 
 a. レイは直進させる
 b. scene_idを0と1で反転させる
 c. BSDF実装の補足
 i. closest_hit 関数の定義は共通
 ii. BSDFのサンプル方向・pdf計算をCallableProgramで切り替えできる設計
 7
8. ポータル間のGI 
 • 2つのシーン間でレイが接続されている
 • 外の景色が床のエリアライトとして反映できる
 8
9. 前半の屋内シーン 
 1. 屋内シーンはポリゴンでシーン構成 
 a. エリアライトの反射を綺麗に描画するために、サンプリング数を増やしたい 
 2. 水銀のBall（自機）のみレイマーチング 
 a. メタボールの実装は距離関数の方が簡単 
 9
10. 前半の屋内シーン 
 • エリアライトの発光のアニメーション 
 ‣ マテリアルのパラメーターのアニメーションをCallableProgram化 
 • フラグメントシェーダーっぽい機能を実現 
 ‣ 40個のエリアライトの発光色を細かく制御可能になった 
 10
11. Blender Geometry Nodes 
 部屋のMeshはBlender Geometry Nodes で作成（Planeを押し出し）
 11
12. 使用アセットの出典 
 • 3Dアセット 
 ‣ ドア
 • https://www.thebasemesh.com/asset/classroom-door
 ‣ Suzanne
 • BlenderからAdd
 
 • テクスチャ（天球のHDRI画像） 
 ‣ https://polyhaven.com/a/kloppenheim_06_puresky
 ‣ https://polyhaven.com/a/fireplace
 12
13. 後半の屋外シーン 
 • ほぼ全部レイマーチングでシーン構築
 • 屋外シーンならサンプリング数が少なくても絵が綺麗に出る
 13
14. 後半の屋外シーン 
 • 距離関数をCallableProgram化 
 ‣ 色々な種類のジオメトリーを同じintersect関数で扱えるようになった
 • タワー、MandelBox、水銀のBall、海
 14
15. 後半の屋外シーン 
 • レイマーチングの衝突判定の条件を形状ごとに変えた 
 15 d < epsで判定 
 レイマーチングのイテレーション回数が足りずに途中で探索が打ち切ら れてしまい、衝突するはずべき箇所が衝突していないと判定 
 シルエットが削れて本来よりもスカスカした印象に 
 最終的にレイの先端がバウンディングボックスの内部に留まっていた ら衝突したとみなす ように修正
 レイマーチングのイテレーション回数が足りないことによる判定エラーを 軽減できた
 ※バウンディングボックスと形状が近い場合に有効 

16. 補足
 レイマーチングはレイが浅い角度で入射すると
 イテレーション回数が増えてしまう
 
 →本当は衝突しているのに、
 　イテレーション回数不足で衝突なしの誤判定が起きる😢
 16 画像出典:　[Keinert et al. 14]
17. 後半の屋外シーン 
 • タワーの無限配置 
 ‣ mod repetitionのテクニックでXZ平面に無限に繰り返し
 ‣ p = mod(p, a) - 0.5 * a; 17
18. modによる繰り返し 
 • pにmodを適用すると無限に繰り返しができる 
 ‣ p = mod(p, 1.0) - 0.5; 
 
 • なぜ
 ‣ テクスチャのWrapモードのRepeatのような感じ 
 ‣ 上の例
 • -0.5〜0.5 の範囲の座標が永遠に繰り返される 
 18
19. 初島の海
 🌊
 19
20. 最後のカット 
 スザンヌがこちらを見つめている
 20
21. レイマーチング（Sphere Tracing）の高速化の研究 
 以下の手法を去年に実装したが、今年のシーンでは相性が悪かったので無効化😭
 同じ著者の新作のSphere Tracing高速化の手法は無かった😭
 
 • [Keinert et al. 14] Enhanced Sphere Tracing
 • [Bán&Valasek 18] Accelerating Sphere Tracing
 • [Bán&Valasek 23] Automatic Step Size Relaxation in Sphere Tracing
 21 [Bán&Valasek 18] シーンを平面と仮定 Sphereが重ならないように次のステップを求める 普通のSphereTracing [Bán&Valasek 23]は [Bán&Valasek 18]の パラメーターを自動調整
22. 役立った機能 
 • 制限時間を守る工夫 
 ‣ 各フレームの最初の2サンプリングの時間から
 制限時間にギリギリ間に合うサンプリング数を推定
 ‣ シーンの重さに応じた計算リソースの配分も実現
 • 前半と後半でシーンの重さが20倍くらい違う
 
 • 軽量版のレンダラー 
 ‣ アニメーションの確認用
 ‣ アニメーションは全部ハードコーディング💪
 
 • PNGの保存の並列化 
 ‣ サブスレッドで動作
 ‣ メインスレッドのレンダリングをブロックしない
 22
23. まとめ
 • ポータルをシンプルに実装できた 
 ‣ ポータル用のBSDFを実装
 ‣ レンダラー本体のポータル専用処理を最小限にできた
 
 • ノイズを抑えられた 
 ‣ 300フレーム、1920x1080
 23
24. END. 24