タグ付けされた質問 「normal-mapping」

Assimp Asset Importer（http://assimp.sourceforge.net/lib_html/index.html）を使用して3Dモデルを解析しています。 これまでのところ、メッシュの各頂点に定義されている法線ベクトルを単純に引き出しました。それでも、法線マップに関するさまざまなチュートリアルを見つけました... 法線マップについて理解しているように、法線ベクトルは法線マップの各テクセルに格納されており、これらをシェーダーの法線テクスチャから引き出します。 法線を取得するのに2つの方法があるのはなぜですか？

17 c++  opengl  normals  normal-mapping  assimp 

私は延期デカールシステムに取り組んできました。ここまでで、投影パーツを完成しました。つまり、シーン内の何かをクリックすると、デカールがオブジェクトの表面に適切に投影されます。 このシステムに追加したいことが他にいくつかあります。通常のクリッピングと通常のマップされたデカールです。通常のクリッピングは、鋭角に引き伸ばされたフラグメントを破棄するときです。見てここに。これを解決する方法は、Gバッファの法線とデカールの法線との間に大きな差があるフラグメントを破棄することです。これには、Gバッファの通常のテクスチャを読み取る必要があります。 デカール法線マッピングを行うには、デカールの法線（法線マップからの）をGバッファの法線とブレンドする必要があります。では、Gバッファの通常のテクスチャに書き込む必要があります。 これら2つの機能をサポートするために、同じシェーダーパスで通常のテクスチャを読み書きする必要があることは明らかです。残念なことに、これは未定義の動作なので、これらの機能を実装する他の方法があるかどうか疑問に思っています。

11 deferred-rendering  normal-mapping  frame-buffer  decal-system 

法線マップが青くならないのはなぜですか？法線のZ成分は青で表されるので、法線マップは主に青色である必要があると思います。法線はZ方向のサーフェスの外側を指しているため、Z成分が支配的であるため、主な色として青が表示されます。 定義により、接線空間は表面に垂直です。どの時点でも、法線は常にZ（青の方向）を指し、X（赤の方向）またはY（緑の方向）はありません。したがって、法線マップ（「法線マップ」であるため）は、法線の色が青（R = x = 0、G = y = 0、B = z = 1）であり、中間に陰影がない必要があります。 しかし、法線マップはそうではなく、陰影のグラデーションがあります。これはなぜですか？

11 normal-mapping 

法線マッピングの概念を理解しようとしていますが、いくつか混乱しています。つまり、法線マップが視点に依存するかどうか（つまり、同じオブジェクトの周りを回転したときに、同じオブジェクトの別の法線マップを取得できるかどうか）はわかりません。第二に、青みがかった色が法線マップで主な色である理由がわかりません。 法線と、RGBカラーとの関係については、次のように考えています。単位球は可能なすべての単位法線を表します。つまり、単位法線ベクトルのX、Y、Z成分は-1から1の範囲です。RGBカラーの成分はすべて0から255の範囲です。したがって、 -1（通常のコンポーネント）を0（カラーコンポーネント）、0から127または128、および1から255にマップします。その間の値はすべて線形補間されます。 このマッピングを任意の3Dオブジェクトの法線に適用すると、非常にカラフルな画像が得られますが、ほとんどが青色ではありません。たとえば、立方体の場合、6つの面すべてが異なるが均一な色になります。たとえば、法線が（1,0,0）の面は（255,128,128）、法線が（0,0、-1）の面は（128,128,0）のようになります。 ただし、何らかの理由で、私が見つけた立方体の法線マップは完全に青みがかっています（128、128、255）。しかし、明らかに、法線はすべて正のz方向ではありません（つまり、（0,0,1））。これはどのように作動しますか？ [編集] さて、上記のアプローチは、オブジェクト空間法線マップまたはワールド空間法線マップと呼ばれるようです。もう1つは接線空間法線マップます。このような接線空間法線マップを使用してジオメトリの法線を変更する方法を理解していますが、実際にどのように計算されるかはまだわかりません（Nicol Bolasの回答の私のコメントを参照）。 [編集2] おそらく、区分的パラメトリックサーフェスを使用していることをお伝えしておきます。これらのサーフェスは一連のサーフェスパッチで構成され、各パッチは独自のパラメトリック空間（u、v）= [0,1] x [0,1]に関連付けられています。サーフェス上の任意のポイントで、法線を正確に計算できます。どうやら、ベクトルT（接線）とB（双接線）—接線空間をまたがるのに必要な—は、単にuとvの方向の表面パッチの偏導関数ではありません...

10 vector  normal-mapping 

金属製のドラムメッシュがあり、その法線マップをベイクすると、奇妙な色が表示されます（添付の写真を参照）。私は色の水平方向のグラデーションのシフトについて話している。私のメッシュにはそのような変形はありませんが、なぜ色はそのようになりますか？私はさまざまなスペース（カメラ、世界など）を試しましたが、それでも問題があります（ただし、水平勾配はそれぞれで変化します）。また、接線空間は、全体的にブロック状の青色を返します。 誰かがメッシュから良い法線マップを取得する方法を教えてもらえますか？ ===更新 解決しました。LukeBに感謝します。本当に良い結果を得るために、オーバーラップしている2つのバージョンのうちの1つ（たとえば、低解像度のもの）を少しスケーリングするという問題がまだありますが、それはそれが行われるはずの方法です。 ===アップデート2 さらにルークBのアドバイスに従って、低解像度のメッシュにマルチ解像度モディファイアーを使用し、そこからベイクしました。以前よりはるかに良く見えますが、色のアーチファクトは最小限に抑えられており、実際にはGIMPのいくつかの修正により、かなり使いやすくなっています。

10 blender  normal-mapping 

3D業界では、あるアプリケーションから別のアプリケーションへの接線空間の正確で一貫した計算に依存する法線マッピングやその他の効果の接線空間を計算するために、Mikktspaceの標準がますます採用されています。Blender、xNormal、Unity、Substance Painter、Unreal Engineは、現在Mikttspaceを使用していると考えることができるほんの一部です。私は個人的に、この標準を採用するために自分のプロジェクトを再コーディングすることも試みています。 しかし、Mikktspaceは比較的新しいものであるため、その動作に関するリソースはほとんどありません。どんな小さなリソースでも、通常は詳細が少なく、非常に技術的であり、ユーザーフレンドリーではありません。または、コーダーが特定のレベルの知識を持っていると想定しています。 1つの言語だけに限定されない方法で数学とコードがどのように機能するかについての簡単な説明とともに、Mikktspaceの仕組みとその実装方法についての明確な説明を探しています。 例として、プログラマが頂点のインデックスを持つメッシュオブジェクトを持っているとします。頂点にはそれぞれ、位置、法線とUV座標、そのインデックスを参照する三角形のリストが含まれます。 例えば： Vertex：{XYZ NX NY NZ ST} VertexIndex： のリスト Vertex Triangle：{V1 V2 V3} （法線方向の正しい巻き順） TriangleList： のリスト Triangle 簡単に言えば、各頂点のMikktspaceに準拠した方法で、頂点ごとに正接ベクトル（TX TY TZ）と正接ベクトル（BX BY BZ）を計算するにはどうすればよいでしょうか。

8 transformation  normal-mapping