タグ付けされた質問 「shaders」

かなり静的なボクセル配列を考えると、より効率的です：CPUを使用してVBOを事前に生成し、ボクセルフェイスをレンダリングします（現時点では、マーチングキューブのような高度なレンダリング形式は無視します）。その場で顔？ 変化するボクセルを更新することについてはそれほど心配していませんが、もちろんVBOを再構築する必要がないため、GPUバージョンの利点です。また、GSアプローチはもう少しモダンだと感じています:) 一方、最新のGPUでGSがラスタライズパイプラインと実際にどのように機能するかについては詳しく見ていない。頂点を一種のストリームキャッシュに出力しますか、それとも頂点が通常のGPUメモリに書き込まれますか？後者の場合、オンザフライで生成すると、利用可能な帯域幅と処理能力が残りのGPUタスクから減少する可能性があり、CPUで実行する方が有益です。

26 opengl  directx  shaders  voxels 

Rocket LeagueやFIFAなどのゲームのスクリーンショットを見てきました。 そして、私は1つが近道草効果を達成するだろうと思い始めました。 シェーダーですか？実際のジオメトリですか？それとも、テクスチャ付きのクワッドですか？誰かが私を方向に向けることができれば、それは大歓迎です。

22 unity  shaders  particles  terrain-rendering 

この理由はどこにもありません。phongで使用される反射ベクトルは、物理学の基礎が単純です。しかし、blinnで使用されるハーフベクトルは、一見合理的な根拠がなく、適切な反映を構成していません。それにもかかわらず、いわゆる「物理ベース」のシェーディング機能すべてで使用されています。それに物理的な基盤があれば、知りたいのですが。 私が見つけることができたのはいくつかの理由です： それは速いです -これについてはさまざまな情報がありますが、それでも1998年には大きな理由だったでしょう。 これは90度よりも高い角度をより適切に処理します。これが唯一の理由である限り、フォンの用語が不適切に使用されているためです。反射とビューのドット積は、-1〜+1の角度を与えます。通常、この角度は0〜1に固定されており、これが90度問題の直接的な原因です。角度を固定するのではなく再正規化すると、180度の完全なカバレッジが得られます。私は、単純なx * 0.5 + 0.5の操作がグラフィックスの世界を40年間逃げていたとは信じません。 エッジをより適切に処理します -エッジの「問題」もblinnソリューションにわずかに存在します。主な原因は、ターミネーターでのエリア照明の不適切なシミュレーションです。これは、「物理ベースの」シェーダーに不可欠です。しかし、より単純な状況でも、シグモイド関数はソフトターミネーターラインを正しく近似できます。ランバート項への乗算は、鏡面反射項を不適切に減衰させるため不正確です。これにより、フレネル項がキャンセルされ、さらなるエラーが発生する可能性があります。 エッジに長い反射があります -異方性反射は現実的かもしれませんが、blinnはエッジにのみ表示されるため、それらを実装する正しい方法ではないようです。H項のエラーが偶然現実的に見えるのは、単なる幸せな偶然です。 これらの理由はどれも満足のいくものではありません。この狂気を整理したいと思います。 私はブリンとフォンの話ではないのですということを明確にしたい、特に、代わりにこれらのシェーダだけでなく、他の人のための基礎として使用されているベクトル成分HとR、程度。

22 shaders  fragment-shader  shading 

破棄命令を最初に検索したとき、破棄を使用するとパフォーマンスが低下するという専門家がいます。ピクセルを破棄すると、zBufferを適切に使用するGPUの機能が破損するため、GPUは両方のオブジェクトに対してフラグメントシェーダーを最初に実行して、カメラに近いものが破棄されるかどうかを確認する必要があると述べました。現在作業中の2Dゲームの場合、depth-testとdepth-writeの両方を無効にしました。私はすべてのオブジェクトをその深さでソートして描画していますが、それはすべてです。GPUが派手なことをする必要はありません。今、フラグメントシェーダーでピクセルを破棄するのはまだ悪いのではないかと思っています。

22 opengl  shaders  fragment-shader 

私は（元）雇用主のために3Dゲームプログラミングの公平な分配を行いました。また、独自のインディーゲーム用に独自のカスタムエンジンでプログラミングを行いました。 最初は、Direct3D 9とD3DX9から始めました。これらはほとんどすべてを行い、シェーダーの観点から考える必要はまったくありませんでした。 その後、最初のDirect3D 9シェーダーを作成しましたが、ほとんどすべてを1つの非常にシンプルなシェーダーで使用しました。 ゲームエンジンの最新の反復では、Direct3D 11に移行し、それによって多くのシェーダーを作成しました。GPUスキニング、GPU計算パーティクル、多くの照明効果、後処理効果をすべてGPUで行いました。本当にクールなもの。 これまでのところ、頂点シェーダーとピクセル/フラグメントシェーダーのみを使用しました。まだ行っていないことはまだたくさんありますが、頂点シェーダーとピクセル/フラグメントシェーダーが何をするのか、それが3Dパイプライン全体にどのように適合するのかについて確かな知識があると思います。 最近の開発に追いついて、新しいシェーダーステージに非常に興味を持ちました。つまり、ジオメトリシェーダー、さらに新しいハルシェーダーとドメインシェーダーです。 私はこれらのステージを使用したことはありませんが、知っていることから、Geometryシェーダーは、有効になっている場合、頂点シェーダーの後に実行され、変換された各頂点に1回（またはプリミティブごとに1回）、頂点（およびプリミティブ？）を破棄できます、新しいものを作成します（パイプラインの最初に戻ると思いますか？）。 私の推測では、ジオメトリシェーダーの主な用途は、GPUでジオメトリをプログラムで生成することです。一般的な使用法は、単一の頂点に基づいてビルボードクワッドを作成することですが、フラクタルや100％プログラムで生成できる他のものを除いて、他の多くの一般的なシナリオを実際に視覚化しません。 ハルシェーダーとドメインシェーダーについては、テッセレーション（粗い表面からより滑らかな表面を作成する？）に関連しているようで、一緒に使用する必要があるか、まったく使用しない必要があります。ここでは「パッチ」という用語も一般的なようです。 これらの新しいシェーダーステージの目的、3Dパイプラインにどのように適合するか、どのような場合にそれらを使用することを検討する必要があるのか​​、実際の用語で誰かに説明してもらえますか？

21 shaders  tessellation  geometry-shader  hull-shaders  domain-shaders 

OpenGL ES 2.0を使用しています。描画するクワッドがたくさんあります。GL_QUADSを使用しているかのように、クワッドあたり4つの頂点のみを渡すことができるようにしたいのですが、基本的には、独立したクワッドの束。 これまでのところ、私ができることを見つけました：-GL_TRIANGLES（クワッドあたり6頂点）-GL_TRIANGLE_STRIP（クワッドあたり6頂点）を縮退します 私が見つけた可能性：クアッドストリップをリセットする特別なインデックス値を持つ-GL_TRIANGLE_STRIPS（これはクアッドごとに5つのインデックスを意味しますが、これはOpenGL ES 2.0で可能だとは思いません）

21 opengl  3d  iphone  android  shaders 

現代のゲームでは、1つのシーンで同時にいくつのシェーダーが通常アクティブになっていますか？複数のシェーダーが使用されており、各フレームでゲームが切り替えられることを知っています。シェーダーを介してオブジェクトを描画することは一般的です。 すべてのオブジェクトをシェーダー1で描画します シェーダー1からシェーダー2に変更する シェーダー2ですべてのオブジェクトを描く それでも、特にシーン全体のグローエフェクト、テクスチャへのレンダリングなどのエフェクトの場合、それほど単純ではないことはわかっていますが、ほとんどの場合、そのように動作すると想定できますか？シェーダーの切り替えは高価な操作であるため、「シェーダーごとのグループ化」アプローチが適しています。 片側からは、シーンを高速でレンダリングするため、シェーダーを多くしすぎることはできません。一方、スキン、金属、水などには、多くの異なるシェーダー（または枝を持つ超シェーダー-非常に似ています）が必要です。 理論的、現代的、三人称のPC用3D探偵ゲーム（重要な場合はDirectX 11）は、いくつの（そしてどの）シェーダーを使用しますか？いくつかの「フレームX」で、アクティブのみをカウントする100個のアクティブシェーダーのように、5、20、またはそれ以上ですか？私はそれが1つの数字ではないことを知っていますが、PCゲームを考慮して、どのような規模と要因が重要なのかと思います。 私のサンプルゲームでは、フレームごとに約9〜11を使用します（別の小さなシェーダーまたは1つの超シェーダーとしてカウントします-今は関係ありません）。 スキンシェーダー アイシェーダー（多すぎない？ メタルシェーダー グラウンドシェーダー 雪/雨シェーダー（必要な場合） ウォーターシェーダー（シーンに水が存在する場合） グローシェーダー（一部の特殊効果が含まれる場合のみ） 発光シェーダー（街灯など） 標準シェーダー（他のすべての場合は標準シェーディングのみ） 法線マップ付きの標準シェーダー 2Dシェーダー（GUIなど） それは「たくさん」ですか「あまり多くない」ですか？必要ないくつかの重要なシェーダーを忘れましたか？

20 shaders  directx  rendering  directx11 

シェーダーでリアルな赤外線ビジョン効果をどのように構築しますか？現実的には、この例のように現実的に見えるものを意味します。 テクスチャを作成して材料が発する熱の量を判断し、次に法線とビューベクトルの内積を使用してその熱が視聴者に到達する量を判断することを考えていますが、これが熱視力であるかどうかもわかりませんでも動作するので、完全に間違っているかもしれない何かを実装し始める前に、より良いアプローチがあるかどうかチェックしたかったです。

20 shaders 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 閉じた3年前。 シェーダーについて学ぶことに興味があります。シェーダーとは何ですか、いつ/何のために、そしてどのように使用するのか。（具体的には、水とブルームの効果に興味がありますが、シェーダーについては0に近いことを知っているので、一般的な紹介が必要です）。 数年前の本をたくさん見たので、それらがまだ当てはまるかどうかわかりません。現時点ではXNA 4.0をターゲットにしています（Shader Model 4.0のHLSLシェーダーを意味すると思います）が、一般にDirectX 11とOpenGL 4をターゲットとするものは役立つと思います。

20 opengl  directx  shaders  hlsl  directx11 

Unity3Dで3Dゲームのイースターエッグを作成しようとしています。ゲームを一時的にASCIIアートでレンダリングしたい。 私の最初のアイデアは、それを行うためのシェーダーを作成することですが、それが正しい方法かどうかはわかりません。

19 unity  shaders 

そこにあるシェーダーウィザードには、これに似た油性/汚染された水の効果を実現する方法のアイデアがあります。 理想的には、水は均一に油性ではなく、代わりに油が何らかのソース（化学プラントからの汚染排水など）から生成され、水域全体に拡散する可能性があります。この部分の私の考えは、「オイルマップ」を水面上の各ポイントでオイルの密度を決定する2Dテクスチャとして保持することです。拡散し、その速度で水の速度とともに自然に移動します（動的波の波動粒子シミュレーションがあり、水面の泡についても同様のことを既に行っています）。ただし、オイルが水と同じ速度で移動しない可能性があるため、物理的にどの程度正しいかはわかりません。 そして、私はそれらのすべての奇抜な色を作る方法がわかりません:-)。考え？

19 shaders  graphics  hlsl  water  effect 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 2年前に閉店しました。 遅延シェーディングを備えた柔軟なUbershaderシステムを実装したい。私の現在のアイデアは、FlatTexture、BumpTexture、Displacement Mappingなどの特定の機能を処理するモジュールからシェーダーを作成することです。色をデコードしたり、トーンマッピングなどを行う小さなモジュールもあります。これには、 GPUがサポートしていない場合、特定のタイプのモジュールを交換します。そのため、現在のGPU機能に適応できます。このデザインが良いかどうかはわかりません。私は今、悪いデザインを選択し、後でそれを支払うことができるのではないかと恐れています。 私の質問は、シェーダー管理システムを効果的に実装する方法に関するリソース、例、記事はどこにありますか？ビッグゲームエンジンがこれを行う方法を知っている人はいますか？

18 opengl  shaders  deferred-rendering  resource-management 

XNAで2Dタイルベースのゲームを作成しています。 現在、私の雷はこのように見えます。 このように見えるようにするにはどうすればよいですか？ 各ブロックに独自の色合いがある代わりに、滑らかなオーバーレイがあります。 ある種のシェーダーを想定しており、周囲のタイルの照明値をシェーダーに渡すことを想定していますが、私はシェーダーの初心者なので、よくわかりません。 私の現在の照明は光を計算し、次にそれをaに渡しSpriteBatch、色合いパラメーターで描画します。各タイルにはColor、色合いに使用される照明アルゴリズムで描画する前に計算されるがあります。 これが現在どのようにライティングを計算するかの例です（左、右、下からもこれを行いますが、このフレームごとに行うのは本当にうんざりしました...） したがって、実際にこれまでに光を取得して描画することは問題ありません！ 霧の霧とグラデーション円形オーバーレイを使用して滑らかな稲妻を作成する無数のチュートリアルを見てきましたが、すでに各タイルに稲妻値を割り当てる素晴らしい方法があります。 レビューする 照明の計算（完了） タイルの描画（完了、シェーダー用に変更する必要があることはわかっています） シェードタイル（値を渡し、「グラデーション」を適用する方法）

18 xna  c#  shaders  rendering  lighting 

ピクセルシェーダーでフレームバッファーまたは深度バッファーをサンプリングさせておくと、非常に便利な機能になります。現在のピクセルの背後にあるものの深さまたは色を知ることができるだけでも役立ちます。 OpenGLとDirectXの両方でこれができないのはなぜですか？何らかのハードウェアの制限があると予想していましたが、アルファブレンディングではブレンドの計算にフレームバッファーの色を使用し、Zテストでは現在の位置で深度バッファーをサンプリングします。これらの値を直接公開しないのはなぜですか？将来これを見てみたいですか？

18 opengl  3d  directx  shaders 

私はGLSL頂点シェーダーをデバッグしている最中で、自分が間違っているという感覚を揺るがせません。 一般に、トレースの不足を補うために2つの戦略があります フラグメントシェーダーに渡すデバッグカラー変数に値を詰め込み、カラーの解釈を試みます。 頂点シェーダーコードを変更して、何が起こるかを確認します。 何らかの方法でテクスチャに値を書き込み、GPUからテクスチャを読み取り、テクスチャに詰め込まれた値を印刷することで、理想的にはトレースの不足を補うことができると考えています。 私の推測では、もっと良い方法があるかもしれません。助言がありますか？

18 shaders  debugging