7

カメラの動きに基づいてぼかす方法については、GPU Gems 3 チュートリアルに従っています。ただし、オブジェクトの動きに基づいてぼかしも実装したいと考えています。解決策は記事に示されています (以下の引用を参照)。

現時点では、オブジェクトのマトリックスにビュー プロジェクションを乗算してから、以前のビュー プロジェクションに対して個別に乗算し、それらをピクセル シェーダーに渡して、ビュー プロジェクションだけでなく速度を計算しています。

それが実際に正しい方法である場合、モデル ビュー プロジェクションを単純に渡すことができないのはなぜですか? 私はそれらが同じ値になると思いましたか?

GPU Gems 3 モーション ブラー

リジッド ダイナミック オブジェクトの速度テクスチャを生成するには、現在のフレームのビュー プロジェクション マトリックスと最後のフレームのビュー プロジェクション マトリックスを使用してオブジェクトを変換し、後処理パスと同じ方法でビューポート位置の差を計算します。この速度は、変換された両方の位置をピクセル シェーダーに渡し、そこで速度を計算することによって、ピクセルごとに計算する必要があります。

4

1 に答える 1

10

このトピックについて数か月前に行った調査をご覧ください: http://www.stevenlu.net/files/motion_blur_2d/Fragment_shader_dynamic_blur.pdf

タワースマッシュの標準レンダリング
(出典: stevenlu.net )

タワースマッシュのぼかしレンダリング
(出典: stevenlu.net )

残念ながら、このマテリアルを作成するときにテクスチャ オブジェクトを実装しませんでしたが、想像力を働かせてください。私はゲームエンジンに取り組んでいるので、最終的にそれがゲームの形で日の目を見るとき、私はここに来てパンくずリストを投稿することを確信できます. 主に、この効果を 2D で実装する方法と、オブジェクトがオーバーラップしない場合について説明します。「正確な」ぼかしを生成するために、フラグメント シェーダを使用してサンプルを「スイープ」するのは、実際には適切な方法ではありません。サンプル数が増えるにつれて、効果はピクセル単位の完成度に近づきますが、スイープ エリアをカバーするために生成する必要があるジオメトリは、いくつかの「醜い」技術を使用して手動で組み立てる必要があります。

フル 3D では、動的オブジェクトがフレームの進行中にどのピクセルをスイープするかを知るのはかなり難しい問題です。静的なジオメトリと移動するカメラの場合でも、GPU Gems の記事で提案されているソリューションは、過去のものをすばやく移動する場合は正しくありません。これは、移動するものによって一掃された領域のブレンドが必要になるという問題に対処できないためです...

そうは言っても、スイープを無視するこの近似が十分である場合 (そしてそうである可能性があります)、動的オブジェクトに拡張するためにできることは、それらの動きを考慮に入れることです。もちろん、詳細を理解する必要がありますが、リンクした記事の 2 番目のコード ブロックの 2 行目と 5 行目を見てください。これらは、ピクセルの現在および以前の画面空間の「位置」です。オブジェクトの動的な動きを考慮して、各ピクセルの以前の位置を計算できるようにする行列を何らかの方法で渡す必要があります。

悪くないはずです。動的オブジェクトをレンダリングするパスでは、最後のフレームでのモーションを表す追加のマトリックスを送信します。

更新:この論文では、3D パイプラインに物理的に正確なブラーリングを提供する、洗練されたパフォーマンスの高いアプローチについて説明し ていることがわかりました。パフォーマンス上の理由から、シーン全体を 1 回しかレンダリングしないという制約内で、これよりもはるかに優れた処理を行うことは困難です。

いくつかの例で、速度バッファーの品質が向上する可能性があることに気付きました。たとえば、回転するホイールには、速度空間にいくつかの曲線が必要です。それらが適切に設定できれば (速度をレンダリングするためにカスタム フラグメント シェーダーが必要になる場合があります...)、2D 探索からダイナミック モーション ブラーへの上記の回転キューブのように直感的に正しく見えると思います。

于 2012-08-17T21:56:13.170 に答える