Hachisukahttp://www.ci.i.u-tokyo.ac.jp/~hachisuka17年前から、CGを勉強していますが、デモシーンに出会ったのがきっかけです。ソフトウェアラスタライザを書いていました。この場で発表するのはとても光栄です。あたりまえになりました。映画のレンダリングにも使われて初めています。デモの簡単なレイトレーシングはものは沢山のサンプルがあります。映画のような物理的に正しいレンダリングをする知識はあまり共有されていない。レンダリングの複雑性があがるにつれて、共有される知識が少ない。この領域を考えると、実用的なレンダリングシステムを書くには重要な事柄が共有されていない。古いものなので、ドライバが良く成熟している。簡単にシェーダーが書ける。使うおうとすると、結構面倒。複数のGPUでも高速化される。重要なのは「楽しい」から。(BVH)CPUを使ったレンダリングシステムで使われているもの。物理的に正しい計算をするために、光の計算をする必要がある。あるので、ひとつ一つやっていると、実質レンダリング終わらない。アイデアとしては、4つ三角形があったとすると、2つのペアに対してバウンディングボックスを用意して、その二つを囲むようなバウンディングボックスを作る。すると階層構造ができる。簡単にできるようになる。PPM蜂須賀手法;3つの方法で光のシミュレーションをします。フォトントレーシングという、光源から乱数を使ってレイトレーシングします。フォトンという点群のが使いとして、格納します。交差した点で、密度推定します。3つのステップで計算します。使って、それを使って高速なレイトレーシングを行います。estimationフォトンを累積して累積して計算します。Principles並列な処理ができるような処理にすることひとつひとつの並列な処理を均質な処理になるようにすること。タスクごとに使われるメモリをなるべく使わない。実際の映画の製作に使うには無理があるかもしれません。いう風に作っていけばプロダクションレベルのレンダラーが作れるのではないか。使ったレイトレーシングは、再帰を使う、スタックを使う、メモリが消費される。スタックを使わない構造。スタックが使えるし速い場合もある。スタックのサイズで、どれくらい並列化されるか決まってしまう。64個のレイしか計算できない。今後並列度があがっていった時に足りなくなるかもしれない。スタックを使わない方が未来があると考える。BVHあらかじめ計算しておいてそれを利用する。ヒットリンクは、トラバーサルする時にヒットすると、たどるリンク。ミスリンクは、ヒットしなかったら辿るリンク。最終的に、ターミナルに行き着いたら探索を終了。ヒットリンクの場合は、隣りにいき、ミスリンクの場合も3つのルールにしたがって、自動的に計算できる。変換するのは比較的簡単。探索が非常に簡単になる。バウンディングボックスに当たっているのか、当たっていないのかだけを判断するもの。すごい簡単なループで探索計算ができます。ヒットリンクとミスリンクは、トラバーサルの順番が固定になっています。最初のトライアングルにヒットすると、後ろにあるトライアングルは計算しない。近いバウンディングボックスからトラバーサルしたいという基本。6つの方向に対して、ヒットリンクとミスリンクを作る。順序を交換してあげて、ヒットリンクとミスリンクを作る。最終的にはデータは、バウンディングボックスのデータと、6つのヒットリンク、ミスリンクの構造になります。小さくコンパクトにまとめられます。トラバース自体のコードはほとんど変わらない。レイの方向によって、どこからスタートするかを決める。スタックは使わないし、まったく同じように動く。レイトレをする時は、レイと三角形との交差判定を行います。CPU上で速い方法をやると、逆に遅くなったりします。最終的に、おちついたのは、このコードです。分岐を最後にまとめて、一回だけやると早くなります。CPUだと分岐を早めにやるのが良い。GPUだと実際はスキップされないので最後にやるのがいい。場合は、前計算しない方がいい。位置を3つストアして、法線ベクトルが正規化されている前提でZは+-だけ。人がチューニングした方法とくらべて半分以上の値が出ている。1.5倍程度しか増えない。そんなに悪くないんじゃないか。この方法が唯一の方法ではなく、研究ではいろいろな方法があるのですが、ほぼ全て実装して比較したところ、今回の方法が速いことがわかった。ビット操作でトラバーサルする方法や結構遅い。レイトレを高速化できたら、フォトントレーシングをどうするか?それぞれのピクセルについて、光源からランダムにレイトレーシングしながら進める。計算負荷が一様でない。乱数を使って計算するのですが、デモとかで使っている乱数を使うと酷いことになる。統計的にいい乱数をつかわないといけない。他のピクセルの計算が終わるのを待たなければいけないので、計算効率が落ちる。リストを作らなければならず、面倒なことになる。最初の問題については、非同期にフォトンの計算をすることによって効率を上げることができる。反射回数をピクセルで持って、0回反射している場合は、新しく光源から。0の数を数えると新しくフォトンが発生したものがわかる。計算が終わったピクセルは、他のピクセルを待たないで、新しい計算ができるように。比較すると、反射回数を非同期にすると、反射回数をあげてもパフォーマンスが落ちない。高速だが、乱数としての性質はあまり良くない。本当にランダムな結果が欲しい。難しい話しで、二つ問題があって、ひとつは乱数の性質がいいものをつくらないといけない。整数演算をサポートしていない環境でできないといけない。乱数発生アルゴリズムは整数前提。これがうまくいくのか全く解っていない。なんで動いているのかわからないので、気持ち悪い気もする。実はあまりうまくいかないので、おすすめしない。暗号化ハッシュを使う方法があって、それは結構うまくいく。高品質なのですが、かなり遅い。tracingフォトントレーシングを同じ、最後にヒットしたら、そこで計算がストップするので、そこで計算をストップできる。どこに交点があるのかを見つけるだけ。実際交点が見つかったあとは、密度推定を行う必要がある。上でやると、問題がある。フォトンはランダムに生成されるので、CPU上で作ってやればいいのか?毎回転送すると、遅すぎて使えない。GPU上でデータ構造を作りたい。フォトンが大量に合った場合、計算がヘビーになる。空間ハッシュを使うという方法。フォトンが沢山あった場合、グリッドに切って、グリッドの点に対して、それよりも少ないハッシュテーブルを作り、それを使う。ごとにテクスチャなどに格納する。球の中にフォトンがあるかどうか計算してみつける。これはすごく高速に動作します。二つ問題があって、ハッシュを作った時にリストを作らなければいけない。長い場合に計算時間が長くなってしまう。hashing蜂須賀手法。ランダムに一個のフォトンをキープする。統計的に正しい結果が得られる。最後に書き込まれたものをキープしている。一応何個書き込まれたかというカウンターはあるが、その分だけフォトンの明るさをスケールする。これをやると実際のフォトンを探すのではなく、ハッシュテーブルに対して、一回だけ読み込めば良くなる。実装が簡単で、ハッシュを計算して、書き込んで、カウンターで数えるだけ。読む時間はほぼ同じか、若干速いくらい。つの問題を完璧に解決できる。パーティクルの密度を計算する時などに使える。テクスチャを持つ時に、なんとなく1つのテクスチャとして作りたくなりますが、テクスチャの数が限られている。違うテクスチャにアクセスすると条件分岐しなければならなくなる。ボリュームテクスチャに全部突っ込んでおく。アホな方法に見えますが、非常に速く動きます。100%になってしまう。浮動小数点で計算する。持っていれば、結構なシーンが格納できて、速い。AMDどれでもちゃんと動く。ドライバでは変に動く場合がある。ドライバーの方がいい場合がある。NVIDIAのドライバでは動かない場合がある。使うと動くようになる。