1

学習目的で、レイトレーシングのテクニックを調べていました。私は最近、グローバル イルミネーションとその変種を発見し、ケビン ビーソンによるこの素晴らしい作品を読みました。smallpt を別の言語 (Lua) に移植しようとしました。

これまでのところ、問題なく動作していますが、私の意見では、シーンのレンダリングが遅すぎます。これまでのところ、私はインターネットを掘り下げました。これがグローバル イルミネーション技術、特にパス トレーシングの主な問題であるという主題をカバーする多くの技術論文を見てきました。

充填曲線の間隔 (たとえば、ヒルベルト曲線) など、プロセスを高速化する方法があるように思えます。基本的に、それらはすべてビューポートをバケット (またはタイル) に分割し、レンダリングに命令して、特定の順序で各バケットのパス トレーシングを処理します。技術的には、ヒルベルト曲線を実装する方法を見ていませんでしたが、実際には、これによりプロセス全体がどのように高速化されるかを理解したいですか?

私の最初の仮定は、各バケット appart を考慮すると、レンダラーは特定のピクセルで呼び出され、その他は補間トリックを使用したサンプルでしたが、実際には、レンダラーはバケットの各ピクセルで呼び出されるようです。

したがって、結果として、レンダラーはマップのすべてのピクセルを処理します。私の控えめな意見では、ネストされた 2 つの for ループ (行ごと、列ごと) と同じ量の作業になります。だから私は明らかに何かが欠けていることを知っているので、いくつかの明確な説明を楽しみにしています.

前もって感謝します。

4

2 に答える 2

1

Smallpt は、可能な限り少ないコード行でパス トレーシングを使用してグローバル イルミネーションを示すように設計されています。そのため、パフォーマンスの最適化は行われません。

単純なシーンよりも複雑なシーンの場合、レンダリング時間のほとんどは、レイがパスに沿って次にヒットするオブジェクトの計算に費やされます。これは、レイごとに何度も実行する必要があるためです。

単純な実装では、次にヒットするオブジェクトを決定するために、レイがバウンスするたびに、シーンを構成するすべてのオブジェクトとレイの交差を計算する必要があります。

これを改善するために、加速構造を使用して、計算する必要があるレイ/オブジェクトの交差の数を減らします。通常は、シーンを囲むボリュームを分割して不要な交差テストを回避します。

主なアプローチは 2 つあります。

パフォーマンスに関してはどちらも同じように機能しますが、BVH の方が実装が簡単だと思います。

于 2013-01-04T19:37:17.450 に答える
0

そのような方法はわかりませんが、複雑なシーンのキャッシュ使用を改善できるため、タイリングだけでもパフォーマンスが向上します。左から右にスキャンする代わりに、シーンをさまよってすべてをキャッシュに取り込みます。一度にタイルを作成することで、たとえば、数百本の光線がすべてシーンのほぼ同じ領域に落ち、楽しそうに移動するのではなく、つまり、その領域のデータのみをキャッシュに入れる必要があります。もちろん、二次光線は基本的にランダムなので、パス トレーシングを使用している場合、最初の光線はおそらくそれほど重要ではありません。ただし、フォトン マッピングの方が役立つ場合があります。

とにかく、空間充填曲線がそこで似たようなことをしているのかもしれません。それを除けば、私はそれらが何のためにあるのか分かりません。

[編集] それらを取り出してみて、パフォーマンスが変化するかどうかを確認してください。

于 2012-12-20T17:48:23.787 に答える