1

実験として、画像 API のみを使用してテクスチャへのレンダリングを試みることにしました。最初は、深度テストの前にテクスチャの書き込みが行われたため、結果は明らかに間違っていました。を有効にしましたがearly_fragment_tests、これはほとんどこのタイプのユースケースで導入されましたが、Z ファイティングのように見える奇妙なちらつきが発生します。通常のレンダリング。

とにかく、問題の画像を含めました。何が起こっているのか、なぜこれが機能しないのか、誰かが説明を持っているかどうか知りたいです。動作させることはできますか？

ちらつくドワーフ

ここに最小限の再現子があります

    #version 420
    in vec3 normal;
    layout(binding = 0) writeonly uniform image2D outputTex;
    void main()
    {
        vec4 fragColor = vec4(normal, 1);
        imageStore(outputTex, ivec2(gl_FragCoord.xy), fragColor);
    }
4

1 に答える 1

0

あなたが示していないコードについて、いくつかの仮定を立てます。あなたがそれを見せなかったからです。私はそれを仮定するつもりです：

  1. この画像を表示するときは、適切なメモリ コヒーレンス操作を使用しました (実際の画面または/操作で)。glReadPixelsglGetTexImage
  2. このシーンは、通常のレンダリング コマンドを使用してレンダリングしました。三角形などの特別な順序は使用していません。各三角形の間でメモリ コヒーレンス操作を行う個別のレンダリング コマンドを使用して、各三角形をレンダリングしていません。

要するに、あなたの問題は実際にはシェーダーが原因であると仮定します。他の多くのことが原因である可能性があります。しかし、コードの残りの部分を表示するように設計しなかったため、わかりません。したがって、この答えは実際にはあなたの問題に答えないかもしれません。でもガベージイン、ガベージアウト。

あなたのシェーダーと上記の仮定から私が見ることができる問題は本当に非常に単純です:一貫性のないメモリ アクセス (画像の読み込み/保存など)は完全に順不同です。イメージ書き込み操作を実行しました。したがって、これらの保証を行う手順を実行しない限り、この書き込み操作に関する保証はありません。

はい、初期のフラグメント テストを使用しました。ただし、これは、フラグメント シェーダーからの一貫性のないメモリ アクセスの順序が特定の順序になるという意味ではありません。

三角形をレンダリングし、その前にそれを完全に覆う三角形をレンダリングするとどうなるかを考えてみてください。上部のフラグメントは下部のフラグメントの後に発生するため、初期のフラグメント テストは何も変更しません。また、イメージのロード/ストアは、同じピクセルへの書き込みの順序については何も保証しません。したがって、上の三角形への書き込みの後に、下の三角形への書き込みが完了する可能性が非常に高くなります。

私の知る限り、このように異なるフラグメント シェーダーから同じピクセルへの書き込みを注文することはできません。書き込み後にa を発行したとしてもmemoryBarrier、仕様を読んでも、ここでの書き込み順序が保証されるとは限りません。

正解は、これをまったく行わないことです。フラグメント シェーダーの出力に書き込みます。それが彼らの目的です。

于 2013-03-29T05:09:20.620 に答える