Three.js: GLTFLoader：法線接線テストモデルの結果が正しくありません

@ cx20を書いてくれてありがとう。

詳細については、関連する情報と問題を以下に示します。

• 私は@donmccurdyさんThreeJS glTFビューア、donmccurdy / 3-gltfビューア＃10で同様の問題を報告しました。 しかし、これはビューアーではなく、ThreeJSのglTFローダーのバグだと思います。 したがって、この新しい問題は、私の古い問題よりも適切に配置されています。

• 上記の以前の号では、モデルは空を向いていましたが、後で水平線を向くように回転させました。 これにより、上記のように地平線が狂ったように回転するため、反射が正しくない場合に見やすくなります。

• モデル自身の法線マップの使用は、KhronosGroup / glTF＃952での議論によって正しいことが確認されました。

• ThreeJSの法線マップの処理は＃11315で質問されました。

• BabylonJSにも同様の問題があり、ここでここで修正されました。 これは、修正が適用されたBabylonJSのglTF2.0ローダーのライブデモです。

良い記事、ありがとう！

次の行を追加すると、モデルが正しくレンダリングされるように見えます。

materialParams.normalScale = new THREE.Vector2(-1, 1);

しかし、私はこの問題をよく理解しているかどうかわかりません。 ＃11315を理解すると、ここで役立つ場合があります。

@donmccurdyアドバイスありがとうございます。
normalScaleを調整することで改善することがわかりました。
ただし、glTFモデルが正しければ、glTFローダーで処理する方が良いと思います。

@ cx20が同意し、この修正はTHREE.GLTF2Loaderにマージされました。

修正中であることを確認しました。

Three.js +法線接線テストモデルの結果：

これは、r101とr104の間で後退しました。

https://github.com/mrdoob/three.js/pull/15749を参照して

理想的には、これを完全に解決するために、mikktspace接線を生成するためのJS実装がありますが、それはかなり複雑です。

今まで＃15749を知りませんでした。 私はこれに気をとられてしまいました。glTFで接線を定義するのに十分な仕事をしたので、少なくとも実行時に近似できると思っていました。

Blenderエクスポーターはファイルサイズを抑えるのに役立つため、デフォルトではglTFタンジェントをエクスポートしないことに注意してください。また、glTFの主要な実装はすべて、タンジェントなしでこのテストに合格していました。 この変更により、ThreeJSの大部分のglTFモデルの法線マッピングが壊れた可能性があります。

何が起こったのか、そしてその理由をより深く理解するために、リンクされたすべての問題を読むのに少し時間が必要です。 ただし、ほとんどのモデルはデフォルトでそのカテゴリに含まれていると思うので、glTFコミュニティは、接線のないモデルを再度正しくレンダリングするために、この高い優先度を考慮する必要があると思います。

再開😅

この変更により、ThreeJSの大部分のglTFモデルの法線マッピングが壊れた可能性があります。

それほど深刻なことではないと思います。デリバティブを使用してシェーダーで常にリアルタイムで接線を生成してきましたが、今でもそうしています。 以前、この特定のテストモデルを修正するために発生したハック（ normalScale.y *= -1 ）を含めましたが、他のいくつかの例を壊すこともありました。 それがいつ役に立ったか、または役に立たなかったかについての説明はありません。そのため、保存された接線をサポートしたら、ハックを削除しました。その場合、それは間違いなく間違っていたでしょう。 これで、ハックに依存していた（そして接線を含まない）モデルが壊れ、ハックによって壊れた（そして接線を含まない）モデルが修正されました。

ただし、ほとんどのモデルはデフォルトでそのカテゴリに含まれていると思うので、glTFコミュニティは、接線のないモデルを再度正しくレンダリングするために、この高い優先度を考慮する必要があると思います。

上記を参照。 一般的に、接線のないモデルを適切にレンダリングすると思います。 ただし、glTF仕様で要求されているようにmikktspaceタンジェントを生成することはありません。 私の知る限り、そのJS実装は存在せず、デリバティブベースのシェーダー実装は単に「ほぼ十分」な近似です。 このサンプルモデルは、その近似の限界を示す意図的に極端なケースです。

JSmikktspaceタンジェント生成の実装があれば嬉しいです。 それはTHREE.BufferGeometryUtilsへの良い追加でしょう。 しかし、公式の（ネイティブの）mikktspaceコードはかなり長く、接線を生成するためにどれだけの量が必要かをまだ十分に掘り下げていません。

以前、この特定のテストモデルを修正するために発生したハック（ normalScale.y *= -1 ）を含めましたが、他のいくつかの例を壊すこともありました。

それは他のglTFモデルを具体的に壊しましたか、それとも一般的な例にすぎませんでしたか？

野生では、2つの異なるタイプの接空間法線マップがあります。 サブスタンスペインターはこれらを「DirectX法線」および「OpenGL法線」と呼んでいますが、これはその最大の名前ではありません。 違いは、具体的にはyチャネルが反転していることです。つまり、テクスチャ内のすべての緑色のチャネル値が反転しています。 y *= -1掛けることは、一方を他方に変換する正しい方法です。 いわゆる「DirectX法線」は左手座標系を使用し、glTFは法線/接線/ビタンジェントの右手座標系を定義します。

私が考えているのは、ThreeJSが接線を自動計算するときに、法線マップが反転Y（DirectX）スタイルで作成されていることを想定し、そのチャネルをglTF用に逆方向に取得するため、反転が必要なことです。 ただし、接線が指定されている場合、そのようなフリップは必要ありません。

mikktspaceの質問はこれとは別だと思います。 仕様がmikktspaceを要求し、ほとんどの実装が画面空間の派生物でそれを近似しているのは残念です。 この2つがどれほど似ているかはわかりませんが、mikktspaceで生成された法線マップは、マップの左利き/右利きが正しく行われている限り、近似で表示するとかなりうまく機能するように見えます。

（これについては、昨年のKhronosGroup / glTF-Sample-Models＃174にもいくつかの議論があります）

特に法線マップのglTF仕様から1つの文を呼び出したいと思い

法線ベクトルは、+ Xが正しく、+ Yが上であるOpenGL規則を使用します。 + Zは視聴者を指します。

この文は、モデルを接線ベクトルなしで出荷できるようにし、スペースを節約するものです。

それをテストしましょう。 ここでは、ペイントプログラムの斑点からお粗末な高さマップ（バンプマップ）を作成しました。

この高さフィールドを外向きの隆起として定義しましょう。白いピクセルは視聴者に近く、黒いピクセルは遠くにあります。

オンラインコンバーター（品質は疑わしいですが、結果はすぐに調べます）を使用して、これを高さマップから法線マップに変換しました。 ここには3Dモデル、UV座標、mikktspace計算、またはジオメトリがないことに注意してください。 高さマップを法線マップに変換しただけです。 Xが正しく、Yが上で、Zがビューアに面するように、glTFの指示に従ってオンラインコンバータを手動で構成する必要がありました。 結果は次のとおりです。

それをペイントプログラムに戻し、カラーチャンネルをバストアウトして、これらのベクトルがどこを指しているかを確認しましょう。 以下では、各カラーチャネルが独自のグレースケール画像に分割されています。 これらは、黒が-1.0意味し、真ん中の灰色が0.0意味し、白が+1.0意味するように解釈されることに注意してください。

したがって、オンラインコンバーターは、少なくとも正しく構成した後、glTFが要求したことを実行したと思います。 赤（X）の画像では、右側の傾斜に白いピクセル（+1.0）があり、Xベクトルが画像の右端を指していることがわかります。 赤の画像の左側では、黒のピクセル（-1.0）がXベクトルを画像の左側に向けています。 緑（Y）の画像では、バンプの上部の傾斜に沿った白いピクセルが、画像の上部にあるYベクトルを指しています。 Z値は最も直感的ではありませんが、バンプの先端とバックプレート自体の両方がビューアを指しており、すべての側面の傾斜が離れているため、すべて均一に暗くなっていることに注意してください。

これを（glTFと同じように）OpenGLスタイルの法線マップを受け入れるBlender Eeveeにロードするとどうなりますか？ UVマップを回転させたり、拡大縮小して反転させたりするとどうなりますか？

結局のところ、これは問題なく機能します。 実際、この方法で接空間を定義することの全体的なポイントは、ソフトウェアがベクトルに夢中になることを可能にすることではなく、ジオメトリに関係なく法線マップが正しい向きになるようにすることで、テクスチャアーティストにある程度の正気を与えることです。

ただし、すべてのソフトウェアがOpenGL規則を使用しているわけではありません。 Yベクトルが画像の上部ではなく下部を指すという別の規則（DirectX規則と呼ばれることもあります）を使用するものもあります。 これが私の画像の分解されたYチャンネルです。 明るいピクセルは、画像の下部に面しているピクセルです。

これらのDirectXスタイルの法線マップの1つをBlenderEeveeにロードした場合でも、それが機能することを期待できますか？

いいえ。Blenderは+ Yアップを期待していました。 計算が間違っており、反射された地平線がぐるりと回転します。
+ Yダウンを予期していたエンジンにOpenGLスタイルの法線マップをロードした場合も、同じことが起こります。

これは、NormalTangentTestモデルがテストしようとしているものです。 各行は、UV座標を異なる方向に回転させ、反射がこれらの異なる方向で正しい向きを維持するようにします。

プリミティブとそのUV座標が与えられ、どのW記号をビタンジェントに使用するかを指定して、単独のプリミティブのタンジェントを計算する方法については、仕様に具体的な式が必要です。 「OpenGL法線」と「DX法線」は、式を導出するのに十分な精度ではありません。 それらは規則を参照しているかもしれませんが、実装者としてそれをどうするかはわかりません。

私が現在行っているのは、この特定のサンプルと一致するようにMikkTSpaceから反転したTangentWを放出することですが、それがたまたま機能したのです。

それは他のglTFモデルを具体的に壊しましたか、それとも一般的な例にすぎませんでしたか？

報告されたバグは、特にglTFモデルに関連していました。 とはいえ、FBXまたはCOLLADAを介したマテリアルのエクスポートには、これらの法線マップの規則が完全に理解され、テストされたと言っても過言ではないでしょう。

違いは、具体的にはyチャネルが反転していることです。つまり、テクスチャ内のすべての緑チャネル値が反転しています。 y * = -1を掛けることは、一方を他方に変換する正しい方法です。

おかげで、これは私たちがそれを実装したときよりもはるかに良い「ハック」の正当化です。 😇

仕様がmikktspaceを要求し、ほとんどの実装が画面空間の派生物でそれを近似しているのは残念です。

MikkTSpaceが接線を生成するための最も堅牢な方法であるという仕様は正しいと思いますが、実行時にこれを自動的に行うことは普遍的に正しい選択ではないと思います。 安価な代替品が特定のモデルに適しているように見える場合、見栄えが良くないより高価なものを実行する理由はありません。 スペック言語を緩めて概算できるようにすることもできますが、私はこれについて強く感じていません。

プリミティブとそのUV座標が与えられ、どのW記号をビタンジェントに使用するかを指定して、単独のプリミティブのタンジェントを計算する方法については、仕様に具体的な式が必要です。

MikkTSpaceアルゴリズムを離散式として表現するのがとても簡単かどうかはわかりません...正規のMikkTSpaceコードの代替を求めていますか？ または、MikkTSpaceを使用するための指示以外の追加情報はありますか？ @Themaister

元の問題では、 normal.y *= -1乗数をどこかに復元する必要があるようです。 これを行うには、3つの可能な場所があります。

• （a）GLTFLoaderで、接線を持たないメッシュの場合
• （b）GLTFLoaderで、すべてのメッシュに対して
• （c）WebGLRendererで、すべてのメッシュに対して

threejsが実際にDirectX規則を使用していて、たとえばBlenderが使用していない場合、（c）のケースを見ることができます。 ただし、迅速で安全な解決策のために、私は（a）を使用する傾向があります。

私が考えているのは、ThreeJSが接線を自動計算するときに、法線マップが反転Y（DirectX）スタイルで作成されていることを期待しているということです。

いいえ、three.jsはそれを想定していません...

three.jsは、接空間では+ Yが「上」であり、UV空間では-Vが「上」であると想定しています。

つまり、three.jsはuv（0、0）がテクスチャの左下隅にあると想定し、glTF仕様は左上隅を想定しています。 これが、 GLTFLoaderがtexture.flipYをfalse設定する理由です。 （three.jsはデフォルトでtexture.flipYをtrueに設定します。）

接線が存在しない場合、three.jsは画面空間の導関数を使用して接線を推定します。 それは連鎖律を使用してそうします。 その計算では、接空間とuv空間の方向が同じであると想定しています。

適切に作成されたglTFモデルの場合、その仮定は正しくありません。 ただし、_glTF仕様に適切に準拠している_すべてのモデルにnormalScale.y = - 1を設定することで、補正できるはずです。

また、シェーダーのflipYフラグを尊重することで、これを自動的に修正できるようにも思えます。

normalScale.yが機能しない場合は、別のことが起こっています。

この説明に感謝します。 ここには前進の道があると思います。

また、シェーダーのflipYフラグを尊重することで、これを自動的に修正できるようにも思えます。

はい、glTFが独自の接線ベクトルを提供する場合を除いて、そうですか？ 自動計算された接線だけがflipYテストとそれに対応するy否定を必要とすることを期待します。

そうでない場合...それは私のNormalTangentMirrorTestモデルに誤った接線がエンコードされていることを意味します。つまり、BlenderglTFエクスポーター自体が間違った接線をglTFモデルに入れています。

編集：エクスポートされた接線ベクトルの正確さを確認したと思います。Yを反転する必要はありません。 必要に応じて、詳細を投稿できます。

しかし、正しいアクションは、自動生成されたタンジェント（指定されたタンジェントではない）がflipYフラグで使用されている場合にのみ、 normalScale.yを反転することのようです。 考え？

以前の投稿では、属性の接線が存在しない場合に逆法線を手動で補正する方法を説明しました。 画面空間の導関数が使用されていないため、接線が存在する場合に補正するものは何もないはずです。

また、シェーダーのflipYフラグを尊重することで、これを自動的に修正できる可能性があることも提案しました。 ただし、これを自動的に修正してnormalScale.y反転させるとは言いませんでした。 ユーザーの設定を変更する必要はないと思います。

いずれにせよ、その道を進む前に、この仮説を検証することが不可欠だと思います。

[Y] glTF仕様に適切に準拠しているモデルに対して、normalScale.y = -1を設定することで補正できるはずです。

正しくレンダリングされていないすべてのモデルについて説明する必要があります。

ユーザーの設定を変更する必要はないと思います。

はい、申し訳ありませんが、そのような実装の詳細を指示するつもりはありませんでした。 画面空間の接線生成の目的で、_ flipYフラグを尊重する_が数学的に何を意味するのかについて誤解がないことを確認しようとしています。

正しくレンダリングされていないすべてのモデルについて説明する必要があります。

それは潜在的に大きなセットになる可能性があるように聞こえます。 公式のテストモデルとは根本的に異なることをしているモデルが実際に存在し、それでもglTFの法線マップの有効な使用法と見なすことができる場合は、それを発見することが重要です。 テストモデルは、静的（変換されていない）ジオメトリでの法線マップの有効な使用法をカバーすることを目的としています。 特に視聴者が生成した接線ベクトルに依存している場合、他の座標系でモデルを構築し、それが有効なglTFであると主張する方法はありません。

これはこの問題と密接に関連していると思いますか？ https://github.com/KhronosGroup/glTF-Sample-Models/issues/174

@WestLangleyこれが私がこれまでに見つけたものです。 デフォルトでは、khronos-NormalTangentTest（タンジェントは含まれていません）は間違って見えます：

normalScale.y = -1に設定した場合でも、それは間違っています。

代わりにnormalScale.x = -1を設定すると、正しく見えます。

特に金色の反射板では、レンダリングが少しピクセル化されているように見えるという例外があります。 これは、画面スペースの概算、または別のバグの指標で予想されますか？

接線のない他の良いテストモデルを持っている人がいたら、私の方法で送ってください。 代表的なサンプルがあることを確認し、glTF仕様に適合しないサンプルがあるかどうかを確認したいと思います。

@elalishそのテストベッドは私には意味がありません、それは私には決して意味がありません、そしておそらくそれは決して意味がありません。 だから...私はそれを説明しようとしてあなたの助けにはなりません。

その例は難読化されすぎた私見です。 何が起こっているのかを理解するのに十分なビジュアルを提供する一貫性のあるテストケースが必要です。

ところで、以前はVertexTangentHelper （＃3511）がありましたが、これを復活させてバッファージオメトリをサポートすることができました。

@WestLangleyNormalTangentTestをより明確にする方法を知って

UV回転にもかかわらず、法線マップを2D画像として表示した場合、法線マップの画像はベクトルがどちらの方向を向いているかについて非常に一貫しています。 画像の2Dビューでは、UV座標に関係なく、すべての半球の右側の赤チャネル値が高く、すべての半球の上端の緑チャネル値が高くなっています。 これは、赤（+ X）がUV空間のテクスチャの右側を指し、緑（+ Y）がUV空間のテクスチャの上端を指すというglTF仕様に従います。 これを機能させるために、提供された接線ベクトルは必要ありません。BabylonJSやCesiumJSのように、接線ベクトルと2接線ベクトルを計算するには、一般に+ U軸が特定の三角形に対してどの方向であるかを単純な画面空間で推定するだけで十分です。もちろん、ThreeJSも同様ですが、まだ説明されていないnormalScale軸の反転がいくつかあります。

glTFがflipYフラグを使用して、UV空間でV座標を反転することには、既知の混乱点があります。これは、すでによくご存知だと思います。 これが原因不明のnormalScaleフリップに影響を与えるのではないかと長い間思っていました。

画像にも小さなベーキングエラーがあります（私のせいで、私は何年も前にSubstance Painterの新しいユーザーでした）。 特に金の半球の平らな部分にわずかな斜めの継ぎ目が見られます。 しかし、これは全体的な効果を損なうべきではありません。 ベイクのメインの丸い部分はうまくいき、3DまたはUV座標がすべての異なる方向に回転し、接線に関係なく、通常のテクスチャの2D画像全体で「上」と「右」が一定であるという効果をよく示しています。省略されています。

これは、3Dジオメトリが作成される前に法線マップテクスチャを繰り返すことを作成するアーティストにとって重要な効果です。アーティストは、テクスチャイメージを作成する前に、UV座標またはタンジェント座標にアクセスする必要がないためです。

@WestLangleyこのテストが好きなのは、これが私が見た中で最高であるという理由だけです。 私が指摘した他のテストモデルを喜んで使用します。

また、プロットが厚くなります。元のテストは両面材料です。 ＃17804のため、片面で試してみることにしました。 デフォルトではまだ間違っていますが、normalScale.y = -1：に設定すると、正しい答えが得られます。

少なくとも、doubleSidedを変更しても、前面のレンダリングに影響がないことに同意できると思いますか？

@emackey役立つ可能性のある別のテストモデルは、溶接された法線と、丸みを帯びるのではなく立方体の形になるように設計された対応する法線マップを備えた光沢のある立方体だと思います。 おそらく2つのバージョンがあり、1つは接線が提供されているものと、もう1つは接線が提供されていないものです。 残念ながら、自分でそれを行うためのオーサリングスキルが不足しています。 あなたが私たちのためにそれを作ってくれれば、私が提供できるのは多くの感謝です：pray：

@emackeyこれにご

おそらくあなたは@elalishと協力して、彼が要求するどんなglbモデルでも喜んで提供するでしょう。 それが私たちの理解に役立つことを期待しています。

@elalish以前にこれらの問題に対処しました。 ある時、私はすべてが機能しているという印象を受けました。 簡単なテストケースがある場合は、 bisectを使用して問題が発生した場所を特定できます。

溶接された法線と、丸みを帯びるのではなく立方体の形になるように設計された対応する法線マップを備えた光沢のある立方体。

完了： normal_map_flat.zip 。 Dracoチームによって作成された接線の例を取り上げ、接線属性のない追加バージョンを作成しました。

ある時、私はすべてが機能しているという印象を受けました。

モデルに接線が含まれている場合、すべてが機能する状態に達したと思います。 そうでない場合、通常は問題ありませんが、特にUVシームの周囲でいくつかのエッジケースが発生する可能性があります。 その場合、接線を追加することをユーザーにアドバイスします。 または、 https： //github.com/mrdoob/three.js/issues/11438#issuecomment -507027586で言及されているnormalScale.y *= -1フリップを復元する必要があります。頂点の接線を省略します。

@donmccurdyありがとう。 今日はこの問題に間に合わないのですが、まだ平らな立方体の側面に苦労しています。 光沢のある表面（ metallicFactor: 1, roughnessFactor: 0.1 ）を持つようにモデルを編集すると、立方体の側面の反射がかなり泳いでいるのがわかります。

私自身のテストモデルでも同じ効果が見られます。 さらに悪いことに、Substance Painterで通常のベイク処理を行う場合と、BlenderCyclesでベイク処理を行う場合では効果が異なります。 各プログラムは、それを独自のビューポートに合わせてベイクしますが、他のプログラムにロードすると、glTFが混在していなくても、完全にフラットではありません。 それは非常に近いですが、そのような平らな表面では、わずかな違いがそれをファンハウスの鏡に変え、良い方法ではありません。

SP、Blender、さまざまなWebGLエンジンで、三角形の面を横切る頂点間で法線ベクトル（またはTBN空間）を補間する方法に微妙な違いが見られると思います。 Gimpを使用してSPベイクとBlenderベイクの「違い」を実行しました。各頂点で黒（同じRGB値）になりましたが、頂点間のスペースは非常に弱い強度の渦巻く違いを示しています。

私は微妙なファンハウス効果を期待しますが、私が現在得ているものではありません（接線なしバージョン）：

接線付きバージョンは実際にはこれ以上優れているわけではないため、これが本当に有効なglTFであるかどうか疑問に思います。

@emackey @donmccurdyが提供するこれらのモデルのいずれかまたは両方が実際に有効なglTFであるかどうかを教えてくれる資格があると思いますか？ もしそうなら、私たちは大きな問題を抱えていると思います。

この特定の立方体は非常に極端な例であるため、何を言うべきか、または物理的に現実的な反射が公正な期待であるかどうかはわかりません。 法線マップは、メッシュの表面全体を変形するためではなく、隆起やへこみなどの詳細を追加するためのものです。 たまたま、接線が正しく読み取られるか生成されるかをテストするための非常に効果的な方法でした。 normalScale.y *= -1変更がそれを修正するのに決して十分ではなかったことを私は知っています。 これは、最初に保存された接線をサポートするように促した例の1つでした。

BabylonJSでも、反射はワイルドに見えます。

識別された唯一の問題がNormalTangentTestにあり、実際に正しくレンダリングされないモデルを使用しているユーザーがいない場合は、ここで変更を保留する必要がありますか？

normalScale.y *= -1乗数を復元しても問題ありませんが、問題の例がないことは、そのような極端な例を作成する必要があるというよりも、問題が軽微であることを示しているようです。

識別された唯一の問題がNormalTangentTestにあり、実際に正しくレンダリングされないモデルを使用しているユーザーがいない場合は、ここで変更を保留する必要がありますか？

訂正： https ： ます。 それはさらに調査する価値があるようですが、単純さと正気のために、おそらく今のところ呪われた立方体を放っておくべきです。 😇