問題タブ [shader]

明るさとコントラストを適用する単純なピクセル シェーダー スクリプト効果は何ですか?

私はこれを見つけましたが、正しくないようです：

ありがとう！

属性の受け渡しや大量の異なるシェーダーの作成を伴わないライトがGLSLで有効になっているかどうかを確認する方法はありますか？

NVidiaのCforGraphics（Cg）を使用するのはどうですか？Cgでできますか？

私は今あなたがそれをすることができないと確信しています。しかし今、私は尋ねます：なぜそうではないのですか？

プログラムの状態に基づいてランタイムをシェーダーソースに渡す#definesを使用して、巨大なシェーダーを最適化して複雑さを軽減しています。最適化されたシェーダーをファイルに書き込みたいので、次にプログラムを実行するときに#definesを再度渡す必要はありませんが、プログラムの起動時に最適化されたシェーダーを直接コンパイルできます。これで、シェーダーの種類がわかりました。プログラムのニーズによって。

シェーダープリプロセッサーから結果を取得する方法はありますか？もちろん、＃define値をファイルに保存し、それに基づいてプログラムの起動時にシェーダーをコンパイルすることはできますが、それはそれほどエレガントではありません。

Windows の Dev-C++ でライブラリを再構築しようとしていました。ただし、その間に追加したシェーダー機能はサポートされておらず、コンパイラーは関連する関数 (::glCreateShader()、::glCreateProgram() など) を見つけることができませんでした。

インターネットと Dev-C++ フォルダーを調べてみると、OpenGL の実装 (gl.h) は v1.1 のみであることがわかりました。SGIから最新のヘッダーをダウンロードするための推奨事項を見つけました。gl3.h を見つけましたが、詳細に調べたところ、gl.h がプロジェクトに含まれていないことがわかりました。SDL/SDL_opengl.h を確認する必要があります。

編集: SDL_opengl.hには gl.hが含まれており、問題の関数のプロトタイプが宣言されています。問題は、なぜリンカ エラーではなくコンパイル時エラーが発生したのかということです。

(私のライブラリは mingw32、libOpenGL32、libSDL、libSDL_Image および libSDL_Mixer に対してのみリンクします。これは、OSX (もちろん mingw32 を除く) とほとんど同じで、問題はありませんでした。)

Dev-C++ および SDL で OpenGL v2.0 シェーダーを使用するにはどうすればよいですか?

ユーザーがシェーダー (.fx HLSL またはアセンブリ ファイル、複数のパスを使用する可能性がありますが、すべてのピクセル シェーダーのみ) を選択してプレビューできるようにする必要がある単純なアプリケーションがあります。

アプリケーションが実行され、シェーダーのリストが表示され、ボタンで「プレビュー ウィンドウ」が起動します。このプレビュー ウィンドウ (DirectX ビューポートを含む) から、ユーザーが画像を選択すると、その画像に対してシェーダーが実行されて表示されます。1 つのフレームのみをレンダリングする必要があります (リアルタイムではありません)。

クワッドを取得して画面にレンダリングし、選択した画像でテクスチャリングする頂点/ピクセル シェーダーの組み合わせをセットアップしました。これは完全に機能します。次に、最初の効果からの出力に対して別の効果 (純粋なピクセル シェーダー) を実行し、最終的な画像 (後処理) を画面に表示する必要があります。これはまったく機能しません。

過去数日間、それを機能させようとしましたが、明らかな理由もなく、各エフェクトのレンダリングに使用される同一のコード ブロックは最初のエフェクトのみをレンダリングします。最初のシェーダー ファイルの 2 番目のパスとして 2 番目のシェーダー ファイルを追加すると、完全に実行されます (ただし、ユーザーが作成したシェーダーをプレビューするという私の目標は完全に無効になります)。2 番目のエフェクト (正常にロードおよびコンパイルされる) を使用しようとすると、何も実行されません。最初のシェーダーの結果を (GetRenderTargetData を使用して) 取得し、それらをテクスチャとサーフェス (destTex および destSur) に配置し、そのテクスチャを 2 番目のパスの入力として設定しました (dev->SetTexture を使用し、後で effect-> を使用します)。 SetTexture("thisframe", destTex))。

すべての呼び出しが成功し、エフェクトがコンパイルされ、テクスチャがロードされ、四角形が描画されますが、エフェクトは表示されません。最初はデバイス (ソフトウェア頂点処理で作成) が問題の原因ではないかと疑っていましたが、そうではないようです (ハードウェアと混合で試しました)。さらに、HAL デバイスと REF デバイスの両方を使用すると (アプリはリアルタイムではないので問題ありません)、その 2 番目のシェーダーは表示されません。すべてが Direct3D 9 用の C++ で記述されています。

シェーダーを使用して球体にたくさんの円を描こうとしています。基本的なアルゴリズムは次のようになります。

1. (テクスチャ座標を使用して) フラグメントから円の中心の位置までの距離を計算します (円の中心もテクスチャ座標で指定されます)。
2. フレジェントから円の中心までの角度を計算します。
3. 角度に基づいて、テクスチャ (360 ピクセルを含み、赤のチャネルが半径距離を指定する) にアクセスし、指定された角度の半径を取得します。
4. フラグメントから円の中心までの距離が取得した半径よりも小さい場合、フラグメントの色は赤になり、それ以外の場合は青になります。

描きたいのですが... 青い球体に赤い円を60個描いてください。y シェーダーを 1 つの円で動作させましたが、60 を行うにはどうすればよいですか? これが私がこれまでに試したことです....

1. 特定の角度の半径を指定するデータ テクスチャを渡しましたが、アーティファクトが忍び寄っていることに気付きました。これは、以下を使用してデータ テクスチャから情報を取得しようとしたときの線形補間によるものだと思います。

   ここで、angles は特定の角度の半径を含むデータ テクスチャ (Sampler2D) であり、x = angle / 360.0 (角度は 0 ～ 360) および y = 0 ～ 60 (y は円の番号)

2. Uniform float radii[360] を渡そうとしましたが、動的インデックスで半径にアクセスできません。私もこの混乱を試しました...

   等々 ...

テクスチャを作成し、そのテクスチャにすべての円を配置してから、青い球体を円を含む球体とマルチテクスチャリングすると機能しますが、ご想像のとおり、エイリアシングが非常に悪くなります。事実上エイリアシングがないため、フラグメントの位置と円の位置に基づいて円を手続き的に生成するというアイデアが気に入っています。しかし、私は私が1つ以上行うのですか？

どうも！！！

〜ボルト

Apple の Shader Builder はそれほど高度ではありません。ブートキャンプで何かを実行する以外に、OS X のより良い選択肢があるかどうか疑問に思っていました。

それはDirectX 9についてです。

頂点シェーダーでレンダリングする一般的なケースでは、デバイスに 1 つ以上のストリーム ソースが設定され、頂点宣言を使用してソース データの形式が定義されます。

ここで、使用される頂点シェーダーが何らかの属性 (たとえば、D3DDECLUSAGE_NORMAL および UsageIndex 1 または 2 を持つもの) を必要とするが、提供される頂点宣言にその属性が含まれていない場合 (つまり、ストリーム ソースで提供されるデータにその属性が含まれない場合) )、DrawPrimitive が呼び出された場合、DirectX はその属性の値をどこで取得しますか?

シェーダーは、さまざまな統一名と属性を多数持つことができます。各シェーダーユニフォームの名前を事前に知り、その場所を取得するためにコードにハードコードする必要がないように、一般的なケースで機能するシステムを作成するにはどうすればよいですか。OpenGLを使用しています。

現在、次の GLSL コードを使用して、後処理の被写界深度シェーダーの深度テクスチャから読み取っています。

次に、深さの値を近距離と遠距離の平面距離に基づいてビュー空間距離に変換します。

これはすべてかなりうまくいくようですが、別zNearのzFar値を必要とせずに現在の射影行列のみに基づいて上記の計算を行う方法を知りたいと思っています。

私の最初の試み(vec4(tcscreen.x, tcScreen.y, depth, 1.0) * 2.0 - 1.0)では、射影行列の逆数を掛け、結果を で割り、結果の値を距離としてw取りましたzが、うまくいかなかったようです。ここで正しいアプローチは何ですか？

また、斜めの錐台クリッピングを使用してニアプレーンを選択したクリッピングプレーンにシフトすると、ニアプレーンの距離がピクセルごとに異なる可能性がありますか? もしそうなら、深度テクスチャからの距離を計算するシェーダーはこのケースを認識する必要があり、平面に近い距離が一定であると仮定しないことを意味しますか?

ありがとう！