Three.js: 両面マテリアルを持つメッシュの一部で法線が反転しました

@pushmatrixこのモデルが独自の接線を提供するかどうかを確認できますか？ これが＃11438に関連しているのではないかと思います。

私はそれがそれ自身の接線を指定するとは思わない

別のテストケースを使用して、git bisectは、メッシュが両面で負のスケールXを持っている場合に問題を開始したPRとして＃17586を指します。ただし、これはr.108ではなくr.109にありました。

このPRのモデルは利用できないため、これはテストされていません。

これがテストGLBです
Wheels.glb.zip

3年前から： https ：

基本的には... gl_FrontFaceがAdrenoGPUの両面マテリアルで正しく機能していないようです。

これは私たちが対応する必要がある問題ですか？

//

normalmap_pars_fragment Adrenoの回避策を削除すると、このモデルは私のマシンで正しくレンダリングされるように見えます。

#ifdef DOUBLE_SIDED

    // Workaround for Adreno GPUs gl_FrontFacing bug. See #15850 and #10331

    bool frontFacing = dot( cross( S, T ), N ) > 0.0;

    mapN.xy *= ( float( frontFacing ) * 2.0 - 1.0 );

#else

    mapN.xy *= ( float( gl_FrontFacing ) * 2.0 - 1.0 );

#endif

うーん、そのコメントも読んだことを覚えています。 私はこのバグを見ているときに遭遇したと思います。これは明らかにr108で修正されました（少なくともアップグレードすると修正されました）： https ：

多分それは関連していますか？ FWIW、私は古いAdreno GPUについていくつかのフィードバックを得たので、明らかにそれらはまだかなり一般的です。

確認のために、これはまだdevます：

確認のために、これはまだdevで発生します：

正しい。 ただし、Adrenoのバグ回避策を削除した場合はそうではありません。

ただし、Adrenoのバグ回避策を削除した場合はそうではありません。

今のところ回避策を削除してから、別の解決策を探すのはどうですか？ 現在の実装では、使用しているプラ​​ットフォームに関係なく、誤ったビジュアルが発生します。

@ Mugen87この特定のケースでは、ジオメトリは互いにミラーであると思いますが、それらは同じ法線マップを共有しています。

仰るとおりです。 私は、すべてのユースケースで正しいAdreno互換の回避策を見つけるために何時間も費やしてきました。

ホイールモデルモデルを調べると、各ホイールには独自のUVシェルがあります。 共有していません。
そして、頂点の順序は逆です。

ただし、少なくともBlenderでは、顔の向きは同じです。

そのため、それがr108のバグなのか、それともr108が正常に動作しているかどうかはわかりません。 ¯_（ツ）_ /¯

@pushmatrixはUnityやBlenderと比較できますか？

@mrdoob

Blender 2.8

Unity

Sketchfab

@pushmatrix

光がカメラと同じ方向にあるため、Unityは見づらいですが、Unityも間違っているように見えますか？ 🤔

@mrdoob

ええ、それは照明に少し依存しますが、それは幻想であり、いくつかの場所でポップアップしたように見えます。 しかし、回転すると消えます。

ここでそれは別の観点から見て、正しいように見えます

@mrdoob前面は、three.jsで反時計回りに巻かれています。 通常、各面の3つの頂点のUVも、UVマップ上で反時計回りに巻かれています。

この例では、私の_予想_は左側のモデルに反時計回りのUVがあり、右側のモデルには_時計回りの_UVがあります。 doubleSideがtrue場合、右のモデルはthree.jsで正しくレンダリングされません。

AFAIK、Adrenoの回避策を削除すると、Adreno以外のGPUの問題が修正されます。

@pushmatrix Unityの例には、2つの方向からの指向性ライトがあるように見えます。 そのため、何が起こっているのかを識別するのが難しくなります。 単一のライトが好ましい場合があります。

@WestLangleyモデルビューアが使用しているのと同じ環境マップを使用していますが、同じ回転がない可能性があります。 シングルライトで試してみます。

@WestLangley一方向ライトが回転します。 目の錯覚を見ているような気がします

Unityは、光がどのように当たるかに応じて溝を出し入れするように見えますが、少なくとも両方で一貫しています。

Threejsも一貫していますが、間違いなく常に飛び出しているように見えます。

Unityのものに何か問題があるように感じます...
のようなものが必要です。 material.normalMapScale.x = -1 。

@WestLangley

@mrdoob前面は、three.jsで反時計回りに巻かれています。 通常、各面の3つの頂点のUVも、UVマップ上で反時計回りに巻かれています。

この例では、私の_予想_は左側のモデルに反時計回りのUVがあり、右側のモデルには_時計回りの_UVがあります。 doubleSideがtrue場合、右のモデルはthree.jsで正しくレンダリングされません。

AFAIK、Adrenoの回避策を削除すると、Adreno以外のGPUの問題が修正されます。

ありがとう、それは理にかなっています。 しかし、それでもさらに調査する価値があると思います。 Sketchfabがすべてのデバイスで正しく見える場合は、シェーダーを確認する必要があります。

今日、それぞれのシェーダーコードを確認しましたが、「ピクセルごとの接空間法線マッピング」を使用していないようです。

この投稿によると、Sketchfabはアセットの接線定義を期待しているか、これらのデータは
UV座標に基づいて生成します。 これは、GLSLコードで見たものに対応しています。

BufferGeometryUtils.computeTangents()を介してモデルに接線を追加し、 Material.vertexTangentsをtrueと、結果は正常に見えます。

ところで：この投稿でSketchfabのコードスニペットを共有しても大丈夫ですか^^？ 結局のところ、それはオープンソースではありません。

一貫性を保つために、1つの指向性ライトが前後に移動するSketchfabを次に示します。

覚えておくべきことの1つは、Sketchfabはモデルをアップロードするときに処理を実行するため、生成したり変更したりする可能性が非常に高いことです。 表示しているのはglTFではなく、独自の形式に変換されたglTFファイルです。

@ pushmatrix ＃17958がモデルで機能することを_

three.jsは、フラグメントシェーダーでタンジェントを計算します。 特定のバグのあるAdrenoGPUに対応するためのハックが削除されれば、正しく機能すると思います。 ＃17958を参照してください。

//

Sketchfabは、接線が必要でモデルによって提供されていない場合に、CPUで接線を計算します。 （ @donmccurdyこれはglTF仕様に必要なものです。）

three.jsもそれを行うことができますが、それはすべての組み込みジオメトリに正しい接線を追加することを意味します。 three.jsは、 ComputeTangents()を置き換えるためにMIKKTSpaceアルゴリズムも実装する必要があります。 three.jsはインデックス付きとインデックスなしの両方のジオメトリをサポートしているため、これにはかなりの労力が必要になると思います。

それを修正します！

さて、ここでの解決策は、Adrenoの回避策（＃17958）を元に戻し、モデルに接線がなく、Adreno GPUのサポートを目指している場合（＃15850）にBufferGeometryUtils.computeTangents()を使用することを推奨することです。 。

いいですね？

別の解決策は、提供されていないときにエンジンでBufferGeometryUtils.computeTangents()を自動的に呼び出し、フラグメントシェーダーでタンジェントを計算するすべてのコードを削除することです...🤔

BufferGeometryUtils.computeTangents()現在インデックスを必要としているため、コアで使用することはできません。 ただし、 three.jsがある時点でMIKKTSpaceに従って接線を生成し、 perturbNormal2Arb()削除できるとよいと思います。

@WestLangleyは書いた：

これは、すべての組み込みジオメトリに正しい接線を追加することを意味します。

考えを変える...接線は必ずしも必要ではありません。 代わりに、メソッドBufferGeometry.computeTangents()を復元し、解析的に正確な接線を設定できるすべての組み込みジオメトリに対してそのメソッドを「オーバーライド」します。

//

別の解決策は、提供されていない場合にエンジンでBufferGeometryUtils.computeTangents（）を自動的に呼び出し、フラグメントシェーダーでタンジェントを計算するすべてのコードを削除することです...

それは私には正しいように聞こえます。

BufferGeometryUtils.computeTangents（）は現在インデックスを必要としているため、コアで使用することはできません。

簡単に直せると思います。 また、 https： //github.com/mrdoob/three.js/issues/17804#issuecomment-557135610をサポートするように修正する必要があり

three.jsがある時点でMIKKTSpaceに従って接線を生成し、perturbNormal2Arb（）を削除できれば望ましいでしょう。

MikkTSpaceがフラグメントシェーダーの計算を必ずしも置き換える必要があるかどうかはわかりません。 シェーダーにはパフォーマンスコストがほとんどなく、ほとんどのモデルで正常に機能します。 接線の事前計算には、毎回頂点ごとの初期費用がかかり、これらの特定の場合を除いて利点はありません。 😕glTF仕様に記載されていることにもかかわらず、デフォルトでそれを行うことを正当化するのに苦労しています。

BufferGeometryUtils.computeTangentsがMikkTSpaceアプローチを実装できれば、それは素晴らしいことです。これは、事前に計算する必要がある場合に最適なアルゴリズムです。 ただし、既存のネイティブ実装を使用できるglTF-PipelineやgltfpackなどのツールにMikkTSpaceを配置し、事前にオフラインで計算を行う方がおそらく簡単です。

@donmccurdy

しかし、たとえば... <model-viewer>ユースケースでは、ユーザーがAdreno GPUを使用しているかどうかを知るための信頼できる方法はないと思いますが、正しく調べたいと思います（https：// github。 com / GoogleWebComponents / model-viewer / issues / 740）。

接線が提供されていない場合、 <model-viewer> （およびx-gpuサポートが必要な他のプロジェクト）はBufferGeometryUtils.computeTangents呼び出す必要がありますか、それとも3つですか？

@pushmatrix

ハハ、私はこれらのホイールがどこから来たのか気づきました😁

https://bumbleride.com/products/era?variant=20719969599599

@ mrdoob🕵

それでは、今のところ回避策を元に戻しましょう。