3ds Max → Unity FBX エクスポート完全ガイド
Markdownダウンロード 画像込みダウンロード3ds Maxでリグ・スキニングしたキャラクターをUnityへ正しくインポートするための標準手順です。
「なぜこうするのか」を理解すれば、シーンが変わっても自分で対応できます。
0. 成功基準 — この画面が出れば完了
FBXをUnityにドラッグ＆ドロップし、Root（最上位オブジェクト）を選択したとき、InspectorのTransformが以下の値になっている必要があります。
| 項目 | 値 |
|---|---|
| Position | 0, 0, 0 |
| Rotation | 0, 0, 0 |
| Scale | 1, 1, 1 |
なぜこの値が重要か?
Rootが0 / 0 / 1でクリーンであれば、Prefab化・アニメーションリターゲット・物理・コライダー計算がすべて予測可能になります。
Scaleが0.01、Rotationが-90で入ると、その誤差が子ボーン・メッシュ・アニメーション全体に蓄積され、後から原因を追うのが非常に困難になります。問題はインポート時点で解決するのが最善です。
1. なぜ座標と単位がずれるのか（必須の背景知識）
3ds MaxとUnityは座標系とデフォルト単位が異なります。 FBXファイルがその間を翻訳する橋渡し役を担いますが、exportオプションが間違っていると翻訳がずれて上記の値が崩れます。
| 項目 | 3ds Max | Unity |
|---|---|---|
| Up軸（上方向） | Z-up（ZがSky） | Y-up（YがSky） |
| 座標系の手 | 右手座標系 | 左手座標系 |
| 内部長さ単位 | シーン単位自由（cm推奨） | 1 unit = 1 meter 固定 |
重要なポイントは2つです。
- 軸: MaxのZ-upをUnityのY-upに変換しないとキャラクターが横に倒れます。
- 単位: Unityは「1 = 1メートル」が絶対固定です。Maxをcmで作業すると1cm = 0.01mなので、FBXがその100倍の差を正しく吸収しないとScaleが
0.01のまま残ります。
このガイドのすべてのステップは、結局「軸をY-upに、単位をcm基準に」合わせるためのものです。
2. STEP 1 — シーン単位の確認（cm基準）
まずMaxシーンの単位を確認します。Customize > Units Setupメニューに入ります。
Display Unit ScaleをMetric → Centimetersに設定します。
なぜcmか?
BipedPlusの内部計算（高さ・スケールなど）がcmを基準（SSOT）としています。また、Maxの標準exportの慣例がcmなので、cmに合わせておくと後のFBX単位変換が最もきれいに一致します。
スタジオのパイプラインがm（メートル）固定でも、少なくともリグ・exportの段階ではcm推奨です。（mシーン対応はツール改善予定）
3. STEP 2 — 軸の整列（Z-up → Y-up）
MaxはZ-up、UnityはY-upです。export前にRootを基準にUnityの慣例（Y上、Z前）に合わせて方向を整列します。
3ds Max基準でYを上、前方（正面）をZ軸にするとUnityの方向に合います。
整列方法：Rootを選択し、ワールド基準でX軸+90°回転します。（Rotate Transform Type-In → Absolute:World X = 90）
なぜX軸90°か?
Z-up空間をY-up空間に変換するには上方向ベクトルをZからYへ90°回転させる必要があります。この回転が2つのエンジンの「上方向」定義の差を埋める値です。
4. STEP 3 — Export対象の選択（スキンボーン + メッシュのみ）
exportする際はスキンボーンツリー + メッシュ（ジオメトリ）のみを選択します。コントローラー・ヘルパー・リググループ（Ctrl_World、Grp_Rig、Drv_Rootなど）は含めません。
なぜリグ全体を含めてはいけないか?
Unityが実際に必要とするのはスキンドメッシュ + それを動かすスケルトンだけです。リグコントローラー/ヘルパーはゲームエンジンでは不要なだけでなく、
- 不要なボーン階層が増えてインポートが重くなり、
- スケール・オフセットがかかったコントロールノードが混入することでScale 0.01のような汚染を引き起こします。
原則：「ゲームに必要なものだけ」エクスポートする。
5. STEP 4 — FBX Exportオプション
(1) Include — アニメーション＆デフォーメーション
- Animation チェック
- Deformations → Skins, Morphs チェック（スキンウェイトとモーフが一緒に出力される必要あり）
(2) Advanced Options — 単位＆軸
最も重要な部分です。前述の単位・軸変換がここで最終決定されます。
| オプション | 値 | 意味 |
|---|---|---|
| Units → Automatic | チェック | シーン単位を自動検出して変換 |
| Scene units converted to | Centimeters | シーンがcmなのでcmで出力 |
| Scale Factor | 1.0 | 追加倍率なし（変換は単位が担当） |
| Axis Conversion → Up Axis | Y-up | UnityのUp軸に合わせる |
なぜこの組み合わせか?
Scale Factor 1.0 + cm + Y-upにすると、Unityがインポート時にcm→m（÷100）と軸変換を自動で吸収し、Root Scaleが正確に1.0になります。Scale Factorを勝手に変えると100倍/0.01倍の誤差が再び生じます。
UnityのUp軸はYなので、必ずY-upでエクスポートします。
6. STEP 5 — Unityでの検証
FBXをUnityに取り込み、Rootを選択して[0. 成功基準]と同じかどうか確認します。
- Position 0, 0, 0
- Rotation 0, 0, 0
- Scale 1, 1, 1
ここまで合っていれば正常インポート完了です。
7. よくある失敗＆トラブルシューティング
失敗1 — Root Scaleが0.01で入ってくる
デフォルト値でないRootボーンを含めてはいけません。
原因: トランスフォームがリセット（デフォルト値）されていないRoot/コントロールノードをexportに含めた場合です。そのノードにかかっている0.01スケール（またはcm↔m未変換分）がそのままUnity Rootにbake-inされます。
解決方法:
- Exportの対象からコントローラー/ヘルパーのRootを除外し、トランスフォームがクリーンなスキンボーンツリー + メッシュのみエクスポートします。（STEP 3参照）
- FBXオプションのScale Factorが1.0、Units = Centimetersかどうか再確認します。
Q&A — Scaleに0.9999999が入ってきます。問題ですか?
結論：正常です。 3Dグラフィックスは値を浮動小数点（floating point）で保存するため、複数の行列変換（回転・単位換算など）を経ると1.0が0.9999999のように微細にずれることがあります。これはエラーではなく演算の自然な丸め結果であり、実使用に影響はありません。
それでもきれいに1.0にしたい場合: 該当ノードのトランスフォームをPRSチャンネルでリセットし、PositionをPosition Constraint、RotationをOrientation Constraintに置き換えます。（Transform Scriptの代わりに純粋なPRSで整理）
こうすることで累積誤差なく値が整理されます。
8. 最終チェックリスト
エクスポート前にこの5点だけ確認すれば大丈夫です。
- [ ] 単位: シーンがCentimeters（
Customize > Units Setup） - [ ] 軸: RootをWorld X +90° 回転（Y-up整列）
- [ ] 選択: スキンボーンツリー + メッシュのみ（コントローラー・ヘルパー除外）
- [ ] FBXオプション: Units
Automatic / cm、Scale Factor1.0、Up AxisY-up、Animation・Skins・Morphsチェック - [ ] Unity検証: Root Transform =
0/0/0 · 0/0/0 · 1/1/1
0.9999999のスケールは正常な誤差です。気になる場合のみPRSリセット + Constraintで整理します。