PMXとPMDの紹介
このセクションでは、PMXとPMDファイルがどのような情報で構成されているか、MMDがその情報をどのように解釈するか、 そしてbabylon-mmdがMMDの動作をどのように実装しているかを説明します。
このドキュメントでは、babylon-mmdがMMDの動作をどのように実装しているかについての内容はこのブロックで区別されています。
PMX/PMDファイルの概要
ポリゴンモデルエクステンデッド（PMX）とポリゴンモデルデータ（PMD）ファイルは、ミクミクダンス（MMD）で使用される3Dモデルファイルフォーマットです。
基本的に、PMX/PMDファイルはテクスチャファイルを除くすべてのデータを含む単一のバイナリファイルです。
これらのファイルフォーマットにはドキュメント化された仕様がないため、リバースエンジニアリング分析によって知られた情報しか存在せず、小さなエラーがあるかもしれません。
また、各情報に対する公式名称がないため、 このドキュメントでは説明のために各情報に一般的な名前を任意に割り当てています。
最新の3Dアセットフォーマットとの違い
最新の広く使用されている3Dアセットフォーマット（例：glTF、FBXなど）は、 3Dモデルを含むシーングラフを表現するように設計された構造を持っています。 対照的に、PMXとPMDファイルは基本的に単一のジオメトリベースの3Dモデルを表現するための情報のみを含み、 カメラ、ライティング、アニメーション、シーングラフなど、3Dモデル以外の要素を表現するための情報は含まれていません。
PMXファイル
PMXはPMDの改良版であり、PMDよりも優れた構造と多くの機能を提供します。
現在知られているPMXファイルのバージョンは2.0と2.1です。
PMX 2.1はソフトボディフィジックス、頂点カラー、フィジックスモーフなど様々な機能をサポートしていますが、 この仕様をサポートしているのはPMXエディタのみであり、MMDもバージョン2.1をサポートしていないため、 バージョン2.1は実質的に使用されていません。
babylon-mmdのPmxParserはPMX 2.1ファイルの解析をサポートしていますが、PmxLoaderはそれらをロードしません。
babylon-mmdはPMX 2.0仕様のほとんどをサポートしており、未処理のデータはモデルのロード処理中に保存されます。
PMDファイル
PMDはPMXの以前のバージョンであり、PMXと比較してより単純な構造と限られた機能を持っています。
PMXファイルはPMDファイルと下位互換性がなく、MMDでは、PMDファイルとしてロードされたモデルはPMXファイルとは別のロジックで処理されると推測されます。
babylon-mmdはPmdParserがPMDファイルを解析する際に、同時にPMDファイルをPMXフォーマットに変換するタスクを実行します。
そのため、PMDモデルを処理するための別個のロジックは存在せず、すべてのMMDモデルは共通のロジックで処理されます。
PMX/PMDファイルの構造と解析方法
PMX/PMDファイルは、様々なデータタイプを含むリトルエンディアンバイナリファイルです。
これらのファイルは一般的な長さプレフィックス形式で構造化されています。例えば、スケルトンデータを表現する場合、 最初にボーンの数が示され、続いて各ボーンの情報が順番にリストされます。 各データのサイズは固定または可変長であり、データの順序は常に同じです。
データアラインメントは強制されず、各フィールドはバイナリファイル内で連続して格納されます。
ヘッダー
PMX/PMDファイルのヘッダーには、ファイルバージョン、モデル名、コメントなどが含まれます。 この情報はファイルのメタデータとして機能し、モデルの識別と管理に使用されます。
PMXファイルの場合、英語モデル名や英語コメントなどの英語フィールドが存在しますが、一般的にはあまり活用されていません。
ジオメトリ
PMX/PMDファイルのジオメトリは3Dモデルデータの中核部分であり、1つのファイルにつき1つのジオメトリデータのみが存在し、 主に頂点が保持する情報を含んでいます。
PMX構造の主要な頂点属性を見ると、主要なコンポーネントは以下の通りです：
- 位置：モデルのローカル空間における頂点の3D座標。
- 法線：照明計算に使用される頂点の法線ベクトル。
- UV：テクスチャをモデルにマッピングするために使用される頂点のテクスチャ座標。
- 追加Vec4：高度なテクスチャリング技術のための追加テクスチャ座標または頂点カラー情報。これはPMDモデルには存在せず、ほとんどのPMXモデルでも使用されていません。
- ボーンウェイトタイプ：スキニングに使用されるボーンウェイトのタイプ（BDEF1、BDEF2、BDEF4、SDEF、QDEF）。
- ボーンインデックス：頂点に影響を与えるボーンのインデックス。
- ボーンウェイト：スキニングに使用される頂点に対するボーンの影響の重み。
- エッジスケール：モデルのエッジをレンダリングするために使用されるエッジのスケール。
追加Vec4はMMDモデルでは一般的に使用されていません。 このフィールドはPMX 2.1で追加された仕様でよく利用され、MMDでMikuMikuEffect（MME）を使用してカスタムシェーダーを適用する際に使用できます。
babylon-mmdはMMDモデルから頂点情報をロードします。
例外として、追加Vec4フィールドはmmdmodel.preserveSerializationDataオプションがtrueの場合にのみ保存されます。
MMDはDirectXのUV座標系に従い、Babylon.jsはOpenGLのUV座標系に従うため、 MMDモデルをロードする際にUV座標にY反転が適用されます。
頂点情報だけでなくインデックスも含まれています。これにより、ジオメトリをインデックス付きメッシュとして表現することができます。
MMDとBabylon.jsでは異なる巻き順（Winding Order）が使用されているため、babylon-mmdはMMDモデルをロードする際にインデックスの巻き順を反転させます。
テクスチャ
テクスチャはPMX/PMDファイルでモデルの表面に適用される画像を定義します。 単一のPMX/PMDファイルに複数のテクスチャが存在でき、 テクスチャは.pmxまたは.pmdファイルを含むディレクトリからの相対パスを表す文字列として格納されます。
例えば、次のようなファイル構造の場合：
- model.pmx
- textures/
- texture1.png
- texture2.png
model.pmxファイル内では、テクスチャはtextures/texture1.png、textures/texture2.pngのような相対パスとして格納されます。
私の調査に基づくと、MMDがサポートするテクスチャフォーマットはPNG、JPEG、BMP、TGAです。
相対パスとして格納されたテクスチャは、Windowsファイルシステムでは大文字と小文字を区別せずに処理されます。
しかし、Webの環境ではURLは大文字と小文字を区別するため、babylon-mmdでモデルをロードする際にテクスチャのロードが失敗することがあります。
この問題を解決するために、babylon-mmdはMMDモデルをBPMXに変換するメソッドやURLではなくブラウザのFile APIを使用してテクスチャをロードするメソッドを提供しています。
BMPファイルローダーについては、ブラウザとMMD間でのBMPローダーの実装の違いにより、 ブラウザでBMPファイルをロードする際にアルファチャンネルが削除される可能性があります。
この問題を解決するために、babylon-mmdはBMPファイルをロードする際にヘッダーを変更することでアルファチャンネルを保持するオプションを提供しています。
これはRegisterDxBmpTextureLoader関数を使用して有効にすることができます。
マテリアル
マテリアルはPMX/PMDファイルでモデルの表面特性を定義します。 単一のPMX/PMDファイルに複数のマテリアルが存在でき、PMXフォーマットに基づいて、各マテリアルには次のプロパティが含まれています：
- 拡散色：マテリアルの基本色。
- 鏡面色：鏡面反射ハイライトの色。
- 光沢度：マテリアルの光沢、鏡面反射ハイライトのサイズに影響します。
- 環境色：アンビエントライティングに使用されるマテリアルの環境色。
- エッジ色：エッジレンダリングに使用されるマテリアルのエッジの色。
- エッジサイズ：エッジレンダリングに使用されるエッジのサイズ。
- テクスチャ：マテリアルによって使用されるテクスチャのインデックス。
- スフィアテクスチャ：マテリアルによって使用されるスフィアテクスチャのインデックス。
- トゥーンテクスチャインデックス：トゥーンのインデックス
- フラグ：マテリアルの両面表示やエッジレンダリングの使用など、マテリアルの様々な特性を示すフラグ。
- インデックス数：マテリアルによって使用されるインデックスの数。
インデックス数とサブメッシュ
PMX/PMDファイルは単一のジオメトリに対して複数のマテリアルを持つことができます。
各マテリアルはジオメトリのインデックスのセクションを分割してサブメッシュを定義します。 具体的には、各マテリアルがインデックスバッファから使用するインデックスの数を定義し、マテリアルの順序に従ってジオメトリのインデックスのサブメッシュが定義されます。
例えば、インデックスの長さが100で、最初と2番目のマテリアルがそれぞれ50のインデックスを使用する場合、
最初のマテリアルはindices[0]～indices[49]を使用し、
2番目のマテリアルはindices[50]～indices[99]を使用します。
babylon-mmdは、Babylon.jsのMultiMaterialとSubMeshを使用してMMDモデルのサブメッシュを実装しています。
しかし、このアプローチはBabylon.jsとの互換性が低く、パフォーマンスの問題がある可能性があるため、ロード時に単一のジオメトリを複数のジオメトリに分割するオプションも提供されています。
このオプションはmmdmodel.optimizeSubmeshesオプションで有効にでき、デフォルトで有効になっています。
レンダリング方法
MMDマテリアルは、デプステスト、デプスライト、アルファブレンディングを使用して、PMX/PMDファイルにリストされている順序でレンダリングされます。
babylon-mmdは、MMDのレンダリングアプローチを再現しながら、より良いパフォーマンスを提供するか、または既存のBabylon.jsシーンと統合するために、以下のレンダリング方法を提供しています：
DepthWriteAlphaBlending- MMDのレンダリング方法と同じデプステスト、デプスライト、アルファブレンディングを使用し、PMX/PMDファイルにリストされている順序で描画順序でレンダリングします。
AlphaEvaluation- アルファブレンドが必要ないマテリアルを判断し、一部のマテリアルを不透明として、他はアルファブレンディングを使用してレンダリングすることで、Babylon.jsのレンダリングアプローチを尊重します。描画順序はカメラから最も近いものから最も遠いマテリアルまでです。
DepthWriteAlphaBlendingWithEvaluation（デフォルト）DepthWriteAlphaBlendingとAlphaEvaluationを組み合わせ、デプステスト、デプスライト、アルファブレンディングを使用し、PMX/PMDファイルにリストされている順序で描画順序でレンダリングします。アルファブレンドが必要ないマテリアルは不透明としてレンダリングされます。
MMDのシェーディングはブリン-フォンシェーディングモデルに基づくトゥーンシェーディングを使用しています。
babylon-mmdはMMDマテリアルを再現するために、StandardMaterialの修正版であるMmdStandardMaterialを使用しています。
さらに、モデルはBabylon.jsのStandardMaterialまたはPBRMaterialを使用してロードすることもできます。
スケルトン
スケルトンはPMX/PMDファイルの構造で、モデルにボーンベースの変形を適用するために使用されます。
これはUnityのSkinnedMeshやUnreal EngineのSkeletal Meshと同様の機能を提供します。
MMDのスケルトンは、一般的なSkinnedMeshスケルトンと同様に、ボーンの階層構造で構成されています。
MMDスケルトンには以下の特殊な特性があります：
変換順序
階層構造を持つスケルトンは通常、トップレベルのボーンから下位レベルのボーンへと順次変換を適用します。
しかし、MMDのスケルトンは異なり、ファイル内で定義されている順序でボーンの変換を計算します。 例外として、別途変換順序を定義しているボーンは異なる計算順序を持ちます。 ボーンが別途定義された変換順序値を持つ場合、その値が計算順序の決定において優先され、その後にファイル内のボーンのリスト順序が考慮されます。
一般的に、変換順序はIKボーンが最後に計算されるようにするために使用されます。
PMDファイルの場合、ボーン情報は別途の変換順序を定義できず、IKボーンには暗黙的に正しい変換順序が割り当てられます。
変換順序とボーン順序が実際の階層と一致しない場合
これは変換順序が正しくない例を示しています。末端のボーンが1フレーム遅れで追従していることがわかります。
MMDはボーンのアニメーション位置を計算し、次のフレームを計算する際にこれらの結果を参照します。 このアプローチは不正確な階層の深さに等しい計算の遅延を生じさせますが、比較的うまく機能するように見えます。
前のフレーム結果に影響されるアニメーション計算は、アニメーション結果を予測不可能にし、ユーザーを混乱させる可能性があります。 そのため、MMDの実装とは異なり、babylon-mmdは新しいフレームを計算する際に前のフレーム計算結果を参照しません。
この実装は、MMDの動作を再現する際に問題が発生した場合、変更される可能性があります。
PMXエディタもbabylon-mmdと同様のアプローチを採用し、現在のフレームのボーンアニメーションを計算する際に前のフレーム結果を参照していません。
ボーンモーフ
ボーンモーフは、事前に定義された特定のオフセットにより、複数のボーンを同時に回転または移動させる機能です。
この機能はPMX仕様に存在し、PMDではサポートされていません。
主に、多くのボーンが一緒に動く必要がある指などの体の部分を効果的に操作するために使用されます。
これについては、以下のモーフセクションで詳しく説明します。
付与親（アペンド変換）
このビデオは準標準ボーン構造で使用される肩への付与親の適用を示しています。モデル：YYB式初音ミク_10th_v1.02（SANMUYYB制作）
付与親は、親子関係にないボーンが階層的に関連しているかのように互いに影響を与えることを可能にします。
この機能はPMX仕様に存在し、PMDではサポートされていません。
付与親はUnityのTransform Constraintコンポーネントに似ています。
後で説明する準標準ボーン構造では、付与親はアニメーターがアニメーションをより簡単に作成できるようにする様々な便利な機能を実装するために使用されます。
IK（逆運動学）
このビデオは脚の動きに適用された逆運動学（IK）を示しています。モデル：YYB式初音ミク_10th_v1.02（SANMUYYB制作）
逆運動学（IK）は、目標位置から逆算して関節角度を自動的に計算する機能です。
MMDでは、IKは主に足と膝の動きを簡単に制御するために使用されます。 例えば、足の位置を指定すると、IKは膝や太ももの角度を自動的に計算し、自然な脚のポーズを作成します。
IKはIKチェーンとIKターゲットで構成されています：
- IKチェーン：IKによって制御される一連のボーン（例：太もも→膝→足首）
- IKターゲット：IKが到達しようとする目標位置を表すボーン
ほぼすべてのMMDモデルの脚にはIKが適用されています。
これにより、異なる身長のモデル間でアニメーションを適用する際に、別途のリターゲティングを必要とせずに足の動きを正しく維持することができます。
標準ボーン構造 / 準標準ボーン構造
MMDのスケルトンには標準化されたボーン構造があり、標準ボーン構造とその拡張版である準標準ボーン構造に分かれています。
標準ボーン構造はMMDでヒューマノイド型モデルを表現するための標準的なボーン構造であり、ほぼすべてのMMDモデルがこの構造に従っています。
準標準ボーン構造は標準ボーン構造をベースにした拡張構造で、2014年以降に作成されたモデルでほとんど使用されているようです。
この標準化された構造のおかげで、MMDアニメーションをロードする際、追加のリターゲティング手順なしでほとんどのアニメーションを簡単に適用できます。
標準ボーン構造の説明
準標準ボーン構造は以下の通りであり、UnityのHumanoidスケルトンやMixamoのRigと似ていますが、いくつかの違いがあります。
/**
* refs:
* https://learnmmd.com/http:/learnmmd.com/mmd-bone-reference-charts/
* https://bowlroll.net/file/9611
*
* mmd standard bone structure:
*
* -全ての親: all parents (semi-standard)
*
* - センター: center
* - グルーブ: groove (semi-standard)
* - 腰: waist (semi-standard)
* - 上半身: upper body
* - 上半身2: upper body 2 (semi-standard)
*
* - 右肩P: right shoulder parent
* - 右肩: right shoulder
* - 右肩C: right shoulder child
* - 右腕: right arm
* - 右腕捩: right arm twist (semi-standard)
* - 右ひじ: right elbow
* - 右手捩: right hand twist (semi-standard)
* - 右手首: right wrist
*
* - 右中指１: right middle finger 1
* - 右中指２: right middle finger 2
* - 右中指３: right middle finger 3
*
* - 右人指１: right index finger 1
* - 右人指２: right index finger 2
* - 右人指３: right index finger 3
*
* - 右小指１: right little finger 1
* - 右小指２: right little finger 2
* - 右小指３: right little finger 3
*
* - 右薬指１: right ring finger 1
* - 右薬指２: right ring finger 2
* - 右薬指３: right ring finger 3
*
* - 右親指０: right thumb 0 (semi-standard)
* - 右親指１: right thumb 1
* - 右親指２: right thumb 2
*
* - 左肩P: left shoulder parent
* - 左肩: left shoulder
* - 左肩C: left shoulder child
* - 左腕: left arm
* - 左腕捩: left arm twist (semi-standard)
* - 左ひじ: left elbow
* - 左手捩: left hand twist (semi-standard)
* - 左手首: left wrist
*
* - 左中指１: left middle finger 1
* - 左中指２: left middle finger 2
* - 左中指３: left middle finger 3
*
* - 左人指１: left index finger 1
* - 左人指２: left index finger 2
* - 左人指３: left index finger 3
*
* - 左小指１: left little finger 1
* - 左小指２: left little finger 2
* - 左小指３: left little finger 3
*
* - 左薬指２: left ring finger 1
* - 左薬指３: left ring finger 2
* - 左薬指４: left ring finger 3
*
* - 左親指０: left thumb 0 (semi-standard)
* - 左親指１: left thumb 1
* - 左親指２: left thumb 2
*
* - 首: neck
* - 頭: head
* - 両目: both eyes
* - 右目: right eye
* - 左目: left eye
*
* - 下半身: lower body
* - 腰キャンセル右: waist cancel right (semi-standard)
*
* - 右足: right leg
* - 右ひざ: right knee
* - 右足首: right ankle
* - 右つま先: right toe
*
* - 右足D: right leg D (semi-standard)
* - 右ひざD: right knee D (semi-standard)
* - 右足首D: right ankle D (semi-standard)
* - 右足先EX: right toe extra (semi-standard)
*
* - 腰キャンセル左: waist cancel left (semi-standard)
*
* - 左足: left leg
* - 左ひざ: left knee
* - 左足首: left ankle
* - 左つま先: left toe
*
* - 左足D: left leg D (semi-standard)
* - 左ひざD: left knee D (semi-standard)
* - 左足首D: left ankle D (semi-standard)
* - 左足先EX: left toe extra (semi-standard)
*
* - 右足IK親: right leg ik parent (semi-standard)
* - 右足ＩＫ: right leg ik
* - 右つま先ＩＫ: right toe ik
*
* - 左足IK親: left leg ik parent (semi-standard)
* - 左足ＩＫ: left leg ik
* - 左つま先ＩＫ: left toe ik
*/
ヒップ位置と親子関係の違い
一般的に、ヒューマノイド型スケルトンはヒップをルートとして次の構造を持っています：
- Hip
- Spine
- LeftUpperLeg
- RightUpperLeg
上記のヒューマノイドスケルトン構造に対応するMMDのスケルトン構造は次のとおりです：
- センター: center **ヒップ領域に対応する頂点ウェイトはこのボーンに割り当てられています！！**
- グルーブ: groove (semi-standard)
- 腰: waist (semi-standard)
- 上半身: upper body - **ヒューマノイドのヒップ位置に対応します！！**
- 下半身: lower body
MMDのスケルトンでは、ヒップ領域の頂点ウェイトはセンターボーンに割り当てられています。 しかし、ヒューマノイドのヒップに対応する位置のボーンは上半身ボーンです。
この異なる構造は、MMDアニメーションを非MMDモデルに適用する際に問題を引き起こし、これを解決するには、センターボーンに対して排他的に特別な処理を行う必要があります。
ヒューマノイドアニメーションをMMDモデルに適用する場合、この構造の違いは問題を引き起こしません。
babylon-mmdは、mixamoアニメーションなどのヒューマノイドアニメーションをMMDモデルに適用するための機能であるAnimationRetargeterを提供しています。
また、MMDアニメーションをヒューマノイドモデルに適用するためのHumanoidMmd機能も提供しています。
HumanoidMmdは上記のセンターボーンに対する例外処理を行います。
肩の構造
- 右肩P: right shoulder parent
- 右肩: right shoulder
- 右肩C: right shoulder child
- 右腕: right arm
準標準ボーン構造では、肩のアニメーションを適用しやすくするために、追加の親ボーンと子ボーンが追加されています。
肩を操作する際、これらのボーンは親ボーンの回転値の量だけ子ボーンを反対方向に回転させ、肩が回転したときに肩の子が回転の影響を受けないようにします。
これは子ボーンに付与親を適用し、親ボーンの回転値を反映することで実装されています。
脚の構造
このビデオは脚の動きに適用された付与親を伴う逆運動学（IK）を示しています。モデル：YYB式初音ミク_10th_v1.02（SANMUYYB制作）
- センター: center
- グルーブ: groove (semi-standard)
- 腰: waist (semi-standard)
- 下半身: lower body
- 腰キャンセル右: waist cancel right (semi-standard)
- 右足: right leg
- 右ひざ: right knee
- 右足首: right ankle
- 右つま先: right toe
- 右足D: right leg D (semi-standard)
- 右ひざD: right knee D (semi-standard)
- 右足首D: right ankle D (semi-standard)
- 右足先EX: right toe extra (semi-standard)
- 右足IK親: right leg ik parent (semi-standard)
- 右足ＩＫ: right leg ik
- 右つま先ＩＫ: right toe ik
右足だけを見てみましょう。左足も同じ構造を持っています。
- 右足IK親: right leg ik parent (semi-standard)
- 右足ＩＫ: right leg ik
- 右つま先ＩＫ: right toe ik
標準ボーン構造では、脚にIKが適用されています。
右足ＩＫと右つま先ＩＫはIKターゲットボーンとして使用されます。これらはそれぞれ足の位置とつま先の位置を表します。
- 右足: right leg
- 右ひざ: right knee
- 右足首: right ankle
- 右つま先: right toe
- 右足D: right leg D (semi-standard)
- 右ひざD: right knee D (semi-standard)
- 右足首D: right ankle D (semi-standard)
- 右足先EX: right toe extra (semi-standard)
準標準構造でのみ、同じ構造の脚のボーンが2回定義されていることがわかります。
DサフィックスのあるボーンはFK操作用のボーンであり、サフィックスのないボーンはIKによって制御されるIKチェーンボーンです。
Dサフィックスのあるボーンは、付与親を使用してIK計算結果にオフセットを適用することで脚を操作します。
その結果、IKを使用しながらも、細かい調整が必要な場合にFKを一緒に使用することができます。
モーフ
モーフはモデルの形状を変更する機能で、主にスケルトンでは表現が難しいMMDモデルの顔の表情や口の形を制御するために使用されます。
これはUnityのブレンドシェイプやBlender 3Dのシェイプキーに似ていますが、追加機能を持っています。
頂点モーフ
顔の形状を変える頂点モーフの例。モデル：YYB式初音ミク_10th_v1.02（SANMUYYB制作）
頂点モーフは、頂点位置を変更してモデルの形状を変える機能です。
ボーンモーフ
手を動かすボーンモーフの例。モデル：YYB式初音ミク_10th_v1.02（SANMUYYB制作）
ボーンモーフは、事前に定義された特定のオフセットにより、複数のボーンを同時に回転または移動させる機能です。 PMDはこの仕様をサポートしていません。
ボーンモーフは主に、指のように多くのボーンが一緒に動く必要がある体の部分を効率的に制御するために使用されます。
UVモーフ
UVモーフは、UV座標を変更してモデルの外観を変える機能です。 PMDはこの仕様をサポートしていません。
これは主にテクスチャマッピングを変更したり、アニメーションテクスチャを作成したりするためのエフェクトに使用されます。
マテリアルモーフ
髪の影メッシュのオン/オフを切り替えるマテリアルモーフの例。モデル：YYB式初音ミク_10th_v1.02（SANMUYYB制作）
マテリアルモーフは、マテリアルのプロパティを変更してモデルの外観を変える機能です。 PMDはこの仕様をサポートしていません。
これにより、マテリアルの色、透明度、またはその他のマテリアルプロパティを実行時に変更するなどのエフェクトが可能になります。
フリップモーフとインパルスモーフもあります。
これらはPMX 2.1仕様で追加されたもので、ほとんどのMMDモデルではほとんど使用されないため、babylon-mmdはこれらを実装していません。
グループモーフ
グループモーフは、複数のモーフをグループ化して単一のモーフとして制御できるようにする機能です。
表示枠
MMDのタイムラインパネルに表示されるボーンとモーフのリスト。モデル：YYB式初音ミク_10th_v1.02（SANMUYYB制作）
MMDとは異なり、babylon-mmdはアニメーション編集機能を提供していないため、このデータは使用されません。
このデータは、mmdmodel.preserveSerializationDataオプションがtrueの場合、メタデータとして保存されます。
物理演算
MMDでの物理ボディの可視化（黄色：キネマティック剛体、赤：ダイナミック剛体）モデル：YYB式初音ミク_10th_v1.02（SANMUYYB制作）
MMDはBullet Physics 2.75を使用して剛体動力学シミュレーションを実行し、モデルの髪や服の物理的な動きを表現します。
これを可能にするために、PMX/PMDファイルにはボーンを参照する剛体と、剛体同士を接続する制約に関する情報が含まれています。
剛体は主にダイナミックとキネマティックの2つの主要なタイプに分類されます。
ダイナミック剛体
特定のボーンがダイナミック剛体によって参照される場合、そのボーンのトランスフォームは階層を無視し、物理エンジンによって制御されます。
キネマティック剛体
特定のボーンがキネマティック剛体によって参照される場合、その剛体のトランスフォームはボーンによって制御されます。
制約
制約は2つの剛体を互いに接続します。
通常、複数の剛体が髪や服を表現するために鎖のような形成で接続され、制約はそれらを互いに接続するために使用されます。
babylon-mmdはBullet Physics 3.26を使用しています。
Bullet Physics 3.26と2.75の間の制約ソルバーの実装の違いにより、一部のモデルの物理計算はbabylon-mmdで奇妙に動作する可能性があります。
これを解決するために、babylon-mmdはMmdModelPhysicsCreationOptions.disableOffsetForConstraintFrameオプションを提供しており、これにより2.75バージョンの制約ソルバーロジックを使用することができます。
このオプションをtrueに設定すると、MMDの物理計算により近い結果を達成できます。
ただし、2.75バージョンの実装では、数値的不安定性により剛体が振動するアーティファクトが発生する可能性があります。
PMX 2.1仕様にはソフトボディ物理仕様が含まれていますが、前述のように、2.1仕様については議論しません。