問題タブ [msaa]

いくつかのバリエーションで MSAA のサポートを実装しました。

コンテキスト ベース (コンテキストを設定し、それに応じたパラメーター リストを渡すときに wglChoosePixelFormatARB を呼び出す) または FBO への MSAA レンダリングを有効にする (色と深度のレンダーバッファー アタッチメントを持つマルチサンプリング FBO と、カラー アタッチメントを持つ別の FBO を作成する) のいずれかを使用できます。解決のため）、アンチエイリアスは全体的に機能しているようです。

ただし、アンチエイリアシングを有効にすると、スペキュラー ライティングに関連すると思われるアーティファクトがいくつか見つかりました。コンテキストベースの CSAA では最悪であり、コンテキストベースの MSAA ではかなり悪いですが、FBO にレンダリングするときに MSAA を使用すると、はるかに改善されます。

私がテストに使用した航空機モデルの 1 つで、特にエンジン シリンダーといくつかの「ワイヤー」の周りで非常に目立ちます (実際には線ではなく、細いシリンダーです)。

画像でわかるように、スペキュラ ライトをオフにすると、問題はほとんどなくなりましたが、何が原因なのかはよくわかりません。

上の画像では、次のシェーダー コードを使用して鏡面反射を計算しています (すべてのライトのループ内)。

また、異なる照明モデルの間にはかなりの違いがあるようです:

左側はスペキュラ ハイライト用に上記のコードを使用していますが、右側はこれを使用しています (すべてのライトを反復処理するメイン ライト ループ内)。

では、FBO ベースの MSAA とコンテキスト ベースの MSAA を使用する場合に、なぜそれほど大きな違いがあるのか​​ 疑問に思っています。また、そもそも問題を引き起こすために、スペキュラー ハイライトで何が間違っていたのでしょうか?

編集:以下の投稿で要求されたように、コンテキストと FBO を介して 16xQ CSAA の結果を比較するためのテストも追加しました (FBO の場合、glRenderbufferStorageMultisample の代わりに RenderbufferStorageMultisampleCoverageNV を使用しています)。ここでも、FBO の結果の方が優れているように見えます (ただし、まだ説得力はありません)。

スムーズな AA テキストをレンダリングしようとしています。

テッセレータを使用してポリゴン メッシュを作成し、MSAA パスを使用してエッジを滑らかにしました。

*奇妙なことに、MSAA パスはエッジの周りに黒いジャギーをもたらします (事前に乗算されたテクスチャに似ています) http://i.imgur.com/cywPSoE.png

奇妙なことに、前置乗算を行うと、結果は問題ありません! 、2 番目の添付ファイルを参照してください: http://i.imgur.com/W06Id18.jpg

MSAA をオフにすると、通常の白いジャギー (ステップ) が発生するため、この問題の原因は MSAA であるとほぼ 100% 確信しています。

私は Android アプリ開発/LibGDX は初めてですが、Java には精通しています。LibGDXで、画像に示されているようなグラデーションの線を作成するのに苦労しています。

(本当に素晴らしいと思います oO)
注: この画像は、移植しようとしている Java アプレットのスクリーンショットです。

これまでのところ、グラデーションを使用して描画する方法に関する情報はほとんどまたはまったく見つかりませんでした。

描画できない場合は、たとえば、Photoshop でグラデーションを作成し、それを覆う黒いレイヤーの後ろのレイヤーに配置してから、線の座標の黒いレイヤーを「削除」する機会はありますか?

グラデーションが表示されない

.........Gradient
---------Black
^^ Line で Black を削除

結果は ->

.........グラデーション
--- ----黒

線の座標にグラデーションが見える（？）

編集:行もアンチエイリアス処理したい。それに関するアイデアはありますか？

JOGL を介して OpenGL 3 を使用する Java アプリケーションがあり、マルチサンプリングを実装しようとしています。私はこのチュートリアルに従っていますが、これまでのところ、1 行を除いて機能しているようです。を呼び出すとgl.glBackBuffer(GL3.GL_BACK)、GL_INVALID_OPERATIONエラーが発生します。プログラムが続行すると、現在フロント バッファーであるかバック バッファーであるかに関係なく、1 つのバッファーのみに描画するように見え、再描画されるたびに目的の出力とガベージ データを切り替えます。

ドキュメントによると：

GL_INVALID_OPERATION は、デフォルトのフレームバッファが影響を受け、buf で示されるバッファが存在しない場合に生成されます。

GL_INVALID_OPERATION は、フレームバッファ オブジェクトが影響を受け、buf が GL_NONE または GL_COLOR_ATTACHMENT$m$ と等しくない場合に生成されます。ここで、$m$ は 0 から GL_MAX_COLOR_ATTACHMENTS までの値です。

これらのどちらも私の問題ではないと思いますが、そのエラーが生成される唯一のシナリオであるため、いずれかが問題になるはずです。

関連するコードは次のとおりです。

また、クリーンアップをあまり行っていないことはわかっていますが、それがこの問題に影響を与えることはありません。

編集: 要求に応じて、GLCanvas が作成されるコードは次のとおりです。

OpenGL で複数のレンダリング ターゲットを使用する場合、明示的なマルチサンプリングを使用すると問題が発生します。

最初のジオメトリ パス中にレンダリングされる 4 つのレンダー ターゲット (位置、拡散 + 不透明度、法線、鏡面反射 + 指数) があります。

これらはすべて、フレームバッファ オブジェクトにアタッチされた非マルチサンプリング テクスチャであり、glDrawBuffers() を使用してレンダー ターゲットとして設定されます。これは問題なく動作し、後でこれらのテクスチャをサンプリングして、ライティングの計算に必要な情報を取得できます。素晴らしい。

取得しているエイリアシングの一部を削除したいので、マルチサンプル テクスチャを使用して明示的な MSAA の実装を開始しました。ただし、代わりにマルチサンプル テクスチャをレンダー ターゲットとして使用すると、最初のレンダー ターゲットのみが描画され、残りは空白のままになります。

シェーダーでのテクスチャのセットアップ、バインド、読み取りの方法を変更する以外は、他のコードは変更していません。

マルチサンプリングされたテクスチャは、次のコードを使用してフレーム バッファ オブジェクトにアタッチされます。

マルチサンプリングされた深度/ステンシル テクスチャも添付されます。

次に、フレームバッファがバインドされ、描画バッファが設定されます

次に、通常どおりジオメトリを描画します。ただし、apitrace で検査すると、最初の色のアタッチメントだけが引き込まれていることが明らかです。これは、通常の (マルチサンプリングされていない) テクスチャを使用する場合には当てはまりません。

ただし、4 つの描画バッファはすべて、まだ確実に設定されています。

2D テクスチャが 2 つあります。最初の MSAA テクスチャは、 のターゲットを使用しGL_TEXTURE_2D_MULTISAMPLEます。2 番目の非 MSAA テクスチャは、 のターゲットを使用しGL_TEXTURE_2Dます。

ARB_texture_multisample に関するOpenGL の仕様によるとGL_NEAREST、MSAA テクスチャが描画されている場合にのみ有効なフィルタリング オプションです。

この場合、これらのテクスチャは両方ともGL_COLOR_ATTACHMENT0、個々の Framebuffer オブジェクトを介してアタッチされています。それらの解像度も同じサイズです (私の知る限り、これは MSAA を非 MSAA にブリットするときに必要です)。

したがって、現在の制約を考えると、MSAA 保持 FBO を非 MSAA 保持 FBO にブリットした場合、両方のテクスチャが既にレンダリングされているためGL_NEAREST、フィルタリング オプションとして使用する必要があるか、または有効ですか?GL_LINEAR

キューブの端に、RGBA 0、0、0、0 の線が表示され、その位置でのテクスチャ ルックアップが失敗します。フラグメント シェーダーでマゼンタに失敗したテクスチャ ルックアップに色を付けました。

最初にテクスチャにレンダリングし、それをクワッドにバインドしてから、立方体ごとではなく MSAA を実行する必要がありますか?

おそらく、まだ塗りつぶされていないピクセルをサンプリングします。