Three.js: シーンルート（0,0,0）から離れている場合のSkinnedMeshバグ

ええと、あなたのデモは私のPixelでよく見えます。

iPhone SEで確認された問題—

おそらくiOSでのWebGLの精度の問題

しかし、iOSデバイスは実際にはスキニング実装のフロートテクスチャベースのコードパスを使用していますよね？ 次の適合性テストでこれを確認できますか？

https://www.khronos.org/registry/webgl/conformance-suites/1.0.3/conformance/extensions/oes-texture-float.html

iPhoneSEのそのページには5つの障害があります。 😕

プロジェクトで紹介する小さなスクリーンキャストを作成しました。
http://cornflex.org/webgl/skin-bug.mp4

アバターが0,0,0から離れすぎると、ご覧のとおり、肌が本当にバグになり始めます。
骨格と骨の詳細なプロファイリングを行いました。 ジオメトリが何らかの方法で「引き戻される」ことを除いて、すべて問題ないようです...アニメーションのルートが悪いとは思いますが、Threejsではすべて問題ないようです...

確率は、スキニングシェーダーのスケルトンとbonesTextureに明確にリンクされています。
私も精度についてですが、Mugenが言ったように、iOSデバイスはそれを簡単にサポートするはずです。

...なぜiPhoneだけで：/

私はかなり立ち往生しています...バックアップ計画としてpngシーケンスに方向を変えています... :(

これは、iphone6が十分な骨をサポートしていないことが原因である可能性があります。

私はまったく同じ問題を抱えていました。

ここで骨の制限を確認してください： https ：

そうは思いません。
skinnedmeshが0,0,0のままの場合、問題はまったくありません：/
アバターの代わりにすべてのアセットを移動することも考えています...（これは私の回避策＃2です）が、もちろん、スケルトンをデスクトップと同じように機能させたいと思います。

友人がiPhone8で同じバグを報告しました

次の適合性テストでどのような結果が得られますか？

https://www.khronos.org/registry/webgl/conformance-suites/1.0.1/conformance/misc/shader-precision-format.html

ThreeJSのソースを2日間見た後、bonesTextureが更新されたときに問題があると思います。
このテクスチャは正しく更新されていないようで、頂点を元の位置に押し戻します...しかし、もちろん間違っている可能性があります。

うーん...ここで私はいくつか失敗しました、見てください：

たぶん、問題はこれらの失敗に関連しています。 たとえば、私のPixelはすべてのテストに合格しています。

移動します。うちのトライ何かをしてみましょうWebGLCapabilitiesとの値を設定floatVertexTexturesにfalse （これはフロートテクスチャの使用を防ぐことができます）。 ビルドを作成し、このthree.jsバージョンをアプリで使用します。 何が起こるのか興味があります😊。

https://github.com/mrdoob/three.js/blob/099e4364541502fdf22fc7b1c0f54239d2ba1708/src/renderers/webgl/WebGLCapabilities.js#L105

レンダラーでfloatVertexTextures = falseを既に試しました。
肌が狂うのをやめますが、アニメーションはもうありません：/
サンプルをプッシュします。

はい、どうぞ：
http://cornflex.org/webgl/skinning-bug2.html

renderer.capabilities.floatVertexTextures = false;

=>アニメーションはもう実行されていません

ええ、私のPixelでも同じです（デスクトップは機能します）。 私たちは一律の限界に達していると思います。

最後のサンプルを作成しましたが、バグが徐々に現れています。
http://cornflex.org/webgl/skinning-bug3.html

0,0,0から始まり、前進します...数秒待ちます...肌が狂い始めます。

0,0,0ですべてがOKであるのはかなり奇妙です。 そうですね。

z：1255>まだOK
z：18870>クレイジースキン

私が言ったように、私はCPU側のすべてのスケルトンとボーンの位置を詳細にプロファイルしました。 すべての値はまったく問題ないようです。 私が持っている唯一の手がかりは、メッシュが0,0,0から遠くなると、iOSでbonesTexturesとbonesMatrixesが正しく機能しないことです。

ルートノードの安定したボーンなどの典型的な動作であるため、ボーンの位置を確認しました。

スキンシェーダーのGPU側の浮動小数点精度を確認しましたが、やはり...何も影響がないようです。

非常に奇妙なことに、SkinnedMeshをシーン内で動かしたり、これを報告したりした人は誰もいません：/

もう1つの質問：Chromeでも同じ問題がありますか？

ええ同じ確率。

精度の問題のように聞こえます。 シーンを縮小してみましたか？ （11195は11キロメートルです）。

別のオプションは、キャラクターの代わりにシーンを移動することです。 大きなシーンの一般的な解決策になる傾向があります。

また、スキニングコードはワールドスペースにあると思います。 これを調査することができます。

あなたの骨の数は67です。

私の（妻の）iphone6の最大ハードウェアボーンの制限は27です。

私が見る変形は、私のゲームで彼女の電話で見たものと同じです（そして、アニメーターにメッシュのアーミチュアを修正させる前に私が抱えていたのと同じ問題です）。 これが少なくともあなたの問題の一部ではなかったら、私は驚きます。

なぜそれは時間とともに悪化するのですか？ わからない。 他の誰かが似たようなことを言ったが、それが関連しているかどうかはわからない： https ：

私がiphone（少なくともiphone 6）で見つけたもう1つの厄介なこと：highpシェーダーの精度を使用する必要があります。mediumpとlowpは、同じ恐ろしい方法でメッシュを歪めません（電話の骨の問題と同じです）が、テクスチャは見えますアニメート中に奇妙で文字化け/ピクセル化。

テストしているデバイスのハードウェアの骨の制限は何ですか？

@mrdoob私はすでにスケールダウンを試みましたが、実際にはスキニングははるかに速く狂っています：/
0.1でスケールダウンすると、バグは10倍速く表示されます。

ここで説明するために使用したデモは、threejsの例からのものです。
私のゲームでは、スケールはそれほど大きくありませんが、バグは同じで、表示が速くなるだけです。

確かに、スキニングはワールドスペースまたはローカルスペースで行われているようですが、中心から遠くに移動するとストレッチします。 それが0,0,0で非常にうまく動作している理由です

アバターの代わりに全世界を動かすことが私の仕事です＃2。
すでに物理学とすべてを使って世界空間でランナーゲームのすべてのルーチンを開発したとき、それは悪い選択であることを認めなければなりません。 そして、z = 11000はランナーゲームとしてはそれほど遠くありません：/ ...そしてそれはただ走っている人であり、船ではありません。

ThreeJSでたくさんのゲームを作りましたが、skinnedmeshを使うのは初めてです。 このiOSのバグは本当に迷惑です。

Workaroung＃1：スプライトシートアニメーションとして6つのpngシーケンスを実行します。 次に、ワールドスペースロジックを維持できます。 締め切りはそう遠くない:(

@titansoftime妻のiPhone8にも問題が発生しています。 これはiPhone6だけに関係するものではありません。
また、最大ボーンの問題がある場合は、最初からバグがあります。 ここでは、0,0,0でバグがないことがわかります。 その場合、骨の限界は問題ではありません。 スキニングシェーダーのボーンとbonesMatrixのワールドスペース計算は、IMOです。

iPhone 8の最大ハードウェアボーンとは何ですか？

私は知らない。 そして、それがデバイスに依存しているかどうかはわかりません。

しかし、繰り返しになりますが... IMO、maxbonesの値とはまったく関係ありません。

サンプルはiphone6,8、Xで正しく機能しています... SkinnedMeshが0,0,0のままの場合のみ5 ...
https://threejs.org/examples/webgl_loader_fbx.html

maxbonesが問題だった場合、0,0,0でもスキニングがうまくいきません。

関連：

https://www.opengl.org/discussion_boards/archive/index.php/t-159613.html
https://www.opengl.org/discussion_boards/archive/index.php/t-159364.html

ユーザーzeoverlordのこのセクションを強調したいと思います：

揺れはフロートの場合にのみ自然であり、変数は数値が大きいほど精度が低下するため、精度は1.0に近いほど最高です。 これは実際には問題ではありませんが、膨大な数の行列計算を大量に実行すると、精度が大幅に低下する（つまり、ジッタが発生する）ことを意味します。 したがって、原点を中心にすべての計算を妥当な数で実行し、それを変換する必要があります

うーん、とても面白い@ Mugen87！ 漏れを見つけたようですね。

z：1255>まだOK
z：18870>クレイジースキン

エラーはあなたの側にある可能性があります。
よくある間違い：スキンモディファイヤが適切に適用されていませんでした。
エラー1：頂点が多すぎるボーンによって制御されている
エラー2：重みのない（または重みが非常に小さい）頂点。

SkinnedMeshが原点（0,0,0）に近い場合、これらのエラーに気付くことはありません。
しかし、遠くに移動すると...モバイルデバイスの精度が原因になります。
したがって、最初に行うことは、スキンモディファイヤを（今回は適切に）再設計することです。

@RemusMarページのソースを見ましたか？
私が公開した例は、ThreeJSソースからのものです。

私の説明でかなりよく言及されています;）

これを投稿する前に多くのテストを実行しました...アニメーション化されたエクスポートの手がかりを探しましたが、バグはあらゆる種類の形式（GLTF、FBX、Collada、JSONなど）で発生していることがわかりました。

問題を明らかにするために、クリーンなソースを使用して明確な例を作成しました。 スマートフォンで確認するのは非常に簡単です。

http://cornflex.org/webgl/skinning-bug.html

私が公開した例は、ThreeJSソースからのものです。

だから何？

ThreeJSのすべてのskinnedmeshの例でこれが発生したときに、エラーが私の側にどのように発生する可能性がありますか:)

あなたが言った：

エラーはあなたの側にある可能性があります。
よくある間違い：スキンモディファイヤが適切に適用されていませんでした。
エラー1：頂点が多すぎるボーンによって制御されている
エラー2：重みのない（または重みが非常に小さい）頂点。

FBXはThreeJSからのものです...そしてGLTFまたは他のフォーマットで試すことができます。 確率は同じです。

var loader = new THREE.FBXLoader（）;
loader.load（ 'https://threejs.org/examples/models/fbx/xsi_man_skinning.fbx'、OnFBXLoaded）;

@ Mugen87が手がかりを見つけました。 GPUスキンメッシュを作成した人がそれを修正できることを期待しましょう。

ThreeJSのすべてのskinnedmeshの例でこれが発生した場合、エラーが私の側にどのように発生する可能性がありますか

「エラーはあなたの側にあるかもしれません」と私は言いました。
結論：
スキンモディファイヤが適切に適用された単純なSkinnedMeshを使用します。

• 頂点ごとに最大4つのボーン
• すべての重み= 1.0000

バグを再現できるかどうかを確認してください。

怒っていますか？ :)
このバグは私の側にはあり得ません...モデル（fbx、gltf、daeなど）とコードソースはThreeJSから来ています。

@ Mugen87の投稿を読んでください。

スキンモディファイヤが適切に適用された単純なSkinnedMeshを使用します。

• 頂点ごとに最大4つのボーン
• すべての重み= 1.0000

バグを再現できるかどうかを確認してください。

今行かなければならない。
乾杯

うーん。 あなたは何人を知っていますか？ これはデスクトップでも起こっています:(

ThreeJSのサンプルメッシュは巨大（高さ100m）なので、非常に遠くに配置しました：z = 10000000
そして、見て、同じ確率：
http://cornflex.org/webgl/skinning-bug4.html

@ Mugen87によって公開されているように、これは間違いなくワールドスペースのボーンの位置とbonesMatrixの計算に関連するもの

https://www.opengl.org/discussion_boards/archive/index.php/t-159613.html
https://www.opengl.org/discussion_boards/archive/index.php/t-159364.html

前に@mrdoobに説明したように、私はすでにメッシュを縮小しようとしましたが、確率はさらに悪化します...デスクトップでも、0,0,0からそれほど遠くないバグに遭遇します。

私自身のゲーム（現実的なスケール1：1）では、バグはすでにz：100に現れています。

設計の悪いスキンメッシュを引き続き使用します...
とにかく、この主題を閉じるために、ここに1から1,000,000（100万!!!）のケーススタディがあります：
http://necromanthus.com/Test/html5/Lara_1000000.html
ステージをクリックして、Y = 0とY = 1000000を切り替えます
スイッチごとに、グローバルな照明のマイナーな変更が可能です。
したがって、スキンメッシュが適切に設計されていれば、結果は（ほぼ）完璧になります。
乾杯

今月のリリース後に調査します。

@mrdoobありがとうございます。

@RemusMarあなたはここで言われたことを無視し続けます。 スレッド全体をもう一度お読みください:)

私はあなたに実用的な例をあげましたが、あなたはまだ理解していません。
http://necromanthus.com/Test/html5/Lara_1000000.html

そして、あなたは悪い習慣について話し続けます。
次の点に注意してください。
単精度浮動小数点の桁数は7です。
それは1234,567と123456.7をカバーします
ほとんどのウェイトマップには小数点以下4桁が付属していますが、1つでも適切な結果が得られます。
このため、すべての3Dエンジンは、世界規模で最大値10,000を推奨しました。
0000.001から9999.999まで
私たちは皆、「無限」または巨大な3Dワールドを望んでいますが、それは不可能です。
あなたがしていることは、多くの観点から完全に間違っています：
ゲームデザイン、パフォーマンス、アニメーション、衝突。
あなたが今メインの絵を手に入れたことを願っています。

たぶん関連： http ：

@RemusMar
私はあなたが言ったことをよく理解しましたが、残念ながらあなたのモデルには同じ問題があります...程度は低いですが、まだそこにあります：
http://cornflex.org/webgl/skin-bug2.mp4

ソース：
http://cornflex.org/webgl/skinning-bug5.html

そして、私がz = 60000より高い位置を与えると、それは悪化します...そして100000までそれは完全に見えなくなります。

私たちは皆、「無限」または巨大な3Dワールドを望んでいますが、それは不可能です。

笑、無限の巨大な世界は欲しくない...以前ThreeJSで何度もやったように、ランナーゲームを作りたいだけです...しかし今回はアバターとしてスキンメッシュが必要です。

私のシーン： http ：

数メートルを超えるアバターをアニメーション化できない場合...それでは、ポイントは何ですか？ （現実的なスケール1m = 1 threejsユニットでは、バグはすでに100から発生しています）。

ところで、あなたのモデルは高さ150mのようなものです...これは現実的なスケールではありません。
編集：
ここでは、モデルにスケール（0.01、0.01、0.01）を使用した同じシーンを使用して、現実的なサイズ（約1.5m）にします。 ご覧のとおり、モバイルではすでにz = 300でバグが発生しています。
http://cornflex.org/webgl/skin-bug3.mp4

あなたがしていることは、多くの観点から完全に間違っています：
ゲームデザイン、パフォーマンス、アニメーション、衝突。

LOL LOL ...ゲームの作成に関する私のWebサイトとブログ（http：//quentinlengele.com、http：//cornflex.org、http：//www.ddrsa.com、http：//br9732.com）にアクセスすることをお勧めします。 ）

編集：あなたのシーンはiOSでは表示されません、空の画面（http://necromanthus.com/Test/html5/Lara_1000000.html）。

スキニングはワールドスペースまたはローカルスペースで行われているようですが、中心から遠くに移動するとストレッチします。 それが0,0,0で非常にうまく動作している理由です

どれどれ：

vec3 transformed = vec3( position );
...
#ifdef USE_SKINNING
    vec4 skinVertex = bindMatrix * vec4( transformed, 1.0 );
    vec4 skinned = vec4( 0.0 );
    skinned += boneMatX * skinVertex * skinWeight.x;
    skinned += boneMatY * skinVertex * skinWeight.y;
    skinned += boneMatZ * skinVertex * skinWeight.z;
    skinned += boneMatW * skinVertex * skinWeight.w;
    transformed = ( bindMatrixInverse * skinned ).xyz;
#endif

私には世界空間のように見えませんか？ 通常のメッシュでは、 transformedはposition属性、つまりローカル座標に設定されます。

そのため、バインドとボーンの行列が計算されるjs側で何が起こっても起こります。 おそらく、バインドマトリックスは多くのストレッチを行い、ボーンマトリックスは、バインドマトリックスでそれほどストレッチを必要としない他の座標で動作するようにドクターされる可能性があります...またはそのようなもの

（編集：nvm、私はこれが間違っていると思います）

@makc残念ながら、スキニングシェーダーのコピー/貼り付けに、計算がローカル空間座標で行われたのかワールド空間座標で行われたのかを判断するのに十分な有効なデータがありません。

私が言ったように、ボーン行列の計算には確かに何か問題があるか、これらの行列の計算の順序が正しくない可能性があります。 OpenGLフォーラムで見ることができ、 @ Mugen87が述べたように、これは少なくとも私にとって最も価値のある手がかりです。

揺れはフロートの場合にのみ自然であり、変数は数値が大きいほど精度が低下するため、精度は1.0に近いほど最高です。 これは実際には問題ではありませんが、膨大な数の行列計算を大量に実行すると、精度が大幅に低下する（つまり、ジッタが発生する）ことを意味します。 したがって、原点を中心にすべての計算を妥当な数で実行してから、それを変換する必要があります。

繰り返しますが、説明したように、オブジェクトのスケールがバグに影響を与えています。
ThreeJSソースを使用した例では、z = 100000でのみバグが発生しますが、これはメッシュのサイズ（ThreeJSソースからも取得）が大きいためです。 走っている少年の身長は150mです。

もちろん、ゲームをしているときは、そのようなスケールは使用しません。 あなたはいつもあなたの世界を1m = 1unitで維持しようとします。 これは、優れた物理学と行動を得るためにも必須です。

ここでの問題は、現実的なサイズのSkinnedMeshを使用する場合です。バグはすでにz = 300で発生しています。

どのエンジンでも、x：30000、y：60000、z：140000000にSkinnedMeshをドロップでき、ボーンとスキニングの問題はありません。 揺れはありません。

確かに、私たちはここでJavascriptコアに取り組んでいることをよく理解しています...しかしそれでも。

「私たちは皆、無限の世界を望んでいるが、それは不可能だ」と偽ってここにいるトロールは、学校に戻って行列変換を学ぶ必要があります。 または、オープンワールドのゲームをよく見て、自分のアバターをシーンのルート0,0,0から遠く離れた場所で「スキンメッシュ」する方法を自問してみてください。

私は言わなければならない、このバグは楽しいです。 ここでは、デスクトップで再現できましたが、60Kでは精度が不足するほどではありませんでした。

わかりました。z= 1e8の場合、現在のシェーダーでは次のようになります。

シェーダーをこれに変更すると、次のようになります（編集した上記の頭のてっぺんからのテストのわずかなバリエーション）：

#ifdef USE_SKINNING
    vec4 skinVertex = bindMatrix * vec4( transformed, 1.0 );
    vec4 skinned = vec4( 0.0 );
    skinned += ( bindMatrixInverse * boneMatX ) * skinVertex * skinWeight.x;
    skinned += ( bindMatrixInverse * boneMatY ) * skinVertex * skinWeight.y;
    skinned += ( bindMatrixInverse * boneMatZ ) * skinVertex * skinWeight.z;
    skinned += ( bindMatrixInverse * boneMatW ) * skinVertex * skinWeight.w;
    transformed = skinned.xyz;
#endif

まだ不安定ですが、ずっと良く見えます:)さて、これはこの問題の文脈で何を意味しますか？

まず、このハックをシェーダーにコピーして貼り付けることはできません。 つまり、可能ですが、1つの行列の乗算を4に置き換えます。代わりに、a）js側でバインド行列の逆行列と骨行列をマージし、単一のユニフォームとして渡すか、b）これのためだけに別のユニフォームを作成します。シェーダーの一部。 次に、この問題を（ある程度）解決し、シェーダーでの行列乗算の数を（1つ）減らします。

ああ、そして

「私たちは皆、無限の世界を望んでいるが、それは不可能だ」と偽ってここをトロールします

彼らが言おうとしていたのは、自分の側でライブラリを修正しなくても問題を回避できるということだと思います。 必要ではありませんが、可能です。

@makcありがとうございました。
残念ながら、それはかなり手遅れです。 私は金曜日に配達しなければなりません。 回避策としてPNGシーケンスを使用しました。

これを十分に深くデバッグしたい場合。 現実的なメッシュサイズを使用してみてください。
繰り返しになりますが、このララモデルもよく覚えていれば高さ60mくらいです。

もちろん、パッチが現実的なスケールでも機能しているかどうかを確認したいのですが:)

ああ、そして...あなたはiOSの下であなたのテストをしていますか？
このスレッドで説明されているように、これは主にiOSデバイスで発生しています（6、8）。
デスクトップでは、非常に大きな値だけが問題を引き起こします。

再度、感謝します

@OrtOfOnコードの先頭にこれを追加することで、 @ makcパッチを試すことができます。

THREE.ShaderChunk.skinning_vertex = `
#ifdef USE_SKINNING
    vec4 skinVertex = bindMatrix * vec4( transformed, 1.0 );
    vec4 skinned = vec4( 0.0 );
    skinned += ( bindMatrixInverse * boneMatX ) * skinVertex * skinWeight.x;
    skinned += ( bindMatrixInverse * boneMatY ) * skinVertex * skinWeight.y;
    skinned += ( bindMatrixInverse * boneMatZ ) * skinVertex * skinWeight.z;
    skinned += ( bindMatrixInverse * boneMatW ) * skinVertex * skinWeight.w;
    transformed = skinned.xyz;
#endif
`;

THREE.WebGLShader：シェーダーをコンパイルできませんでした。 ：/

ちょっと、あなた。 間違った引用符と1行のフォーマットになってしまいました。 そのようにどのようにコピー＆ペーストしますか？

また、好奇心を満たすこれらの奇抜な画像を見るためにやったのです。 私は他の誰かがここからそれを取ると信じています:)

@makc CTRL + C / CTRL + V ...ここから...：/

残念ながら、バグは以前ほど強力ではありませんが、まだあります:(

iOSでテスト済み（パッチが適用されています）：

スケール1.0のメッシュ（正確には高さ約20mのアバター）、位置z = 10000
http://cornflex.org/webgl/skin-patch1.mp4

スケール0.1のメッシュ（高さ約2mのアバター）、位置z = 3000
http://cornflex.org/webgl/skin-patch2.mp4

@mrdoob再現してみます:)一行で登場しました。 あなたの返事が飛び出るのを見たとき、私はページに書いていました、そしてそれはそれが正常に見えるように見えませんでした、私は約束します：p ...私はこれらのボーナスポイントを得るでしょう、あなたは見るでしょう:)

編集：ところで、あなたはあなたの投稿を編集しましたか？ :)

残りの効果はスキニングとは無関係で、実際にはすべてに影響を与える可能性があると思いますが、アニメーションがないため気づきません。

@OrtOfOnを代わりに、シーン全体（カメラを使用）を追加のObject3Dでラップし、このオブジェクト座標をフレームごとに-1 *アバター座標に設定しようとします。 これにより、それは永久に0,0,0の世界座標に保たれます。

@markc私は本当にこのようにごまかすのは好きではありません。 ゲームプレイとシーンはそのように拷問されるようには設計されておらず、モバイルファーストゲームとして、パフォーマンスはもちろん最適でなければなりません。

また...私の場合ではありませんが、SkinnedMeshのいくつかの敵がどこからでもやってくると想像してみてください...

締め切りがあり、SkinnedMeshをスプライトシートアニメーションに置き換えたため、選択の余地はありませんでした（クライアントはOKです）。 そうでなければ、私はこのような何かに遭遇することを除いてはしませんでした。 私はほとんどすべてのWebプロジェクトでThreeJSを使用しており、非常に満足しています。

「無限の世界」は必要ありませんが、有名なエンジンのように、これらの優れたSkinnedMeshとアニメーション機能を世界空間の座標で使用できるようにしたいと考えています:)

私はある意味で少しがっかりしています...クロスフェード機能に基づいてメカニムからインスピレーションを得た非常にクールなアニメータースクリプトを作成したので...次のプロジェクトのために確かに：/

@markc私は本当にこのようにごまかすのは好きではありません。

私はそれが不正行為だとはまったく思わない。 これが、すべてのスペースシミュレーションの仕組みです。 実際、リアルタイム3Dレンダリングは基本的にシーン全体をオフセットしているため、中心がカメラの位置になります。

@mrdoobええ、私はカメラさえ存在しないことを知っています。 マトリックスの力：）（私はいくつかのネイティブWebGL / OpenGL開発を自分で行います）。

とにかく、すべてのシーンをゲームオブジェクトに入れることは、私には少し野蛮なように思えます...特にスキンアニメーションを機能させるために。

@OrtOfOn実際には、シーン自体を使用できます。 たとえば、ララの例では、次のようにします。

scene.add(camera);
scene.position.z = -60000;

そしてそれは大丈夫です（編集：しかし、これを行うとライトに何か問題があります.... @ mrdoob ？）

@makcパッチを提案していただきありがとうございます。

私は悲観論者になりたくありませんが、この種の操作を行うことで問題になるのは照明だけではないということです。 結果の不確実性とパイプラインの他の部分への影響のために、私がこれらのトリックとチートと呼ぶのはそのためです。

残念ながら、ゲームを作成する人々は、物理学、レイキャスター、パーティクルなどを持っています...現実的なスケールで世界空間にあるように設計され、設計されなければならないものがたくさんあります。

また、シーンの一部の場所に隠れたりスポーンしたりする敵のように、これらのパッチが複数のSkinnedMeshで動作しているのを見るのは非常に興味があります。 それでは、0,0,0で1つのスキンメッシュアバターに制限するポイントは何ですか？

できるだけ早くソースを深く掘り下げますが、2日以内に何かを配信する必要があります...したがって、私のスプライトシートアニメーションは今のところうまくいけばうまくいきます。

それでは、0,0,0で1つのスキンメッシュアバターに制限するポイントは何ですか？

重要なのは、スキンを0,0,0でレンダリングし、別のスキンをz = 60000で同時にレンダリングする可能性は非常に低いということです。 0,0,0の周りのいくつかのスキンだけが画面に表示され、バグをトリガーするのに十分な距離ではありません。

@makc繰り返しますが、パッチはデスクトップで有効ですが、iOSデバイスでケースをテストしていません。この場合、バグは、現実的なスケーリングされたメッシュで0,0,0から数メートルのところにすでに現れています。 私はそれに十分なビデオを見せました。 これは、たとえば、z = 100でのみバグを示します：/
http://cornflex.org/webgl/skin-bug.mp4

ゲームでは常に高さ20mのアバターを使用していますか？ :)
焦点を当てた数値（60000）は、デスクトップ（非常に巨大なlaraまたは巨大なthreejs fbxサンプル）でバグを公開するためにのみ使用されるため、モバイルでは使用されません。 そして、私のアバターはもちろんそれほど遠くには行きません...

これはiOSの問題であることを確認します。 少なくとも第6S / 6S +世代以来、iOSはfloatVertexTexturesに問題を抱えています。 私たちが使用している修正は、iOSでその機能を無効にすることです。 これは私たちが使用できる骨を制限しますが、とにかくもっとくだらない電話をサポートするためにそれらを制限しなければなりません。

iOSデバイスは@ Mugen87によって投稿された適合性テストに失敗するため、iOSでfloatVertexTextures、またはおそらくfloatFragmentTexturesをデフォルトで無効にすることをお勧めします。これは、サポートするようにアドバタイズする機能を明らかに正しく実装していないためです。

@ daniel-nthそれは理にかなっていると思います。 しかし... @ OrtOfOnはz = 60Kがデスクトップで問題を再現すると言っていました...デスクトップで60Kで問題はありません、私が「再現」するには1e8だけで十分でした。 したがって、この問題は実際には少なくとも3つの個別の問題である可能性があります。

• iOSのフロートテクスチャ、
• @OrtOfOnのデスクトップに60Kの何か、
• ボーンシェーダービット（上記で混乱したもの）の行列の乗算順序が悪いため、1e8で精度が不足しています。
• パッチの後、女の子はまだ少し震えていたので、頂点シェーダーに何か他のものがあるかもしれません。

こんにちは、みんな、
まず、このバグに戻っていただきありがとうございます。 私はまだそれを掘り下げる時間が見つかりませんでした:(

@ daniel-nthオブジェクトのスケールがバグに影響を与えています：

iOSでは、この非常に巨大な「Lara」オブジェクト（height = 120、scale = 1）を使用すると、バグは実際にz = 60000で発生します。 ただし、現実的なサイズのメッシュ（height = 1.8、scale = 1）を使用すると、すでにz = 100でのみ表示されます。

skinnedmeshが大きいほど、バグを確認するためにさらに変換する必要があります。

このスレッドですでにテストおよび報告されているように、iOSでfloatTexturesを無効にすると、スキニングはまったく発生しません。

また、骨行列の行列の乗算または乗算のバーの順序が悪いと思われます。

iOSでは、この非常に巨大な「Lara」オブジェクト（height = 120、scale = 1）を使用すると、バグはz = 60000に表示されます。

@OrtOfOn待って、

焦点を当てた数値（60000）は、デスクトップでバグを公開するためにのみ使用されます（非常に巨大なlaraまたは巨大なthreejs fbxサンプルを使用）...モバイルでは使用されません。

iOSでは、この非常に巨大な「Lara」オブジェクト（height = 120、scale = 1）を使用すると、バグは実際にz = 60000で発生します。

それほど大きくはありません。
そして、あなたはまだモデルサイズと世界規模の関係を理解し​​ていません。
最後に：
http://necromanthus.com/Test/html5/Lara_1000000.html
モデルの高さは約= 75、ワールドスケールは9,999,999です。
Z = 0からZ = 1,000,000まで（100万!!!）
単精度浮動小数点の桁数は7であるため、小数点はまったく残っていません!!!
それは私が持っているすべてのラップトップとデスクトップで完璧に動作します。
さらに：
Android 6＆7およびさまざまなSamsung携帯電話で完璧に動作します。

あなたの例では@RemusMar 、これをコンソールに入力してください：

camera.position.z += 1e8;
scene.children[2].position.z += 1e8;

次のようなものが表示されます。

トリッピーです

z = 1e6も悪くはないことをお伝えします。 1e7あたりはすでに目立ち、1e8はただクレイジーです

@ OrtOfOncapabilities.floatVertexTexturesをfalseに設定すると、iOSで機能します。 あなたのモデルは、ユニフォームにフィットするために多くの骨を使用していると思います。

z = 1e6も悪くはないことをお伝えします。 1e7あたりはすでに目立ち、1e8はただクレイジーです

私は知っていますが、それらの値についてはあなたは正確ではありません。
スキンメッシュの頂点の重みの精度の場合、最大ワールドサイズは9.999.999です。
これは、最大距離が数百万に達することを意味します。
乾杯

@makc確かに、デスクトップの番号が間違っていました。 それは非常に巨大でなければなりません、あなたは正しいです、そして私は実際に前のスレッドで言及しました：/ https://github.com/mrdoob/three.js/issues/13288#issuecomment -364650679

@ daniel-nth知っておくと良いのですが、よろしいですか？ これが、このスレッドで、threejsソースからの3Dモデルを使用して行ったテストです。 あなたはまだコードを見ることができます。 @ Mugen87も同じフィードバックを行いましたが、このモデルではアニメーションはありません。 https://github.com/mrdoob/three.js/issues/13288#issuecomment -364572653

ああ、モデルはもう存在しないようです。 https://threejs.org/examples/models/fbx/xsi_man_skinning.fbxの404

@ daniel-nth骨の少ない新しいモデルを使用している場合は、私はあなたを信じています;）

@RemusMar最新の投稿で引き起こされた距離について、かなり同意しました。 数値（1e6、1e8、1e9、...）は確かに精度が悪くなります。 それについては疑いがない。 しかし、私を荒らしするのをやめてください。 何もわからないふりをやめて、高さ120のアバターメッシュが大きくないかどうか自問してみてください。 私にとって、それは非常に巨大で、アーティスト、レイキャスト、物理学、照明などによって作成された他の現実的なスケーリングされたオブジェクトを使用したgamedevではあまり使用できず、3週間で配信されます。

私が主張しているのは、資産をメートル単位で現実的なスケールに保つことは、物理ベースのゲームを正しく構築するために必須のことです:)

残念ながら、iOSでは、これらの現実的なスケール条件では100mを超えてアバターを実行できません：/

更新：とにかく、@ daniel-nthは、floatTexturesをオフにして、ボーン数が非常に限られていることを示しているようです。

しかし、私を荒らしするのをやめてください
私が主張しているのは、資産をメートル単位で現実的なスケールに保つことは、物理ベースのゲームを正しく構築するために必須のことです:)

私はあなたを荒らしていません。
しかし、1.5単位は1.5メートルを意味するものではありません
乾杯

@OrtOfOn

私が主張しているのは、資産をメートル単位で現実的なスケールに保つことは、物理ベースのゲームを正しく構築するために必須のことです:)

しかし、このスケールは任意の自主的な値です。 センチメートルを使用することもできますが、「高さ120のアバターメッシュ」は実際には平均よりも小さくなっています。

@makcもちろんですが、物理エンジン/ライブラリはメトリック値を使用することを想定しています。 スケーリングされたオブジェクトまたは非メートル値を使用して、すでにいくつかの物理演算を実行しようとしましたか？ 開発はすぐにひどくなり、予期しない非現実的な結果が得られます。 あなたのすべての力も見直され、拡大縮小されなければなりません。 動作しますが、正確ではありません。

もちろん、達成する必要のある精度のレベルによって異なり、1e6、1e7、...のような値は大きすぎて、精度の問題が発生します。 また、スキンメッシュをそれほど遠くまで移動する必要はありません。 私たちはそれについて同意しました。 ただし、iOSでは、少なくとも数百ユニットの範囲でgpuスキンメッシュ（高さ1.5ユニット）を移動できるはずです。

ただし、物理エンジン/ライブラリでは、メトリック値を使用する必要があります。

それは真実ではない。
メートル、センチメートル、インチなどは関係ありません。
前に（数回）言ったように、重要なのは世界のサイズ（スケール）と精度だけです。
次の点に注意してください。
高さ= 1.5単位のスキンメッシュがある場合、頂点の重みマップによって、少なくとも小数点以下2〜3を使用するように強制されます。
物理エンジン（存在する場合）の場合、許容できる結果を得るには、小数点以下3〜4桁が必要になる場合があります。
グローバル精度に小数点以下4桁が必要な場合、最大ワールドサイズは999です（単精度浮動小数点の桁数が7であるため）。
言い換えれば、まともなアニメーションとまともな物理学が必要な場合は、数百の距離を使用できます。
今回は全体像を把握していただければ幸いです。
乾杯

@RemusMarここでやめます。 iOSデバイスでケースをテストしたくない、またはテストしたくないようです。 これらのデバイスでは、GPUスキンメッシュを使用して「数百の距離」を使用することはできません。 メッシュはすぐに狂ってしまいます。 それがこのスレッドのポイントであり、私は最初にそれを報告したかっただけです。 以上です。

ここにいる他の人や私の画面キャプチャによって報告されているように、すべての提案とサンプルがiOSデバイスで機能しないという事実を知っていただければ幸いです：/

これらのデバイスでは、GPUスキンメッシュを使用して「数百の距離」を使用することはできません。

あなたはまた間違っています。
上のスクリーンショットを参照してください（Android 7-Samsung携帯電話）。
モデルの高さ= 75（バウンディング球の半径約38）および距離1,000,000（100万!!!）
または、モデルの高さ= 1.5および距離20,000。

ps
iOSが常にバグの集まりであったことは私の問題ではありません。

@RemusMar私は間違っていません、あなたは

あなたがAppleをそんなに嫌いなら、私の確率ではない。 私のクライアントの1人がThreeJSで3DWebベースのゲームをやりたいと思っているとき、私は彼に「あなたのiPhoneであなたをファックする」とは言いません...あなたがそうするなら、ごめんなさい。

ここで送信の終わり...私はもうこれに従うことができません。

@OrtOfOnはい、使用したモデルには19個のボーンがあり、

https://github.com/mrdoob/three.js/issues/13288#issuecomment -364550036には、均一な骨の制限を示すページへのリンクがありました。 ページが使用する式はMath.floor((data.webgl.params.MAX_VERTEX_UNIFORM_VECTORS - 20) / 4);です。three.jsで100％正確かどうかはわかりませんが、iPhone Xでも27と報告されます。これは、残念ながらGalaxy S3の半分未満ですが、モバイルWebGLゲーム。 私はすぐに自分の作業フォルダーを調べましたが、26のWebGLプロジェクトでは、1つだけがより多くのボーンを持つモデルを持っており、そのモデルは0,0,0のままです。

@OrtOfOn ：固定シーンで同様の問題が発生し、スキンされたキャラクターがシーン内で移動します。 キャラクターはiOSでひどく揺れます。 骨の数は22です。シーンの寸法は妥当です。 問題は、頂点テクスチャを使用すると32ビットのフロートに制限されることと、Threejsがワールドスペースでスキニングを計算するという上記のアサーションと相まって、問題があると思います。

私は現在、ワールドスペースアサーションを調べています。うまくいけば、ローカルスペースの頂点位置を計算し、オブジェクトを変換する適切な方法を実装する予定です。 スキニングを使用してオブジェクトをワールド空間に配置する人のことは聞いたことがないので、実装者がなぜそのようなことをしたのかわかりません。

解決策が見つかったら投稿します。

ただfyi、iosのfloatテクスチャは頂点シェーダーで壊れているだけではありません。 私は最近、フロートテクスチャを整数テクスチャに変更してiOSのカラーバンディングを修正していたので、これはiOSの普遍的な問題です。 本当に必要な場合は、整数テクスチャを使用してiosのボーンを修正することもできます。これは、他の誰かのシェーダーからの関連スニペットです。

vec2 encodeFloatRG( float v )
{
    vec2 kEncodeMul = vec2(1.0, 255.0);
    float kEncodeBit = 1.0/255.0;
    vec2 enc = kEncodeMul * v;
    enc = fract (enc);
    enc.x -= enc.y * kEncodeBit;
    return enc;
}

float decodeRGFloat( vec2 enc )
{
    vec2 kDecodeDot = vec2(1.0, 1.0/255.0);
    return dot( enc, kDecodeDot );
}

...実際、ios精度をグローバル精度制限として受け入れ、1つではなく2つのfloatをテクスチャに格納すれば、おそらく（ここでは、そのようなことを実際には試していませんでしたが）フロートボーンテクスチャも機能させることができます。

私は、threejsにローカル空間（それが属する場所）でスキニング計算を実行させ、モデルを世界空間マトリックスを介して標準的な方法で実世界の座標に変換することで、この問題を完全に解決しました。

上記の問題は、iOSでのスキニングで完全に修正されています。 また、このソリューションは普遍的であり、テストしたAndroidデバイスだけでなくすべてのデスクトップブラウザーでも問題なく機能することも指摘しておく必要があります。 ほとんどすべての場合、IMHOローカルスペーススキニングが正しい方法であり、この方法がThreeJSのデフォルトである必要があります。 @mrdoob ：これについてどう思いますか？

mesh = new THREE.SkinnedMesh(geo.geometry, mat);
mesh.bindMode = 'detached';
var skel = new THREE.Skeleton(bones, boneInvs);
var bsm = new THREE.Matrix4().fromArray(geoPrims.bsm);
mesh.bind(skel, bsm);

// make bsmInv identity for models that have multiple skins
mesh.bindMatrixInverse = new THREE.Matrix4();

// patch SkinnedMesh's updateMtxWorld:
// we're using local skinning, so don't keep resetting binMatrixInverse (leave identity)
// the reason we're using .bind here is for models that have more than one skin
mesh.updateMatrixWorld = PatchSkinnedMeshUpdateMW.bind(mesh);

// re-normalize since input data has been compressed
mesh.normalizeSkinWeights();

// remove bone roots and add to bone root list
for (var bi = 0, bl = bones.length ; bi < bl ; bi++) {
    if (bones[bi].parent && !bones[bi].parent.isBone) {
        bones[bi].parent.remove(bones[bi]);
        boneRoots.push(bones[bi]);
    }
}

'boneRoots'をルートシーンオブジェクトに追加する必要がある場所（したがって、マトリックスの更新を取得しますが、実際のスキンメッシュに至るまでの階層内のすべてのマトリックスを継承しません）。 これらのboneRootsをシーンルートに追加します（コードは表示されていません）。

そして、これがthreeJSのSkinnedMesh実装を置き換えるパッチです（threejsのupdatematrixworldは、IDとして保持したいbindMatrixInverseを覆い隠すため、これが必要なだけです）。 または、パッチ関数を使用する代わりに、THREE.Mesh..prototype.UpdateMatrixWorldに直接バインドすることもできます。

function PatchSkinnedMeshUpdateMW( force ) {
    THREE.Mesh.prototype.updateMatrixWorld.call( this, force );
}

@ denbo-ftそれは私にはいいですね。 そのためのPRを作成しますか？

@ denbo-ftお疲れ様でした。 返信が遅くなってすみません、私はもうこのスレッドをフォローしていませんでした。

私たちの製品にもこの問題があります-どのブラウザ（0,0,0から十分に離れている場合）ですが、iOSでは約2〜3ユニット離れるとすぐに発生するためより顕著になります。 私たちにとって重要ですが、少なくともこれを見ると大笑いします

わかりました、これを必要とする人がもっといるようです。 私はgithubオープンソースプロジェクトに貢献したことはありませんが、gitに精通しており、PRを作成しようとしています。 :)

こっちも一緒。 私のSkinnedMeshは、iPhoneのプロセラピストであるカッツ博士のエピソードのように見えます。

参考までに、5月21日の私の投稿には完全な解決策があります。 ThreeJSソースの修正はそれほど多くありません。修正のほとんどは、個々のプロジェクトのローダーやシーンセットアップコードに含まれています。

基本的な修正は、モード「デタッチ」（文書化されていない、ところで）を使用し、ボーン階層をルートシーンレベルでシーンに配置することです-実際のレンダリング可能な文字階層では配置されません。 次に、エンジンから1つの簡単なもの（SkinnedMesh.update）にパッチを適用すると、準備が整います。

編集：
TJS用の完全にカスタムのファイル形式とローダーがあるので、残念ながら、サンプルソリューションで完全なPRを作成するには、提供されている缶詰ローダーの1つ（Colladaなど）を修正する必要があります。 私は今これを行うことを検討します

おかげで、私はあなたのソリューションをより一般的な方法で理解し、適用するために時間を割くつもりでした（あなたはあなたのプロジェクトに少し固有のようでした）。 コードのコンテキストをもう少し共有できますか？

カッツ博士、プロのセラピスト

私は夢中になっているわけではありませんが、いまいましいです。

編集：

プルリクエストを正常に作成しました。他にできることがあればお知らせください。

元の投稿：

変更を加えたローカルブランチがありますが、元に戻すことができないようです。 github credsを提供しても、次のエラーが発生します。

https://github.com/mrdoob/three.js.gitにプッシュする
リモート：mrdoob /three.js.gitへのアクセスがdenbo-ftに対して拒否されました。
致命的：アクセスできません ' https://github.com/mrdoob/three.js.git/ '：要求されたURLがエラーを返しました：403

これはgithubへの私の最初の貢献なので、いくつかのアドバイスが欲しいです。 ありがとう！

参考までに、PRがmrdoobで機能し、統合されている場合、この変更をサポートする新しいバインドモード「ローカル」があります。 文書化されていない「デタッチ」バインドモードにパッチを適用したり変更したりしたくありませんでした。誰が、何が使用しているかがわからず、知らないことを壊したくなかったからです。 しかし、それはこの目的のために意図されたのかもしれないように私には思えます。

binMode = "local"は、更新中にbindMatrixInverseを変更しません。これは、IDのままにする代わりに、bindMatrixの逆にリセットする「detached」とは異なります。

このPRのwebgl_loader_collada_skinning.htmlの例を参照して、シーン内を移動するキャラクターに適切なローカルスキニングを取得するために、シーンレベルで必要ないくつかの変更を確認してください。

この修正をテストするために、ストームトルーパーDAEローダーのデモが使用されました。 これらのテストでは、キャラクターは原点から2000ユニット離れた場所に移動されました。 以下のスクリーンショット。

以下のショットはiPhoneX / Safari11からのものです

この変更前（2000、2000、2000）：

この変更後：

ルートシーンレベルと（0,0,0）にボーンがなくても、これを実現する方法があると思いますか？ ボーンを使ってアバターに物を付けたり、ポイントを見させたりしています。そして、私だけではないと思います。

2つのオプションがあります。

1）threejsで実装されているように、ローカルスキニングの恩恵を受けるために、ルートのワールドスペースにボーンを保持します。 次に、たとえば、アバタースペースに武器を入れるために、武器をボーンにアタッチする必要がある場合は、追加の変換を行います。

2）ボーンをアバタースペースにそのまま残し、iOSでワープします。

私は間違いなく＃1をします。 ボーンの位置とキャラクターの位置がすでにある場合は、いつでも計算を行って、アタッチ可能なオブジェクトが任意のフレームのどこにあるべきかを判断できます。 ただし、ワープはiOSデバイスのHALレベルでのパッキングによって引き起こされ、それに対してできることは何もないため、＃2の回避策はありません。 確かに、上記のさまざまなHalfWordパッキングなどを使用してハックを追加することはできますが、それらはすべて問題を軽減し、解決するものではありません。 ローカル空間でスキニングを行うと、iosのスキニングの問題は完全に解消されます（より具体的には、ボーンを世界の原点を中心に保ち、数値をできるだけ小さくします）。 次に、添付ファイル用の文字スペースにxformします。

より詳しい情報：

TJSでの実装方法の問題は、特にTJSではありませんが、シェーダープログラムごとのユニフォームの数に上限があることによるボーン制限の問題を解決するために、BoneTexturesが使用されています。 これはかなり標準的な解決策です。 ただし、iOSでは、テクスチャのフロートが32ビットよりも小さいものに量子化（パック/圧縮）されています。 これは、数字のサイズ/大きさが「大きい」、つまり数百を超える場合に、文字の「カマキリ」またはその他の奇抜な効果を引き起こします。

わかりました、今何をしますか？ さて、あなたのゲームのすべての大きな機能（実際にはゲームエンジン）は、通常、実践の基準を必要とします。 例：アーティストに、キャラクターの原点を中心に配置するように指示します。 キャラクターのルートノードを足/地面に配置し、特定の方法でボーンとスキンを作成します。 次に、プロセスルールを認識しているエクスポーター（またはTJSの場合はインポーター）とインポーターを作成します。 次に、この構成を持つアセットをロードするときに、エンジンの最終機能をサポートします。 これが私たちがゲーム業界で物事を行う方法です。

ゲームのすべての機能を完全に処理するために、あらゆるオーサリング方法、あらゆるファイル形式、およびあらゆる汎用ローダーを期待することは、管理不可能で不確定です（ゲーム開発にとってはひどいことです）。 途中でいくつかの標準とプロセスが必要です。

キャラクターがスキニングを使用していて、武器などにジオをアタッチする必要がある場合は、エンジンがスキニングするために何が必要かを考えてから、それを使用してください。 例として、そのようなソリューションの1つを提供しました。 残念ながら、何らかの理由でローダーを変更したくないため、PRは受け入れられませんでした。 とにかく、私が提出したPRだけでなく、上記のスレッドで問題と解決策を説明したことを願っています。

私はこれまで私がすでに持っている以上に本当に貢献することはできません。 私は何人かの人々を助けたことを願っています...

幸運を！

ローカルスペースでスキニングを行うと、iOSのスキニングの問題は完全に解消されます

最初から言ったように、これはiOSの制限（バグ）の回避策であり、そのために処理能力を浪費する必要があります。
それは解決策ではありません！
実際の解決策は、iOSの浮動小数点精度を上げることです（通常の7桁の値に）。
http://davenewson.com/posts/2013/unity-coordinates-and-scales.html

@ denbo-ft私は実際にあなたのPRを実装しました（私たちは私たち自身のローダーを持っています）ので、あなたの貢献に感謝します、それは感謝されました。 シーンに複数のアバターがあり、それらが動き回ったり、アイテムをつかんだり、相互作用したりするため、別のアプローチを望んでいました。スケルトンが0,0,0の場合、多くのものを変更する必要があります。コード、新しい問題が発生するリスクなど。

私はこの問題について考えることに時間を費やしましたが、より良い解決策を思いつきませんでした。 （まだやっています）

@RemusMar

本当の解決策は、iOSで浮動小数点の精度を上げることです

誰かが最初に@grorgとcoに、そこでフローティングテクスチャをどのように処理するのかを尋ねる必要がありますが、どうしてそのようになるのでしょうか。 それは単なるバグではなく、他の問題に対するアップルの「解決策」だと感じているからです。

それは単なるバグではなく、他の問題に対するアップルの「解決策」だと感じています。

おそらく本当です。
Firefox Androidの問題と同様：バグが報告され、開発者によって検証されましたが、過去5か月（2リリース）では修正されていません！？！

これが最近のソフトウェア開発の仕組みです。
適切な場所で修正する代わりに、サードパーティに回避策があります。
最終結果：バグ、無駄なリソース、ブロートウェアのコレクション!!!

@jfcampos
ボーンの階層をルートに保持し、アバターの実際の位置マトリックスのmartixWorldを掛けて、ボーンの最終的なWS位置を取得する関数を追加することをお勧めします。 それは非常にシンプルで、修正前に持っていたものを返します。

または、チョップがある場合は、元のメソッド（バグあり）に戻り、ローカルマトリックスをボーンテクスチャに含めて、テクスチャの使用量を2倍にし、シェーダーフラグメントを変更して、スキニング中にgpuで追加の計算を行うことができます。 。 このソリューションは、コードの観点からは「よりクリーン」ですが、フレームごとにGPUにアップロードされるテクスチャの量を2倍（場合によっては4倍）にするため、上記の提案よりも効率が大幅に低下することに注意してください。 しかし、私が気付いていない理由が何であれ、後者の方法で行う方が有益な場合があります。

以前は解決策がなかったものから、すべてのデバイスと互換性のあるいくつかのオプションがここにあります。これは、ほとんどのプロジェクトにとって明らかな要件です。

0,0,0のボーンを使用して、他のものに対していくつかの追加の行列計算を実行する必要があるようです。 ありがとう！

@ denbo-ftは正しいです。 これは、ワールドスペースでのスキニングによって引き起こされるthree.jsの問題です。

参考までに、ここでworld-space-skinningへの変更が行われました： https ：