タグ付けされた質問 「pixel-shader」

3
コンピューティングシェーダーは、画像フィルタリングのピクセルシェーダーよりも効率的ですか?
ブラー、SSAO、ブルームなどの画像フィルタリング操作は、通常、ピクセルシェーダーと「収集」操作を使用して行われます。各ピクセルシェーダーの呼び出しは、隣接するピクセル値にアクセスするために多数のテクスチャフェッチを発行し、単一のピクセルの価値を計算します結果。このアプローチには、多くの冗長なフェッチが行われるという理論上の非効率があります。近くのシェーダー呼び出しは、同じテクセルの多くを再フェッチします。 別の方法は、計算シェーダーを使用することです。これらには、シェーダー呼び出しのグループ全体で少量のメモリを共有できるという潜在的な利点があります。たとえば、各呼び出しで1つのテクセルをフェッチして共有メモリに保存し、そこから結果を計算できます。これは、高速かもしれませんし、そうでないかもしれません。 質問は、どのような状況下で(実際に)コンピューティングシェーダーメソッドがピクセルシェーダーメソッドよりも実際に高速であるかということです。カーネルのサイズ、どんな種類のフィルタリング操作などに依存しますか?明らかに、答えはGPUのモデルによって異なりますが、一般的な傾向があるかどうか聞いてみたいと思います。

3
ゲームでピクセルを直接描画できるのに、OpenGLやDirectXなどのグラフィックフレームワークがあるのはなぜですか?
ゲームやその他のグラフィックを多用するアプリケーションは、OpenGLやDirectXなどのフレームワークを使用します。また、ピクセルシェーダーやDX12などの機能が必要です。 しかし、ピクセル単位ですべてを描画できるのに、なぜこれらすべてのフレームワークとGPU機能が必要なのでしょうか? まず、ゲームはピクセル単位で描画されるようにコンパイルする必要があります。これにより、ゲームの実行可能サイズが大きくなる可能性がありますが、より高速で、32ビットカラーGPU(古いものでも)で動作しますか? 最初の3Dゲームはピクセルごとに描かれたのは知っていますが、なぜ今はそうしていないのですか?

1
グローシェーダーを微調整して見栄えを良くする
私は単純なゲームをしていて、その主題はこれらの小さな線です。iOSとAndroidをターゲットにしているため、現時点で実行できるプロセッサの範囲は非常に広いです。 2つの理由でリアルタイムのグローを追加しようとしています ほとんどのデバイスでアンチエイリアスを処理するためのレンダリング時間がないという事実を隠そうとしています。 ゲームの主題は純粋な光であることになっています。つまり、それらのものが純粋な光のように見えるはずです。 私はかなり長い間、分離可能なガウスぼかしシェーダーを微調整してきました、そして私は欲求不満の点に達しました、私はそれを正しく見せることができません、おそらく問題は光のギザギザのエッジを無駄に隠そうとしていることですその間、光をぼやけさせないようにします。 私の最大の問題は、それを最高に見えるようにするために必要なすべての変数です。 私はグラフィックス/レンダリングに非常に慣れており、決してアーティストではありません。恐らく、私にとってのレンディングで最もイライラするのは、関係しているように見えるすべての変数です。輝きをもって私は多くの可能な変化を見てきました。 A.ブレンドモード、スクリーンブレンドモード、またはその他の調合を追加する B.ぼかし、通常の組み合わせ前の重み付け C.ガウスベル関数のシグマ(私はこの 紛らわしい計算機を使用していますが、他の人が持っているのと同じ値を与えていないようです) D. sigma関数に送信される "x"値のスカラー E.サンプルスケール(ぼかし半径を小さくまたは大きくする) F.グローバッファーの解像度を変更する このように多くの変数を扱うときに、どのようにして「最適な」定数を見つけるのでしょうか。 微調整を行ってから変更が表示されるまでの時間が長いため、問題も発生しています。シェーダートイで実行しますが、この画像をロードしたり、そのようなものを手続き的に生成したりすることはできません。 現在、ガウシアンベルカーブカーネルのシグマに悩まされています。特に、プロセッサーの速度が必要なため、数式ではなく数値でコーディングしているためです。使用する良いシグマを提案できますか?

2
シェーダーは、シェーディングされたメッシュが占めるピクセルを超えて、スクリーンピクセルをペイントできますか?
ジオメトリとコンピューティングシェーダーのプログラミングの経験はありますが、フラグメントシェーダーを実際に使ってみたことはありません。現在、私はそれらがどのように機能するか、そしてそれらの可能性をよりよく理解しようとしています。私が複数の場所で読んだことの1つは、フラグメント(スクリーンピクセル)がフラグメントシェーダー内でそれ自体を超えて拡張できないことです。つまり、反復される特定のフラグメントは、それ自体にのみ影響を与えることができます。 したがって、私は学習のために、次のことが可能かどうか(可能であれば、一般的にはどのようにして達成できるか)を知りたいと思います。簡単にするために、2つの頂点のみからなるポイントメッシュ(3Dワールド空間に配置)があるとします。これらの2つの頂点のそれぞれが画面上のWorldToViewportの正確な位置に描画されるようにシェーダーをプログラムできますか。また、radius = Rの各頂点を囲む円も、それらが延長されている場合でも周囲のピクセルに描画されます。シェーダーがアタッチされている元のメッシュを超えていますか?下の図のように(円の中心にある赤い四角形が画面に描かれた頂点を表します): それが可能であれば、頂点を超えて延びるこれらの円が互いの色(RGBA)に影響を与えるように、シェーダーをプログラムすることもできますか?下の図のように: 私が言ったように、これらが可能であるなら、私はそのようなことを達成する方法の少しを概念的または実際的な面で聞きたいです。フラグメントシェーダーで行われますか、それとも頂点シェーダーまたはジオメトリシェーダーで前に計算する必要がありますか?メッシュボディが占めるフラグメントを超えて「追加のフラグメント」を計算して渡す方法は?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.