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

自明ではないシェーダーを書くとき（他の自明でないコードを書くときと同じように）、人々は間違いを犯します。[要出典]ただし、他のコードのようにデバッグすることはできません。結局、gdbまたはVisual Studioデバッガーを添付することはできません。コンソール出力の形式がないため、printfデバッグすらできません。私が通常していることは、見たいデータを色としてレンダリングすることですが、それは非常に初歩的で素人的な解決策です。私は人々がより良い解決策を思いついたと確信しています。 では、シェーダーを実際にデバッグするにはどうすればよいですか？シェーダーをステップスルーする方法はありますか？特定の頂点/プリミティブ/フラグメントでシェーダーの実行を見ることはできますか？ （この質問は、「通常の」コードをデバッグする方法に似たシェーダーコードのデバッグ方法に関するものであり、状態の変更などのデバッグに関するものではありません。）

45 opengl  glsl  debugging 

多くの場合、いくつかのシェーダー間でコードをコピー＆ペーストします。これには、単一のパイプライン内のすべてのシェーダー間で共有される特定の計算またはデータ、およびすべての頂点シェーダー（またはその他のステージ）が必要とする共通の計算の両方が含まれます。 もちろん、それは恐ろしい習慣です。コードをどこかで変更する必要がある場合は、他のすべての場所でコードを変更する必要があります。 DRYを維持するための承認済みのベストプラクティスはありますか？人々はすべてのシェーダーに単一の共通ファイルを追加するだけですか？彼らは#includeディレクティブを解析する独自の初歩的なCスタイルのプリプロセッサを書いていますか？業界で受け入れられているパターンがある場合は、それらをフォローしたいと思います。

30 glsl 

自分で Perlin Noiseを実装しようとしました理論だけを使っ（flafla2.github.io/2014/08/09/perlinnoise.htmlに続きます）。残念ながら、「オリジナル」のパーリンノイズの外観を実現できませんでした。 以下のコードがPerlin Noiseのブロックバージョンをレンダリングする理由は何ですか？ アーティファクトなしでPerlin Noiseをレンダリングするために、コードを改善/変更する必要があるものは何ですか？ 補間方法またはgradsベクトルに問題がある可能性があります。gradsすべての4つの近くの格子点について-ベクトルドット（格子点ランダムベクトル）の生成物および（サイズのベクター）を含みます。（ランダムおよびサイズのベクトルは、最初のリンクで説明されています。） GLSLサンドボックス：http : //glslsandbox.com/e#32663.0 float fade(float t) { return t * t * t * (t * (t * 6. - 15.) + 10.); } vec2 smooth(vec2 x) { return vec2(fade(x.x), fade(x.y)); } vec2 hash(vec2 co) { return fract (vec2(.5654654, -.65465) * dot …

21 glsl  noise  artifacts 

私は素晴らしい数学の世界を発見しており、PBRと命名で巨大な壁にぶつかっているので、いくつか質問があります：BRDFを理解する限り、マテリアルが光にどのように反応するか（直接的な光と反射の受信）を説明します。しかし、「クックトーランス」では、反射については何も表示されません。統合方法がわからないため、拡散光と反射しか得られません。 「Oren-Nayar」のような異なる「拡散用語」についてたくさん読んだことがありますが、DFGノミネーターの異なる「D」のようなCook-Torranceの一部ですか？鏡面反射計算なしで置き換えますか？ ブレンダーアーティストの背景から「GGX」について多くのことを読みましたが、それはぼやけた反射を引き起こすものだと思っていましたが、間違っているようで、今ではマイクロファセットなどのさまざまな状況でこのGGX用語を見つけていますこのチュートリアルの配布 つまり、問題は「Oren-Nayar」と「GGX」と「Cook-Torrance」が互いにどのように関係しているのか（それらがある場合）、それらのアルゴリズムに「vec3リフレクション」をどのように統合するかです。 前に言ったように、私は数学の初心者なので、あなたの答えが「数学が重い」なら、あなたの方程式のglsl / hlslバージョンを書いてください。 PS：私の質問はぼやけていることは理解していますが、主題を理解するのと同じくらいぼやけています。

13 glsl  pbr 

GLSLでは、頂点属性の遠近法による正しい補間がデフォルト設定です-noperspective修飾子を使用して、特定の頂点属性に対してそれを無効にできます。後処理シェーダー以外では、パースペクティブの正しい補間が無効になっているのを見たことがありません。他の使用例はありますか？また、パフォーマンス面でも違いはありますか？

13 opengl  glsl  performance 

動的ループ関数をシェーダーに統合するための最良の方法は何ですか？ まず、動的配列は不可能であるようです。では、最大サイズの配列を作成し、その一部のみを埋めるか、定義済みのサイズで配列を定義する方が良いでしょうか？ 次に、この配列を反復処理する最良の方法は何ですか？ 4〜128回の反復で、展開されたループまたは動的ループを使用する方が良いですか。また、事前定義された最大反復回数まで展開してから、などの条件で停止できることも確認しましたif (i == myCurrentMaximumIterationNumber)。

11 opengl  rendering  shader  glsl  performance 

シーンのレンダリングには通常、複数のシェーダープログラムが含まれます。私の場合、すべてが同じ属性を使用し、少なくともいくつかのユニフォームを共有しています。それらを適切に機能させるために、私は現在安全にプレイしています。つまり、シェーダープログラムを切り替えるたびに属性を再バインドし、適切な均一の場所を取得しています。したがって、基本的に各フレームで複数回実行することは、おそらく最善の方法ではありません。 では、シェーダープログラムを切り替えた後、（一般的に）属性とユニフォームを再バインドする必要がありますか？なぜ？ もしそうなら、これをプログラムの開始時に一度行い、再びそれらに触れる必要がない方法はありますか？

11 opengl  glsl  shader 

GLSLでテクスチャを使用する場合、頂点シェーダーで最終的なテクスチャ座標を計算し、varyings を使用してそれらをフラグメントシェーダーに渡すのが最善です。y座標の単純な反転の例： // Vertex shader attribute vec2 texture; varying highp vec2 texCoord; // ... void main() { texCoord = vec2(texture.x, 1.0-texture.y); // ... } // Fragment shader varying highp vec2 textureCoordinates; uniform sampler2D tex; // ... void main() { highp vec4 texColor = texture2D(tex, texCoord); // ... } Y座標の反転、またはvec2(0.5)テクスチャ座標への追加などのさらに単純な操作がフラグメントシェーダーで実行される場合、テクスチャアクセスは非常に遅くなります。どうして？ 注意として、たとえば、2つのテクスチャをブレンドして、それらの加重和を使用すると、時間の点ではるかに安価であり、各ピクセルに対して実行する必要があるため、テクスチャ座標自体の計算はそれほどコストがかかるとは思われません。

11 performance  glsl  fragment-shader 

まず第一に、深度マップとキューブマップを使用したシャドウマッピングに関する多くの投稿を読み、それらがどのように機能するかを理解しています。また、OpenGLを使用してそれらを使用した経験がありますが、実装に問題があります。 「EZ3」という名前の3Dグラフィックエンジンで単一の点光源を使用した全方向シャドウマッピングテクニック。私のエンジンでは、WebGLを3DグラフィックAPIとして、JavaScriptをプログラミング言語として使用しています。これは、コンピューターサイエンスの学士論文のためです。 基本的に、これはシャドウマッピングアルゴリズムを実装した方法ですが、ポイントライトの場合にのみ焦点を当てます。 まず、次のように前面カリングをアクティブにします。 if (this.state.faceCulling !== Material.FRONT) { if (this.state.faceCulling === Material.NONE) gl.enable(gl.CULL_FACE); gl.cullFace(gl.FRONT); this.state.faceCulling = Material.FRONT; } 次に、各キューブマップ面の深度値を記録するために深度プログラムを作成します。これは、GLSL 1.0の深度プログラムコードです。 頂点シェーダー： precision highp float; attribute vec3 position; uniform mat4 uModelView; uniform mat4 uProjection; void main() { gl_Position = uProjection * uModelView * vec4(position, 1.0); } フラグメントシェーダー： precision highp float; …

9 glsl  webgl  shadow-mapping 

マイクロファセットBRDFモデルを実装しようとしています。セバスチャンラガルドのスライドを読んでいます。コードに数式を実装しましたが、結果の画像が間違っていると思います。 黄色は素材のベースカラーです。鏡面色は正しく見えるように赤です。 私のコード： // Fragment Shader #version 330 core in vec3 Position; in vec2 TexCoord0; in vec3 Normal; in vec3 Tangent; out vec4 FinalColor; uniform vec3 uCameraPosition; // init value: vec3(0, 0, 5) #define PI 3.1415926f #define EPSILON 10e-5f #define saturate(value) clamp(value, 0.0f, 1.0f); float BRDF_Lambert(float NdotL) { return NdotL; …

9 rendering  glsl  shading  specular 

私は最新のOpenGL（3.1以降）を使用してレンダラーを作成していますが、今ではユニフォームを処理する効率的で柔軟な方法を作成しようとしています。私は、均一なバッファオブジェクトと、これらを使用するための「一般的な」アプローチとは何かを調べてきました（後者は、残念ながら、期待していたほど多くの結果が得られませんでした）。 OpenGL API呼び出しを減らし、連続したメモリにデータを保存するために、GPUにアップロードする必要がある各データ構造に対して複数の大きなバッファーを作成することを検討しています。各バッファの最大サイズは16kbです（私が理解しているところによると、これはUBOで使用できることが保証されています）。オブジェクトがユニフォームをGPUにアップロードできるようにしたい場合、まだいっぱいではない、アップロード対象のタイプの最初のバッファーをフェッチし、そのバッファー内で次に使用可能なインデックスを取得します。オブジェクトが描画されると、UBOがバインドされ（まだバインドされていない場合）、UBOの要素インデックスがアップロードされます。 これにより、次のような結果になります。 layout(std140) uniform ModelData { mat4 model_matrix[kNumInstancesPerModelUbo]; } uniform int u_ModelDataIndex; layout(std140) uniform SkeletonData { mat4 bone_transforms[kNumInstancesPerSkeletonUbo][kMaxBones]; } uniform int u_SkeletonDataIndex; ただし、次のことも検討しています。 layout(std140) uniform MeshData { mat4 model_matrix[kNumInstancesPerMeshUbo]; mat4 bone_transforms[kNumInstancesPerMeshUbo][kMaxBones]; } uniform int u_MeshDataIndex; いくつかの点で、これは、アップロードされるメッシュに関連するすべてのデータにアクセスするために単一のインデックスを必要とするという点で、はるかにきれいに感じられます。一方、これは手に負えない可能性があります（16kbより大きいバッファーサイズ、無関係なデータ（スケルトンのないメッシュなど）へのハンドル）、またはモデルマトリックスのアップロード中にボーンを言うためのアクセスが許可されていないため、同期の問題も発生します）これがGPUのメモリレイアウトにどのように影響するかはわかりません。 率直に言って、私はここで立ち往生しているように感じ、UBOを高速で柔軟に処理する方法の具体的な例を見つけることができません。 ここで私を助けることができるアドバイスやリソースはありますか？

8 opengl  rendering  glsl  c++  uniform-buffer-object 

私は深度テクスチャを使用してOpenGLのシャドウマッピングをいじっています。深度テクスチャは細かいので、シーンにマッピングできますが、オブジェクトの裏側に奇妙なアーティファクトがあります。 私の質問は、これを引き起こしているものであり、どうすれば修正できますか？ 私が使用しているフラグメントシェーダーはかなり単純です（ここに青がない理由に疑問がある場合に備えて、簡単にするために色を取り除いています）。 in vec4 vShadowCoord; uniform sampler2DShadow shadowMap; out vec4 fragColor; void main() { float bias = 0.005; float visibility = 1.0; if (texture(shadowMap, vec3(vShadowCoord.xy, vShadowCoord.z / vShadowCoord.w)) < (vShadowCoord.z - bias) / vShadowCoord.w) visibility = 0.25; fragColor = vec4(visibility); } 編集：必要に応じて、上記のコードのみを使用する最低限の作業例のスクリーンショット（色なし）。

8 opengl  glsl  shadow-mapping  shadow 

シェーダーのユニフォームをどのように構成するかに基づいて、パフォーマンスに影響があるかどうか知りたいのですが。たとえば、4つのfloatを渡すことは、単一のvec4を渡すよりも悪いですか？

8 performance  glsl  shader