Three.js: Utils：非推奨のエクスポーター（Blender、3DS Max、Maya）

+ 1-これは、エクスポータが存在することは、特に

注：公式のGLTF Blenderエクスポーター（https://github.com/KhronosGroup/glTF-Blender-Exporter）は現在、適切なアニメーションのエクスポートを許可していません（現在、オブジェクトごとに1つのアニメーションのみがサポートされています）。
https://github.com/KhronosGroup/glTF-Blender-Exporter/issues/112

@Usnulこれはこのリポジトリの

@looeee
BlenderJSONエクスポーターはアニメーションをうまくエクスポートします。 GLTFエクスポーターには存在しない特定の条件でのUVまたは頂点法線の奇妙なグリッチがいくつかありますが、それは別の話です。

OK、私はBlenderを使用していないので、それについてはこれ以上コメントしません。

ただし、経験から言えば、数年更新されていない3DS Maxエクスポーターを使用しようとすることは、際限のない頭痛の種であり、FBX形式を優先してリポジトリから削除することを強く支持します。
3DS Max FBXエクスポータによってエクスポートされたほぼすべてがFBXLoaderによってサポートされるようになり、そのエクスポータはAutoDeskによって管理されているため、最新の状態に保つことができます。

Maya FBXエクスポータと同様ですが、ピボットポイントを適切にサポートするには、FBXLoaderを更新する必要があります。

私が正しく覚えていると、 BufferGeometryを選択すると、Blenderはアニメーションをエクスポートしません。 モーフターゲットには間違いなく問題があります。＃10932を参照してください。 さらに、エクスポーターは、現在のアニメーションシステムではなく、「古い」アニメーション階層形式を使用します。

RevitエクスポータのREADMEも削除する必要があると思います。これは、ここ数年ほとんど触れられていないように見える別のリポジトリにリンクしているだけです。

このようにリンクできるthree.jsツールはおそらく何百もありますが、それらがアクティブに維持され、正しく機能していることを確認する意思がない限り、ここにそれらへのリンクを含める必要はないと思います。

「three.jsrevitexporter」をグーグルで検索すると、とにかくリポジトリは問題なく見つかります。

RevitエクスポータのREADMEも削除する必要があると思います。これは、ここ数年ほとんど触れられていないように見える別のリポジトリにリンクしているだけです。

👍

リポジトリ内に不十分に維持され、古くなった輸出業者が存在することは、新規参入者にとって不必要な混乱のポイントです。

three.jsにとって非常に重要だと思うので、このステートメントを強調したいと思います。 ユーザーがこれらのエクスポーターに遭遇すると、正しく機能するツールを期待します。 しかし、ほとんどの場合、彼らは混乱し、プロジェクト全体の印象が悪いかもしれません。 それは良くないね。 😢

罪のないユーザーとして、あえてコメントをいただけますか...

ブレンダーについて：
three.jsにネイティブの.blend形式のインポーターがある場合、
明らかに輸出業者は必要ありません。

Blender側でのインストール作業はありません。
pythonコードを介してblenderAPI / structsからjavascriptへのコンパイルはありません...

PythonでJSONエクスポーターを作成するために多大な努力が払われました。
なぜあなたの協力者はこの方法を選ばなかったのだろうか...？

@wolfgangvonludwigsburg
答えるのはかなり簡単な質問です。 ブレンド形式はthree.jsの内部表現にあまり近くないため、変換が必要です。 three.jsのJSON形式は内部表現に非常に近いため、ブレンダー表現からthree.jsへの変換の仕事は、エクスポーターとローダーのどちらと呼んでも、どちらの方法でも可能です。 とは言うものの、.blendは一般的な転送形式ではなく、blender以外は実際にサポートしていません。したがって、blenderを多用する人でも他のソフトウェアを使用する傾向があるため、ローダーを使用すると、かなり少数のユーザーを満足させることができます。交換フォーマットとして選択されるフォーマットではありません。 通常、これはobj、fbx、またはgltfやcolladaなどのオープンスタンダードです。

@wolfgangvonludwigsburg .blendファイルローダーの構築を検討する場合、これはおそらく開始するのに適した場所です。

https://raginggazebo.com/parsing-blender-3d-files-blend-1-of-3/

あなたのコメントのための多くのTHX！

しかし、なぜBlenderJSONエクスポーターはそのようなエラーが発生しやすいのですか...
=>これはBlenderAPIに依存し、Pythonで記述されており、Blenderデータ構造体を理解する必要があります。
そして、JSON形式にコンパイルすると、three.jsはその内部に再変換されます...

主にBlenderのバージョン変更で、すべてが失敗する可能性がある（そして実際に失敗する）非常に多くのタスク。
まあ、私は「直接データコンパイル」の方法を好むでしょう...

ええと、私は「直接データコンパイル」の方法を好みます。

それは良いアプローチではありません。 blendファイルをアプリに直接ロードすることは、ある種の誤用です。 代わりに、データ転送とアセット配信を目的としたファイル形式を利用する必要があります。 glTFは、アプリケーションの観点からこの側面に焦点を当てた最初の標準化された形式です。 それが私がglTFを何度も宣伝する理由の1つです😇。 これは、今後のすべての3Dアプリの標準になるはずです。

まあ、私は「直接データコンパイル」の方法を好むでしょう...

残念ながら、この方法で.blendを使用することにはさらに深刻な問題があります。 編集履歴、Blender UIの現在の状態、Blenderアドオンデータなどが保存されます。 新しいBlenderリリースがリリースされるとフォーマットが変更されます。 また、ファイルサイズは非常に大きくなる可能性があるため、高品質の3Dアプリケーションには適していません。 Blenderから直接データを取得する最良の方法は、Blenderの内部.blend形式をリバースエンジニアリングするのではなく、（FBXおよびglTFエクスポーターが行うように）BlenderのAPIを使用することです。

元の質問に対して、私は3Dオーサリングワークフローにあまり精通していないため、賛成/反対票の追加をスキップします。

しかし、メンテナとして、そして主にJS開発者として、サードパーティのオーサリングツールを積極的に維持しているFBXやglTFなどのフォーマットのロードとサポートに集中できると、信頼できる結果が得られる可能性が高くなります。

余談ですが、現在のglTFエコシステムに問題があり、このタイプのニーズを解決するのに十分なワークフローとなることができない場合は、それも有益なフィードバックです。 🙂

私はBlenderの.blendフォーマットを一般的な交換フォーマットとして使用することを主張しませんでした。
しかし、それはBlenderとthree.jsの間のコラボレーションを単純化するかもしれません...

Blenderフレームワークの下でPythonエクスポーター+ GUIを維持しているため、作業量を見積もることができません。
しかし、これは簡単に恐怖になる可能性があると思います... ;-)

@donmccurdy
ところで、Wavefront .obj、3D Studio .3dsもネイティブ形式であり、広く使用されています...

ところで、Wavefront .obj、3D Studio .3dsもネイティブ形式であり、広く使用されています...

ええ、OBJはアニメーションのようないくつかの人気のある機能をサポートしていないので、ここでは言及されていないと思いますが、確かにthree.jsは非常に長い間OBJをサポートし続けます—それは古典的で信頼できるフォーマットです。

3DS Maxの.3dsは、Blenderの.blendまたはMayaの.mltまたはCinema4Dの.c4dと同じカテゴリにあります。 各エディターには独自の内部形式があり、それらの形式はソフトウェアと同じように変更されます。 すべてのモデリングツールのプライベート内部形式のローダーを維持することは、編集者自身の開発者が提供したエクスポート形式を使用するよりもはるかに難しく、バグが発生しやすくなります。 3DSとBlenderの両方にFBXエクスポートが組み込まれており（作成者によって維持されています）、Blenderには将来のバージョンでもglTFエクスポートが組み込まれることに注意してください。

最後にもう1つ...

元/輸入業者に依存しないモデリングツールがすでに1つあります：Collada、
しかし、何らかの理由で、これらはあまり受け入れられていないようです。

できれば、私はこの実装の種類を念頭に置いていました：
Google ProtocolBuffersに基づくローディングソリューション

https://developers.google.com/protocol-buffers/

それは

...構造化データをシリアル化するための言語中立、プラットフォーム中立、拡張可能なメカニズム– XMLを考えますが、より小さく、より速く、よりシンプルです。

私たちが扱わなければならない2D / 3Dベクトルデータは本質的にそれほど複雑ではないので、1つのBlenderデータファイルスキーマを開発することは単純に実行可能であるはずです...

実際には、javascriptにブレンドファイルパーサーがあります😁
https://github.com/Galactrax/js.blend

ええと、私はサポートを受けます...-ありがとうmrdoob ;-)）

（Terrabyteの面で）最大の3Dモデルアプリケーション（Googleマップ3D）は、実装のこの効率的な種（protobufs）を使用しています...

.blendをロードするパスをたどるのは、あまり正気ではないかもしれません。 ただし、.daeおよび.fbxのロードとそれほど違いはありません。

とにかく、私は輸出業者を非難するという考えに同意します。
ただし、gltfがもう少し成熟してテストされるまで待ちます。 2018年夏？

これらの輸出業者も削除することに同意します。 RIPできる他のリポジトリに移動することもできます:)

ただし、gltfがもう少し成熟してテストされるまで待ちます。 2018年夏？

待つことは私には理にかなっているようです。 特にglTFの場合、最初にいくつかの準備を整えておくとよいでしょう。

• [] glTFエクスポートが組み込まれたBlenderの出荷、および複数のアニメーションのサポート。
• [x] Mayaおよび3DSMaxからglTFへのワークフローの改善、またはFBX2GLTFのテストの
• [x] glTF2.0用の公式COLLADA2GLTFコンバーターの更新。

2018年の夏に質問を再検討することは正しいと思われます。

ただし、gltfがもう少し成熟してテストされるまで待ちます。 2018年夏？

Blenderエクスポーターについては、私は同意する傾向があります。 ただし、FBXにはすでに成熟したはるかに優れた代替手段があるため、少なくとも3DSMaxエクスポータをすぐに削除することをお勧めします。

ただし、FBXにはすでに成熟したはるかに優れた代替手段があるため、少なくとも3DSMaxエクスポータをすぐに削除することをお勧めします。

私にはいいですね👌

さて、3DSMaxエクスポーターはなくなりました。 数ヶ月後に他のエクスポーター（BlenderとMaya）を再訪しましょう。

その間、Mayaエクスポーターに関してはあまり変わらないと思います。

おそらく今それを評価する必要があります。 私はそれをテストして、それが次の数日間維持する価値があるかどうかを確認します。

良い提案👍。

ここにいる限り、 https：//github.com/mrdoob/three.js/tree/dev/utils/converters/fbxのステータスはどうなってい

No animation support
Only Lambert and Phong materials are supported
Some camera properties are not converted correctly
Some light properties are not converted correctly
Some material properties are not converted correctly
Textures must be put in asset's folder, and use relative path in the material

また、msgPack、UTF8、およびCTMコンバーターは、何年も触れられていません。

それらはまだ誰かに役立ちますか？

@donmccurdy DOMにアクセスできないため、node.jsスクリプト内でFBXLoader使用することはできません。 TextureLoaderを利用するすべてのローダーは、 ImageLoader依存しているため、 document依存しています。 ReferenceError: document is not definedようなランタイムエラーが発生します。 FileLoaderからアクセスされるwindowオブジェクトについても同じ問題が発生します。

一時的な回避策として、 fbx2three.jsファイルのImageLoaderとFileLoaderを再定義できますか？

たぶん、fbx2three.jsファイルでImageLoaderとFileLoaderを再定義できますか？

これは十分に単純であり、今でもPythonコンバーターよりもはるかに少ないコードで済むと思います...試してみます。

たぶん、fbx2three.jsファイルでImageLoaderとFileLoaderを再定義できますか？

良いアイデア：赤面：

3DS Maxの.3dsは、Blenderの.blendまたはMayaの.mltまたはCinema4Dの.c4dと同じカテゴリにあります。

これは完全に真実ではないかもしれません。.maxは同じカテゴリに似ており、.3dsはかなり削除されています。

エクスポーターの書き方の例として、またmaxscriptにも、3dsmaxエクスポーターを用意するのが好きでした。 3ds maxからfbxを介して正しい接空間をエクスポートできたとは思いません。maxscriptを使用すると、必要なものを簡単に試したり取得したりできます。

適切な免責事項を付けて、新しいリポジトリを作成する価値はありますか？ エクスポータを作成する方法の例はすべてですが、それが維持されておらず、FBXLoaderの信頼性が高い場合は、3DSMaxからthree.jsにアセットを取り込むための推奨される方法であると思われることは望ましくありません。

ええ、どちらかといえば、私は新しいリポジトリに投票します。

json形式を完全に放棄する前に追加したかっただけです：シーンのエクスポートにブレンダーエクスポーターを使用しています。つまり、プレースホルダーオブジェクトとともにアニメーションとカスタムプロパティを使用してカメラとシーンの階層を設定し、実行時に実際のメッシュに動的に置き換えます（ロードされます）他の方法で）。 これは「ちょうど」jsonであるため、jsでイントロスペクトして変更し、これらの種類のことを行うのは非常に簡単です。 たとえば、glTF（少なくとも現在の形式では）がシーン形式として適しているかどうかはわかりません。したがって、blenderエクスポーターとjson形式がもう少し長く続くことを期待しています。

@pjoe JSON形式とBlenderエクスポーターは、このスレッドで言及されている他のもの（3DS Max + Mayaエクスポーターなど）よりも短期的には

しかし、それでも、glTFとBlenderエクスポーターに関するフィードバックを得るのは素晴らしいことです。 あなたが言及したすべてがサポートされています：

• カメラをセットアップする
• シーン階層
• アニメーション（複数のBlenderアクションの場合、別のエクスポーターが必要になります）
• カスタムプロパティ（オプションで[エクストラのエクスポート]を選択）
• マテリアル、メタデータなどの「JSONのみ」。 メッシュデータは個別のバイナリペイロードとして最適化されます

@donmccurdyは、私がglTFの経験があまりないことを認めなければなりません（少なくともまだ）-私は仕様を読み込もうとしましたが:)

glTFを使用したメインの「ビーフ」（これは優れたトランスポート形式であり、「バイト」を可能な限り迅速かつ直接GPUバッファーに取り込むのにも最適だと思います）は、すべての参照がインデックスベースであるため、適切ではないと思います。可変シーンフォーマットに適合します。 したがって、たとえばエントリを削除したり、途中で何かを追加したりする場合は、その場所以降のインデックスへのすべての参照を更新する必要があります。 この「インデックス管理」を行うと、すぐにかなり厄介なimoになります。

私がblenderglTFエクスポーターで過ごした短い時間から、それも当時（約2か月前）はかなり未熟に見えました。 それは明らかにそれを改善するのを手伝うことによって修正することができます:)

...すべての参照はインデックスベースであるため、変更可能なシーン形式には適していません。 したがって、たとえばエントリを削除したり、途中で何かを追加したりする場合は、その場所以降のインデックスへのすべての参照を更新する必要があります。

ええ、それはその意味で手動編集用に設計されておらず、ランタイム/送信フォーマットとして、おそらく決してそうなることはありません。 役立つ可能性のある、それを操作するためのさまざまなライブラリがあります。

一般的に、glTF Blenderエクスポーターは他のどのBlender出力よりも良い結果をもたらすことがわかりましたが、特定の問題を見つけた場合はバグを報告してください。 :)

@donmccurdyは、glTFがトランスポート/ランタイムに忠実であり

小さくて高速である必要があるWebアプリケーションを実行しているため、余分なライブラリや変換のオーバーヘッドを回避しようとしています。これまでのところ、このユースケースのシーン形式としては、three.jsJSON形式が適しています。 ブレンダーでシーン全体をセットアップできるようになります。たとえば、カメラアニメーションを使用して、エクスポート、ロード、実行時にモデルを動的に置き換えることができます（これは、近いうちにglTFを使用することになります）。これにより、パイプラインがかなりスムーズになります。わたしたちのため ：）

補足として、webpack jsonローダーを使用してシーンファイルをメインバンドルに含めます。これにより、処理がさらに簡単になります。

その間、Mayaエクスポーターに関してはあまり変わらないと思います。 おそらく今それを評価する必要があります。 私はそれをテストして、それが次の数日間維持する価値があるかどうかを確認します。

@looeee興味があります、これについて何かニュースはありますか😊？ 今すぐエクスポーターを削除して、代わりにFBXを参照できると思いますか？

今すぐエクスポーターを削除して、代わりにFBXを参照できると思いますか？

私は少量のテストを行っただけで、さらに多くのことを行う予定でしたが、時間がありませんでした。 しかし、そうだと思います。それを削除して、FBXLoaderがMayaを完全にサポートするようにする必要があります。

ここでBlenderエクスポーターのユーザーとしてチャイムを鳴らします。JSONを使用する利点の1つは、エクスポート後に変更するのが非常に簡単なことです。 Blenderは自動化されたツールチェーンの一部にすぎず、Webビューアに移動する準備が整う前に、エクスポートされたJSONに対して多くの処理を行います。 内部のthreejs形式に非常に近い転送形式を持つことは、私たちにとって大きなボーナスです。

また、他のエクスポート形式でいくつかのテストを行ったところ、JSON形式は、転送サイズの点でそれほど悪くないことがわかりました。たとえば、適切に圧縮されると、ColladaやFBXよりもはるかに優れています。 私たちはプロトバッファーベースの簡単なトライアルを行い、その方法で少し小さくすることができましたが、面倒なことに値するものは何もありませんでした。

大きなシーンや遅いクライアントの場合、解析と内部ThreeJSモデルへの変換の速度も重要になります。 JSON解析はブラウザーで大幅に最適化されており、モデル構造が非常に似ているため、JSON形式はこの点で非常にうまくいくと想定しています。 これを実際にテストしていません。

Soft8Softは、3dsMax用のglTFベースのエクスポーターをリリースし

@alexkowelに感謝しこのスレッドにリンクを追加できる場合は、他のglTFリソースとともにリストします。 🙂

@dherben良い点、ありがとう—

構文解析の速度については、glTFの方がさらに高速であることがわかると思います。 本質的な違いは、メタデータは依然として「単なるJSON」であるのに対し、ペイロードの大部分（頂点位置、アニメーションデータ）は、 THREE.BufferAttributeコンストラクターの型付き配列を作成するために使用できるArrayBufferチャンクにあることです。 完全に最適化されたローダー（THREE.GLTFLoaderがまだそこにあるかどうかはわかりません）では、JSでそのデータを読み取ったりコピーしたりする必要はありません。

しかし、パイプラインの一部としてのデータの変更については、あなたが言ったように、プレーンJSONの方が扱いやすいことに同意します。 glTFを操作するためのさまざまな言語のライブラリがありますが、ツールはまだあまり成熟していません。

この問題の現在の状況：

輸出業者：

• [X] Mayaエクスポーター
• [X] 3DSMaxエクスポーター
• [X] Blenderエクスポーター
  
  
  
  • 現在どこにも行かないので、将来再訪するかもしれません。
  
  
  • 2018年5月に削除されました。
  
  

コンバーター：

• [] FBX
  
  
  
  • https://github.com/mrdoob/three.js/pull/13013として提案された簡略化された置換
  
  
• [] CTM（説明されていません）
• [] utf8（説明されていません）
• [] obj2three（説明されていません）

編集：2018年5月更新。

@donmccurdy glTF BlenderエクスポーターとThree.jsローダーでさらに実験した後、戻ってきたかっただけです。 これまでのユースケースでは、実際にはシーン形式として非常にうまく機能していることがわかりました。 私が今していることは、エクスポートされたglTFファイルをThree.jsシーンにロードし、最初のレンダリングを行う前に、Three.jsシーン階層を操作することです（動的にロードされたものでプレースホルダーを交換します）。

glTFエクスポーターに見たい機能がまだいくつかあると思います。そこでコメントしたりPRを行ったりします:)

glTFエクスポーターに見たい機能がまだいくつかあると思います。そこでコメントしたりPRを行ったりします:)

素晴らしい、やってください！ 🙂

現在どこにも行かないBlenderエクスポーターは、将来再訪する可能性があります。

では、誰かが現在のBlenderエクスポーターのバグに取り組んでいるのでしょうか？ 答えはノーだと思います。 その場合、そう言うべきです。

私の前に誰もいないなら...少なくとも、回転の問題を解決しようと思います。 ＃13130

では、誰かが現在のBlenderエクスポーターのバグに取り組んでいるのでしょうか？ 答えはノーだと思います。

私は議論全体を読んだわけではありませんが、私の2セントです。

先週、常設展示会でのコンテンツ配信にThree.jsを使用するソリューションを提供している会社を支援するよう依頼されました。 ユーザーが探索して操作できる3Dモデルの看板。 古くからある元の開発者は、 Three.jsJSON形式を使用していました。 （ランタイムコードの変更がnogoであるという条件で）新しいモデルを準備して取得することは、本当に悪夢です。

IMHO Three.jsは、 FBXやglTFなどの確立されたフォーマットと急成長しているフォーマットのサポートに重点を置く必要があり

Blenderのものが出て行くワークフローを想像してみてください

1）WebGL
Three.jsは明らかに😃

2）OpenGL 3.3+
生/シンダー

3）RISC上のOpenGL ES 2.0
スマートフォンからRaspberryPiへ

4）ゲームエンジン

5）メディアサーバーと統合されたリアルタイムグラフィックスアプリ（Hippo、D3変装）
ステージVFXの人が使用するもの。

さまざまな出力に多くの異なるエクスポーターを使用する代わりに、目標は1、最大2の形式を使用することです。 最初の3つのケースでOGLを作成するときは、同じモデル形式を使用する必要があります。それだけです。 最後の2つのポイントでは、FBXが重要であり（パッケージ間でCOLLADAの実装が異なるため、操作が困難になります）、実際にはモデルは「公開」されていません。
私はThree.jsJSON形式またはBlenderアドオン（ @ mrdoob🙇🙏）をバッシングしていません、それは（持っていましたか？）使用されており、おそらく他の形式が最初にできなかった問題を解決するために発明されました（そして私はそうしますNIHS症候群もあります）。
業界内のさまざまな出力に絶えず配信する必要があるという観点から、 Three.js JSON形式は状況に適合しないため、不要です。

@krokoは間違いなく同意します👍

フォーマットの展望はより明確になり始めていると思います。 当時json形式がなかったため、three.jsjson形式が実行されました。 ファイル形式の定義は、レンダリングエンジンとAPIをすでに実行していたときに最後にやりたかったことでした😩

初心者として、Three.js JSONエクスポーターは、出力ジオメトリの生データと基本構造を確認できるため、非常に教育的でした。 他のエクスポーターは、効率的ですが、ほとんどがバイナリ形式であるため、データを表示できません。

このリポジトリから削除することが今日の最善の選択肢であることに同意しますが、 @ hccamposが言ったように、教育目的で残すために独自のリポジトリに配置できる可能性があります。

このリポジトリから削除することが今日の最善の選択肢であることに同意しますが、 @ hccamposが言ったように、教育目的で残すために独自のリポジトリに配置できる可能性があります。

http://threejs.org/editor/からJSONとしてエクスポートするオプションは常にあります

https://github.com/mrdoob/three.js/pull/14117でクローズ

Blenderエクスポーターに関連するすべての未解決の問題を今すぐ閉じることをお勧めします。 同意しましたか？

誰かが3Dモデルのエクスポート/インポート（基本機能と特殊機能用）、一般的なトラブルシューティング、古いドキュメントと例をすべて削除または更新するための「公式」ドキュメント/パイプラインを作成する可能性があると思います。 たとえば、ブレンダーのjsonエクスポーターがもうないことを考えると、騎士の例は非常に紛らわしいものです。 おそらく、3Dモデル用のJSONLoaderは、下位互換性のために保持する必要がありますが、それを読む必要があります。

@stmaccarelliここにいくつかの新しいドキュメントがあります： https ：//threejs.org/docs/#manual/introduction/Loading -3D-models、しかしはい、他に何が役立つか教えてください！

@donmccurdy紙が貧弱だと思います。
現在、さまざまな時代のドキュメント、例、インターネット上で見つかったものが混在していることを考えると、3Dインポート/アニメーションシステム全体が混乱しています。

単一のオブジェクトの参照が正しければ、マスターアニメーションシステムのドキュメントは問題ありません。
AnimationClipリファレンスを見てみましょう。 morphTargetsを正しい方法でエクスポートしているかどうかはわかりませんが、ここでは次のように読みます。

_.CreateClipsFromMorphTargetSequences（name：String、morphTargetSequence：Array、fps：Number、noLoop：Boolean）：Array
ジオメトリのモーフターゲットシーケンスから作成された新しいAnimationClipsの配列を返し、モーフターゲット名を「Walk_001、Walk_002、Run_001、Run_002 ...」などのアニメーショングループベースのパターンに並べ替えようとします。

問題は、glTFファイルをインポートすると、morphTargetSequence配列がないことです...あちこちにいくつかのmorphTargetSomethingオブジェクトが格納されていますが、何をどのように使用するかわかりません。

非常に簡単な例で3Dモデルの管理/ワークフローを説明するドキュメントが必要だと思います。
また、3Dローダーの参照はすべて同じテンプレートを尊重する必要があります。
まあ言ってみれば
1-シンプルな3Dモデルのインポート
2-マテリアルのインポート（さまざまなマップ、マップパラメータ、マルチマテリアル管理などのすべてのベルとホイッスルを含む）
3-シーン全体のインポート（glTFからのもののようなインポートされたシーンをトラバース/管理する方法など）
4-スケルタルアニメーションのインポートと管理
5-モーフアニメーションのインポートと管理

また、3Dモデルの読み込みを特徴とするすべての例が、同じパターンを尊重していることを確認する必要があります。

例を更新する必要があります。不可能ではありますが、一部の部分が非推奨であり、何が（騎士の例のように...）

_EG-3DモデルのJSONファイル形式を廃止する必要があると判断した場合（たとえば、glTF）、スケルタルアニメーションとモーフターゲットの両方を備えた唯一のアニメーション例が、 10バージョン前のJSONモデルで、使用されなくなったデータ構造を格納します。_

@stmaccarelli推奨されるエンドツーエンドのワークフローは1

通常、そのCreateClipsFromMorphTargetSequencesメソッドは必要ないと思います。 上記のドキュメントでは、特定のローダーの使用の詳細については説明していません（おっしゃるように、一貫性がありません）が、

loader.load('foo.glb', function(gltf) {
  const clips = gltf.clips;  // Array<THREE.AnimationClip>
  const model = gltf.scene; // THREE.Scene
  ...
});

この場合、クリップがTRS、スキン、またはモーフターゲットのいずれであるかは関係ありません。アニメーションは、すべて同じように再生できます。 MixamoとBlenderを使用して1つの可能なワークフローを作成しました。 これはMayaを使用した別の方法です。

また、3Dモデルの読み込みを特徴とするすべての例が、同じパターンを尊重していることを確認する必要があります。

また、3Dローダーの参照はすべて同じテンプレートを尊重する必要があります。

これは公正な点であり、ここで改善の余地があります。

スケルタルアニメーションとモーフターゲットの両方を備えた唯一のアニメーションの例が、10バージョン前のJSONモデルを使用し、現在は使用されていないデータ構造を格納する古い騎士の例であることは意味がありません。

厳密に言えば、JSON形式とデータ構造は非推奨ではなく、シーンを[逆]シリアル化するための完全に合理的な方法ですが、要点を説明します。 @mrdoobアニメーションの例のいくつかを置き換えることについてどう思いますか？ そのような：

animation / keyframes / json
animation / scene
animation / skinning / blending
animation / skinning / morph

アニメーションの例のいくつかを置き換えることについてどう思いますか？

このために+1。 私は少なくともanimation / skinning / blending aの兵士を、次のようなMixamoのより現代的なモデルに置き換えることに投票します。

アイドル/ウォーク/ランをブレンドすることができ、それが望ましい場合は、モデルをglTFに変換することもおそらく可能です。

モデルのサイズは約9MBですが、現在のモデルと関連するすべてのファイルは71MBです。

animation / skinning / morph場合、FBXモーフターゲットをテストしてきたモデルを次のように使用できます。

現在のナイトモデルとほぼ同じサイズですが、顔の表情にはモーフターゲットが一般的に使用されているので、これの方が理にかなっていると思います。 繰り返しになりますが、現在はFBX形式ですが、必要に応じてglTFに変換できます。

考慮すべきいくつかの例を次に示します。

| スクリーンショット| リンク| サイズ|
| --- | --- |-|
| | リンク| 6 MB |
| | リンク| 3 MB |
| | リンク| 5 MB |
| | リンク| 12 MB |

それらはすべてアニメーション化されており、three.jsで正しく機能し、Sketchfabダウンロードバージョンよりも少し圧縮または最適化される可能性があります。 実行/歩行サイクルが良好な装備されたキャラクターはありませんが、