問題タブ [shadow-mapping]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
1 に答える
1818 参照

opengl - シャドウ マッピングを使用すると、OpenGL 3.3+ で正しくないシャドウが表示される

OpenGL 3.3+ を使用してランドスケープ エディターにシャドウ マッピングを実装しようとしています。いくつかのチュートリアルを使用して、コードをコンパイルして実行することができましたが、ランドスケープ グリッドの後ろの行 (最小の z) を除いて、ランドスケープ全体が影になっています。

現在、ライトにカメラと同じ投影、ビュー、およびモデル マトリックスを使用しています (負の z はカメラから最も離れています)。

投影、ビュー、およびモデル マトリックスの初期化 (LWJGL マトリックス チュートリアルから):

シーンを表示するときにマトリックスをバインドする:

フラグメント シェーダーに色を保存して FBO をテストしたところ、高さマップが正しく表示され (画面の隅にある小さなクワッドに FBO テクスチャを描画しました)、高さマップを変更すると更新されました。

次に、最初のパスで深度をテクスチャに保存するように FBO を変更しました。

最初のパスの頂点シェーダー (シャドウ マップの作成):

最初のパスのフラグメント シェーダー:

私のバイアス行列:

2 番目のパスの頂点シェーダー (シャドウ マップを使用してシーンをレンダリング):

2 番目のパスのフラグメント シェーダー:

0 投票する
1 に答える
909 参照

opengl - OpenGL 3.3 2 つの GPU での 2 つの異なる結果 nVidia Optimus とシャドウ マッピング

だから私はC ++で(将来的にゲームを学び、作成するために)プロジェクトに取り組んでおり、レンダリングのためにOpenGL 3.3を選択しました。デフォルトの新しいアプリを開き、すべてがうまくいったので、プロセッサーに組み込まれた Intel HD 4000 に取り組んできました。しかし、その後、2番目のGPUであるnVidia GTX660mで開こうとしましたが、これははるかに高速であり、より多くのFPSが期待されていました。しかし、いいえ、何十ものバグがあっただけではありません(たとえば、フラグメントシェーダーで色としてvec3を出力した場合、Intelは問題ありませんでしたが、vec4を出力しなかった場合、nVidiaは完全にクレイジーなスタイルになりました...)。もちろん、コンパイル時にエラーが発生するわけではないので、修正するのは非常に困難です...

しかし今、私はそれのほとんどを修正したとき、私が望むように修正できない1つの問題に苦労しています(いくつかの汚い方法があるかもしれませんが...それはポイントではありません)。

簡単に言えば、両方の GPU で有効な深度マップを生成しますが、nVidia GPU ではグレースケールではなく、バーの赤から黒へのスケールです。同じ API!)。そのため、私のフラグメント シェーダーはそれに追いつかない可能性が高く、nVidia では、照らされた領域と完全に暗い領域を検出しません (少なくともスポットライトでは、ディレクショナル ライトは機能しません)。

写真: Intel HD4000 を使用した場合の画像 (i5 ivy-bridge cpu から取得) RMB メニューからアプリを実行し、nVidia GTX660m を使用した場合のイメージ。 ソフト シャドウなし

重要 - GTX660m の深度マップは、Intel GPU のようなグレースケールではなく、redToBlack スケールであることに注意してください。上はディレクショナル ライト、下はもちろんポイント ライトです。

マイ FragmentShader: #version 330 コア

最初の部分はディレクショナル ライト用です - 5 つのポイントで深度マップを事前にサンプリングします。すべてが同じである場合は、それ以上サンプリングしません (早期ベイリング - パフォーマンスの最適化が大幅に向上します!)。または、一部が異なる場合は、すべてをサンプリングし、現在のフラグメントの影の強度を計算します。 .

2 番目の部分は、ポイント ライトの深度マップから単純にサンプリングしたものです。次に、レイの中心からの距離をチェックして、懐中電灯の効果 (中心が強い) をシミュレートします。

これ以上何も必要ないと思いますが、必要な場合は書いてください。必要なコードを投稿します。

また、シャドウマップの精度は 16 ビットのみ (GL_DEPTH_COMPONENT16) です。Intel HD4000 は私の GTX660m よりも高速です (これはより強力です)。これは非常に奇妙です。ハイポリを描いていないからだと思いますが、非常にローポリが多いだけです。私は正しいですか?

0 投票する
1 に答える
416 参照

c# - XNA 3.0 を使用したソフト シャドウ手法

私は XNA 3.0 で作業しており (ため息、わかります)、スポット ライトがトーラスに当たり、エッジのきつい影を投影するオブジェクトを使用して 3D シーンを実装するのに役立つチュートリアルに取り組んでいます。さて、その影を和らげるためのヘルプ (チュートリアル、ソース コード、スニペット) をどこで見つけることができるか知りたいですか?

0 投票する
1 に答える
536 参照

opengl - 奇妙なシャドウ マップの動作、座標を正しく計算できますか?

グラフィック エンジン用のシャドウ マップ シェーダーを作成しました。私は次のチュートリアルに従いました: パート 1と次のパート。

残念ながら、私が得た結果はかなりずれています。ここにいくつかのスクリーンショットがあります。それらは、私のシーンが通常どのように見えるか、シャドウが有効になっているシーン、およびシャドウ マップの内容を示しています (中央の白いものは無視してください。これは単なるアヒルのジオメトリです)。

これは、フラグメント シェーダーでシャドウ マップをサンプリングするための座標を計算する方法です。

lightSpacePosition ベクトルは次のように計算されます。

射影行列は次のとおりです。

シャドウ マップは問題ないようで、レンダリング パスがシャドウ マップ パスと同じ lightSpacePosition ベクトルを使用していることを確認しました。しかし、何が悪いのかわかりません。

0 投票する
0 に答える
134 参照

opengl-es - シャドウ マップ: 同じ UV でのサンプリング

カメラ ビューの 2 つのピクセルがシャドウ マップ上の同じ UV 上にある場合、OpenGL でシャドウ マップを使用すると問題が発生します。これがどのように見えるかです:

同じ UV の問題に関するシャドウ マップ http://img7.imageshack.us/img7/4459/ida9.png

両方の可視シャドウが同じ UV のシャドウ マップに表示されます。明らかに側面のシャドウが問題です。これを修正する方法はありますか?

これが私のフラグメントシェーダーです:

ありがとう。

0 投票する
1 に答える
1581 参照

java - ディレクショナル ライトの正射投影を使用する OpenGL 3+

現在、移動する (太陽のような) 光源からのディレクショナル ライト シャドウ マップに問題があります。

最初に実装したとき、ライト プロジェクション マトリックスは 3D として計算され、シャドウ マップが美しく表示されました。次に、私がやろうとしていることについては、正投影の方がうまくいくことを学びましたが、適切な投影行列を代用するのに苦労しています。

1 ティックごとに、予想どおり、太陽は円に沿って一定量移動します。自家製の「lookAt」メソッドを使用して、適切な表示マトリックスを決定します。たとえば、日光は午前 6 時から午後 6 時まで発生します。太陽が午前 9 時の位置 (45 度) にあるとき、太陽は原点を見て、シャドウ マップをフレーム バッファにレンダリングする必要があります。正投影で起こっているように見えるのは、原点に向かって「下に傾いていない」ということです。代わりに、Z 軸をまっすぐ見続けるだけです。午前 6 時と午後 6 時は問題ないように見えますが、たとえば正午にはまったく何も表示されません。

設定方法は次のとおりです。

元の 3D 射影行列:

LookAt メソッド:

正射投影 (幅 100、高さ 75、近 1.0、遠 100 を使用) 私は多くの異なる値でこれを試しました:

シャドウ マップの頂点シェーダー:

シャドウ マップ フラグメント シェーダー:

ここで非常に単純なものが欠けているように感じます。前述したように、これは 3D プロジェクション マトリックスで問題なく動作しますが、ユーザーが世界中を移動する際に一定の影が必要です。これは、指向性照明、つまり正射投影に適しています。

0 投票する
0 に答える
330 参照

opengl - Strange behaviour with shadow mapping using GLSL shaders

I've integrated basic shadow mapping. However I noticed a strange behaviour with the rendering. To summarize, the shadow mapping technics requires 2 step. The first to render the scene from the light point of view (filling of a depth texture) and the second from the camera point of view. Here's the C++ code foir the first step :

Here's the output :

enter image description here

There's acnee on the floor. But now if I erase the code below the part corresponding the sending of the vertices to the program shader :

I have the following output (with no acnee) :

enter image description here

Here's is the vertex shader :

As you can see I transform my vertices in light (view) position. So in my C++ code if I don't send (in the second case) the vertices I wonder how it works ! (I just send the light MVP matrix !) And the most amazing thing is there is no more acnee! How can you explain this behaviour ? Do I send the vertices to the shader like in the first case (and find a solution to erase the acnee on the floor) or not ?