これは本当に格好良いです！

ちなみに、 THREE.GLTFLoaderを削除し、 GLTF2Loader → GLTFLoader名前を近いうちに変更する予定です*。 混乱を避けるために、r87がリリースされる前にエクスポーターの名前をGLTFExporterに変更することをお勧めします。これにより、リリース間で名前を変更する必要がなくなります。 おっと、あなたがすでにそのように名前を付けているのを見逃しました..続けてください！ 😆

* @mrdoob 、それがいつ起こるべきかについての好みはありますか？ 非推奨の警告だけでr87にGLTFLoaderを保持し、r88で削除したい場合を除いて、IMOでこれを実行できますか？

早いほど良いと思います。 新しいGLTFLoaderが1.0を検出し、2.0以降のみをサポートしていることをユーザーに警告できる限り。

IIRCは、前に述べたようにassetを見ることで検出できます。

IIRCは、前述のようにアセットを確認することで検出できます。

✅うん！ https://github.com/mrdoob/three.js/pull/11864

いいね！ しかし、私はマイナーなバグを見つけました。 今PRをしています。 名前を変更する前にマージしましょう。

チェックリストで誰かが取り組んでいる項目を指定できますか？

@takahirox確かに！ 人々はここにコメントを書くことができ、リストを更新して、すでに何かが起こっている場合はPRを指すことができます

次に作業するのは、テクスチャを使用して、URLだけを使用するのではなくbase64に変換することです。

ありがとう！ glTFエクスポーターの作成を手伝いたいです。 チェックリストで何ができるか調べています...

ところで、意図的に2つの変数WEBGL_CONSTANTSとTHREE_TO_WEBGLグローバルにしたことがありますか？

@takahiroxかっこいい！
2つの変数に関しては、これを次のPRで取り上げて、 WebGLUtils一部にして、インポートするだけです。 これらの定数を必要とするそれぞれが毎回それらを再定義する必要があることは意味がありません。

@takahiroxところで、もちろんリストに新しいアイテムを提案してください！ ;）

@fernandojsgもちろんです！ 変数については、意図的にグローバルとして宣言されている場合は、どこかに移動することを提案したかったので、そうしていることを知っておくと便利です。

共有バッファビューで作業したい。

BufferViews：現在、アクセサーごとに新しいbufferViewを作成しています。これは、同じcomponentTypeを共有するこれらの属性に1つだけを使用するように修正する必要があります。

すべての属性に1つではなく、同じcomponentTypeを共有する属性に1つあるのは、データの配置のためですよね？

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#data -alignment

かっこいい、私はあなたをリストに追加しました👍はい、基本的に同じタイプのコンポーネントの同じバッファビューを共有したいと思います。たとえば、位置があり、通常の場合、2つのVEC3アクセサがありますが、それらはポイントします同じbufferviewに。 それは素晴らしい出発点になるかもしれません;）

つまり、異なるcomponentType（例：floatとshort）間でバッファービューを共有させない理由は、適切なデータアライメントを維持するためです。

normal (Vec3) 、 position (Vec3) 、 uv (Vec2) 、同じtargetである限り、同じバッファビューに異なるコンポーネントタイプを格納できると思います。同じバッファビューにある可能性がありますが、 indicesはありません。 @donmccurdy確認できますか？

うん、同意した。 そして、このglTF仕様が言及しているように

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#data -alignment

アクセサーのbufferViewへのオフセット（つまり、accessor.byteOffset）およびアクセサーのバッファーへのオフセット（つまり、accessor.byteOffset + bufferView.byteOffset）は、アクセサーのコンポーネントタイプのサイズの倍数である必要があります。

簡単にするために、異なるcomponentType（= floatとshortのようなデータ型、vec2やvec3ではない）の間でバッファービューを分離することをお勧めします。 異なるデータ長のcomponentType間でそれらを分離すると、より最適化されます。

ところで、現在のエクスポーターがaccessor.componentType float、uint、ushortのみをサポートしている特別な理由はありますか？ glTF 2.0は、char、uchar、およびshortに加えて、それらを処理できます。

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#accessorcomponenttype -white_check_mark

@takahiroxは実際にはそうではありません。現在サポートしている属性のタイプ（位置、法線、色、UV、インデックスなど）に使用されているため、これらを定義しました。
私が取り組んでいる次のステップはテクスチャなので、たとえばucharような他のものが必要になります

OK、それで、あなたがすでに実装を始めていない限り、私は最初にaccessor.componentType取り組みます。

ほぼ準備ができていますが、私のPRは＃11978と競合するはずです。
だから私は＃11978がマージされたら私のものを送り、競合を修正します。

リストにアニメーションを追加しますか？

@takahirox確かに、アニメーションを追加するのは素晴らしいことかもしれません。 three.jsのアニメーション機能の現在の状態に精通していなかったため、追加しませんでしたが、引き継ぐことにした場合は素晴らしいでしょう;）

BufferGeometryグループをサポートする予定はありますか？
GLTF仕様はそれをカバーしていますか、それともすべてのグループに新しいメッシュを作成することになりますか？
これも注意を払う必要があります。メッシュの材料特性は材料の配列です。

@marcatec glTF仕様には、「メッシュ」と「プリミティブ」の区別があり、それぞれが異なるマテリアルを参照できるBufferGeometryグループを作成できます。 現在、THREE.GLTFLoaderはロードプリミティブを最適化せず、個別のメッシュを作成しますが、実装することはできます。

素晴らしい仕事、素晴らしいリスト、そしてこのフォーマットにはすでにたくさんのサポートがあることを知っておくと良いでしょう！ また、gltfブレンダーエクスポーターと一緒に非常にうまく機能します。 ライトのサポートが待ちきれません！ これからもいい結果を出し続けてください。

私は同意します、素晴らしい仕事です！

StandardMaterial以外のマテリアルのサポートを追加する予定はありますか？

ありがとう！

@homerjam MeshStandardMaterialと共有されているマテリアルプロパティはすべて保持されます。たとえば、 mapとnormalMapを使用するMeshPhongMaterialは、これらのテクスチャをそのままにしてエクスポートしますが、three.jsにインポートして戻すとMeshStandardMaterialになります。 エクスポーターは現在、このためにPBRへのナイーブな変換を行っています。

ラウンドトリップサポート（GLTFExporterからPhongをエクスポートし、GLTFLoaderからPhongをロードする）では、glTF形式で進行中の作業が必要になります： https ：

baseColorTexture ：サポートされています（material.map）が、texCoordは常に0に設定されています

@fernandojsgここで何が欠けているのか明確にできますか？ .mapは常にthree.jsの最初のUVセットであるため、これはglTFでそれを表す正しい方法のように聞こえますか？

また、注意点として、リストの3つの項目に取り消し線を付けました。 以下の理由：

• 接線
  
  
  
  • three.jsはGPUでのみそれらを計算します。 エクスポーター専用の実装を追加することは理想的ではないようです。
  
  
• スパースアクセサ
  
  
  
  • これは、 mattdeslのスクリプトのように、エクスポート後の最適化にます。
  
  
• マテリアルがglTFのデフォルトと一致するかどうかを確認し、省略します
  
  
  
  • エッジケース/クラッターのように感じますが、誰かが強く感じた場合は自由に実装してください
  
  

エディターからGLBにエクスポートすると、 alphaMap 、 roughnessMap 、およびmetalnessMapがエクスポートされないことに気付きました。

＃13397で、 normalMapどちらもエクスポートされないと言いましたが、間違っていたようです。

エディターからGLBにエクスポートすると、alphaMap、roughnessMap、metalnessMapがエクスポートされないことに気付きました。

誰かがすでに始めていない限り、私は今日これに取り組みます。

@donmccurdy

スパースアクセサ
これは、mattdeslのスクリプトのように、エクスポート後の最適化に任せるのが最善だと思います。

エクスポータにモーフのスパースアクセサをサポートさせたいと感じています。 後で試してみます。

@takahiroxかっこいい！ どうぞ！

alphaMapがglTF2.0でサポートされているとは思いません。

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#material

ええ、私はそれを恐れました.... metalnessMapとroughnessMapどうですか？

私は今それらに取り組んでいます！

13415

画像フォーマットについて。 glTF 2.0は、外部画像ファイルとして.pngと.jpgのみをサポートします。 サポートされていない画像形式のファイル（例：.bmp）をembedImagesモードで処理する方法を検討しています。

1. .pngまたは.jpgに変換して埋め込みます
2. 気にしないでください。 元の画像ファイルとしてエクスポート
3. エクスポートしないでください

私は1が好きです。何か考えはありますか？

うわー、本当にあなたたちの作品に感謝します。

ほとんどの3Dモデルはマルチマテリアルを使用しているため、 Multi-material meshesができるだけ早く実装されることを期待しています。

1. .pngまたは.jpgに変換して埋め込みます
2. 気にしないでください。 元の画像ファイルとしてエクスポート
3. エクスポートしないでください

私は3に投票し、コンソールに警告を記録します。

ほとんどの3Dモデルはマルチマテリアルを使用しているため、マルチマテリアルメッシュができるだけ早く実装されることを期待しています。

同意しました、私にとってこれは輸出業者の使用を妨げる一番の問題です。

ほとんどの3Dモデルはマルチマテリアルを使用しているため、マルチマテリアルメッシュができるだけ早く実装されることを期待しています。

他のスレッドで言ったように、私はそれに取り組んでいます。

1. .pngまたは.jpgに変換して埋め込みます
2. 気にしないでください。 元の画像ファイルとしてエクスポート
3. エクスポートしないでください

私は3に投票し、コンソールに警告を記録します

ええ、私は3.がより単純で、ユーザーを混乱させないだろうと思うようになりました。 emedImagesモードで埋め込み画像を取得すると、少し混乱します。

私が1.を好む理由は、他の形式からglTFに変換するためでした。 他の形式の一部（または多く）には、画像形式の制限がありません。

エクスポータはembedImagesモードで変換します。 したがって、コンソールの警告に「変換する場合はembedImagesオプションを使用する」を追加するとよいと思います。

私も3人で行きます。 他の形式からの変換は面倒な場合があり、とにかくいくつかの形式を他の形式よりも優先する必要があります。 おそらく今すぐ3を実行して、gltfがktxなどの新しいテクスチャフォーマットにサポートを追加するかどうかを確認するのを待つ価値があります。実装を再検討できます。

https://github.com/mrdoob/three.js/pull/13415#issuecomment -369022383で説明されているように、エクスポーターがユーザー用にambientRoughnessMetalnessテクスチャを作成できれば便利です。 おそらく、そのコードをImageUtilsに配置する方が良いでしょう。

チェックリストを最新の変更で更新しました。 multimaterialアイテムに@takahiroxを追加しました。これで、画像の作成タスクを実行します。
material_unlit拡張機能も追加しましたが、まだドラフト中ですが、リリースに非常に近く、それほど変更されないと思います（/ cc @donmccurdy）

ほとんどの3Dモデルはマルチマテリアルを使用しているため、マルチマテリアルメッシュができるだけ早く実装されることを期待しています。

他のスレッドで言ったように、私はそれに取り組んでいます。

WIP ...（ミクにはマルチマテリアルがあります）

サポートされていない画像形式については、3つにしましょう。

@takahirox格好良い！ 👍

ところで、あなたはzipアーカイブのサポートに興味がありますか？ .glTF +外部の.binとテクスチャは他のオーサリングツール（多分）に適合しますが、アーカイブ以外では行うのは困難です。 したがって、zipアーカイブが必要になります。 そして、エクスポートされたファイルサイズを減らすことができます。

以前に地元の支店で試してみましたが、興味があれば後で共有できます。

それはglbをgzipすることとほとんど同じではありませんか？

.glTF +外部の.binとテクスチャは他のオーサリングツールに適合します（多分）

オーサリングツールが個別のファイルを必要としないことを願っています。 デフォルトでGLBを使用することをすべての人に奨励しています。 ただし、画像が埋め込まれていない場合は、画像を手動で編集する方が簡単です。

その機能をTHREE.GLTFExporter直接入れたいかどうかについては強い意見はありません...しかし、代わりにglTFの最適化後のオプションが多すぎないようにする必要があると思います。 別の例として、Dracoは一種の複雑で、いくつかの外部ファイルを必要とするため、特殊なglTFからglTFへのツールにその最適化を行わせる方がよいのではないでしょうか。 同様に、glb-unpacker（http://glb-packer.glitch.me/の反対側）を作成して、人々が必要としていることがわかった場合に、GLBからZIPにファイルを解凍できるようにすることもできます。

https://github.com/KhronosGroup/glTF/issues/1256から—

... gltf-pipelineの本来の目的（そして実際には一般的にglTF）は、エクスポーターを可能な限り単純にし、最適化を共通のツールにプッシュします。 もちろん、断片化にも役立ちます。

そうは言っても、私が知っているglb-unpackerはまだ存在しません...

@mrdoob

テクスチャ画像は、.glTFと.glbではなく、外部のものにしたかったのです。

@donmccurdy

https://github.com/KhronosGroup/glTF/issues/1117のディスカッションをフォローアップし、.glb +埋め込みファイルとパイプラインアプローチを今すぐ奨励することに同意します。 1つの.glbは、特にWebおよびパイプラインアプローチのデータ送信に適しています。これにより、エクスポーターとツールをシンプルで再利用可能に保つことができます。 （私はUNIX / Linuxコマンドパイプラインアプローチも好きです！）

したがって、エクスポーターは現在zipアーカイブのサポートを必要としないと思います。 また、同じ理由で、スパースアクセサーとdracoのサポートも必要ないかもしれません。

glb-unpackerに関しては、暇なときに作るかもしれません。 glTF固有のツールがなくても読み取り可能なため、.glTF +外部ファイルが好きなアーティストもいると思います。 また、外部ファイルはファイルの並列ロードによりロード時間を短縮できる場合があり、最適化の目的で使用できます。

パイプライン/最適化ツールに関しては、ネットワークを介して巨大なデータを転送したくないことに注意したいと思います。 ユーザーは、データを転送する前に最適化/圧縮したいと考えています。 そのため、ユーザーがサーバーに巨大なファイルを送信する必要があるため、glTF最適化Webサービスが巨大なデータに対してうまく機能しない場合があります。

さらに、Three.jsやその他のJavaScriptブラウザーベースのエンジンの場合、ブラウザーで実行されるglTF最適化ツールがあれば幸いです。 データがユーザーに渡される前に最適化/圧縮できます。 それらがないと、ブラウザの制限により、ユーザーはエクスポートされたデータを手動でダウンロードしてからパイプラインツールに渡す必要があります。

この観点から、ツールをどこでも、ブラウザー、サーバー、CUIなどで実行して、より一般的で再利用できるようにしたいと考えています。 異なるプラットフォーム用に同じ目的のツールを2回以上作成したくありません。 では、node.jsベースのツールが良いでしょうか？ glTF（パイプライン）チームに何か提案はありますか？ （たぶん、この議論はここではなく、glTFで行われるべきです。）

念のため、 GLTFLoaderバイナリサポートが拡張機能として実装されていますが、.glbはglTF 2.0のコア仕様に含まれていますよね？

念のため、GLTFLoaderではバイナリサポートが拡張機能として実装されていますが、.glbはglTF 2.0のコア仕様に含まれていますよね？

ええ、それはglTF 1.0の拡張であり、コアglTF 2.0仕様の一部になった後、そのコードを再配置したり名前を変更したりすることはありませんでした。

この観点から、[最適化ツール]をどこでも、ブラウザー、サーバー、CUIなどで実行できるようにして、より一般的で再利用できるようにしたいと考えています。 では、node.jsベースのツールが良いでしょうか？ glTF（パイプライン）チームに何か提案はありますか？ （たぶん、この議論はここではなく、glTFで行われるべきです。）

glTF-Pipelineのロードマップについて質問する価値があります... glTF-Toolkitは関連性があるように見えますが、（現在）Windowsでのみ実行されます。 私は個人的にNode.jsが好きですが、WASMへのコンパイルではC ++またはRustが妥当な選択である可能性があります。

ああ、WASMへのコンパイルがありませんでした。 いくつかの推奨される開発プラットフォームを指定することは、最適化開発に役立ちます。 だから私は適切なスレッドに提案したいと思います。

私はthree.jsとは異なるレポに住むことができるパイプライン上のこれらの最適化を感じるように私は@donmccurdyに同意し、誰もが彼らから利益を得ることができます。 gltfパイプラインとツールキットツールの違いを確認する必要がありますが、この種の機能が含まれていると思います。
また、WASMがあれば、ソース言語はそれほど重要ではないことにも同意しますが、node.jsで記述されている場合、3DWebエンジン周辺のコミュニティの多くがそれらの改善に役立つ可能性があることも事実です。とにかく、今はこのファイル形式の主なターゲットです。

「変換前の最適化」について理解できません...パイプラインがモデルに対して実行する可能性のある変換にはいくつかのタイプがあり、最適化はおそらく最も一般的なタイプの変換ですか？

それを超えて同意した。 他のツールを構築したり、よりユーザーフレンドリーなGUIにプラグインしたりするために使用できる、低レベルで焦点を絞ったツールがあると便利です。

おっと、それはタイプミスです。 変身するのではなく、移す。 つまり、ほとんどのユーザーは、ネットワーク経由でデータを送信する前に最適化/圧縮したいと考えています。 投稿を更新して、わかりやすくしました。

こんにちは、みんな

THREE.js GLTFエクスポーターを使用して、フレームシーン全体をgltfオブジェクトとしてエクスポートしています。
aframeで定義されたa-animationタグをgltfオブジェクトのアニメーションの一部にするにはどうすればよいですか？

@donmccurdy @fernandojsg @mrdoob

こんにちは@ siddhartpai— THREE.GLTFExporterはTHREE.AnimationClipオブジェクトのみをglTFアニメーションに変換しますが、A-FrameのアニメーションシステムはTweenJSを使用します。 したがって、現在これは不可能です。 A-FrameまたはA-FrameInspectorで問題を開き、これもGLTFExporter使用して、将来の機能としてリクエストすることをお勧めします。

マルチマテリアルサポート＃13536

バリデーターが、正規化されていないbufferviewのすべての通常の要素でエラーをスローすることに気づきました。 たとえば、[0,0,0]のような初期化されていない値を保存すると、そのエラーがスローされます。
これはエラーであり、警告/通知ではないため、修正に敏感であることがわかります。 通常のbufferview要素が正規化されていることを確認することについてどう思いますか？ それでも、[0,0,0]のように正規化できない値の場合、有効な単位ベクトルを使用する必要がありますか？ / cc @donmccurdy

NORMALは正規化する必要があるようです。

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#meshes

ノーマル| 「VEC3」| 5126（フロート）| 正規化されたXYZ頂点法線

Three.jsの通常にはそのような制限がないため、確認することに同意しました。

はい、しかし、[0,0,0]の未使用の値のように、実際の法線がない場合は、有効な値を作成するだけで大​​丈夫ですか？ [1,0,0]としましょう。 したがって、バッファビューコードを変更して、通常の属性を解析していることを検出し、データビューに保存する前に各属性を正規化する必要があります。

[0,0,0]の未使用の値のように、実際の法線がない場合の対処方法

うーん....有効なものと交換して警告を表示しますか？

したがって、バッファビューコードを変更して、通常の属性を解析していることを検出し、データビューに保存する前に各属性を正規化する必要があります。

processMesh()でそれを行う方が好きです。

var originalNormal = geometry.attributes.normal;

if ( hasNonNormalizedValues( originalNormal ) ) {

    geometry.attributes.normal = createNormalizedAttribute( originalNormal );

}

processAccessorHere();

geometry.attributes.normal = originalNormal;

processBufferView()でこれを行うと、位置や通常などの異なる属性間でデータが共有されるかどうかを注意する必要があるため、コードは少し複雑になります。 （私はそれが非常にまれなユースケースであることを知っていますが、Three.jsは制限していません。）

はい、私はそのアプローチが好きです。エクスポート後に法線を変更することを恐れていましたが、参照を保存して終了後に再び法線を戻すことができれば問題ありません。 ：+1：これらの変更でPRをプッシュしていただけませんか？ または私にそれをしてもらいたいですか？

はい、します。 （あなたはそれを修正するために急いでいますか？）

@takahiroxかっこいい、ありがとう！ しかし、急いで私は輸出業者の状態を確認していました^ _ ^

じゃあ、今週は〜明日〜やります。

そうです、glTFでは特定の頂点の法線を省略することはできませんが、単一のプリミティブで他の頂点を省略することはできません。 ある種の値を提供するか、これらの頂点を取り除くか、エラーをスローする必要があります。

私はユーザーにとって物事を簡単にしたいので、私の投票は、それらを正規化する新しい法線配列を作成し、空のものに（0,1,0）値を追加することです。

良いようです。 大規模なモデルで速度が遅い場合は、 checkNormalsオプションなどが必要になる可能性があるため、これを必要としないユーザーは、すべての頂点をスキャンするのではなく、オプトアウトできます。

うん、私はちょうど同じことを書くところだった！ ：NS

大規模なモデルで速度が遅い場合は、checkNormalsオプションなどが必要になる可能性があるため、これを必要としないユーザーは、すべての頂点をスキャンするのではなく、オプトアウトできます。

最初にそのオプションなしでPRを作成します。 必要に応じて追加しましょう。 個人的には、このチェックはそれほど遅くないと思います。

最初にそのオプションなしでPRを作成します。 必要に応じて追加しましょう。 個人的には、このチェックはそれほど遅くないと思います。

各ストロークをa-painterにロードするときに、バッファ全体を正規化していましたが、非常に遅くなりました

正規化されているかどうかを確認するだけでも？

@takahiroxとにかく長さを計算する必要があるので、それほど変わらないと思います

うーん、わかりました。 PRで評価します。

これは、各頂点で計算を行う（相対/絶対モーフターゲット変換を除く）最初のGLTFExporter機能であるため、いずれにしても遅くなる可能性があります。

すごい仕事！ IMHOは、「例」ではなく、コアのthree.jsにマージする必要があります。
KHR_lights_punctualサポートをぜひご覧ください。

PRhttps：//github.com/mrdoob/three.js/pull/15519はKHR_lights_punctualを追加します。 :)

この問題はおそらく解決できると思います。残りの項目はそれほど重要ではなく、利便性や最適化であり、他の場所で追跡できます。

• []バッファビューを再利用する
• []メタル/ラフ/ aoテクスチャを自動的にマージします

やあみんな、モーフを適用して最終オブジェクトから削除するモーフ変更によってカスタムシェイプメッシュをエクスポートする方法を知っている人はいますか？
この質問のようにhttps://stackoverflow.com/questions/57423471/how-to-export-morph-changed-meshes-from-threejs-application
前もって感謝します！

@ vini-guerrero GitHubの問題ではなく、フォーラム（https://discourse.threejs.org/）またはStackOverflowを使用してヘルプを参照してください。