---

# biped-initial-setup

> slug: biped-initial-setup

3ds Maxでリギングを始める際、最初に出会うBiped。しかし、デフォルト設定のまま使うと、後のエンジン段階で大きな問題が生じる可能性があります。安定したパイプラインのために、以下の設定を必ずご確認ください。

## 1. 階層構造の論理的エラーの修正

![image.png](biped-initial-setup/image.png)

Bipedの初期ジョイント構造は、かつてのスキニング方法に合わせて設計されており、現代のエンジン環境では多少非論理的な構造となっています。

- **問題点:** デフォルト設定では、`Thigh`（太もも）が`Spine`（背骨）の下に、`Clavicle`（鎖骨）が`Neck`（首）の下に従属する場合があります。
- **発生する問題:** エンジンでキャラクターが頭を回したり、背骨を補正するアニメーション機能を追加する際、背骨を動かすと脚もついてくるなど、構造が非常に複雑に絡まってしまいます。

### ✅ 必須チェック事項 (Figure Mode)

![image_1.png](biped-initial-setup/image_1.png)

![image_2.png](biped-initial-setup/image_2.png)

リギングセットアップ前に、**Figure Mode**で以下の2つを必ず設定してください。

- **Triangle Pelvis（三角形の骨盤）:** 必ず**チェック**（脚の階層構造を骨盤に正しく帰属させます。）
- **Triangle Neck（三角形の首）:** 必ず**チェックを外す**（鎖骨と首の階層構造を論理的に分離します。）

---

## 2. 正確なピボット確認のためのモード変更

![image_3.png](biped-initial-setup/image_3.png)

精密なリギングのためには、骨の中心点を正確に把握することが重要です。

- **Body TypeをClassicに変更:** BipedをBox形態に変更する際、最も正確なピボット位置を視覚的に確認できるモードです。
- **Box Modeを有効化:** Bipedを全選択してBox Modeをオンにすると、作業効率が大幅に向上します。

---

## 3. プロダクション標準リンク設定（推奨）

プロジェクトにより異なる場合がありますが、一般的に最も安定したデータ値を推奨します。セットアップ作業の際にご参照ください。

| **項目** | **推奨設定値** | **備考** |
| --- | --- | --- |
| **Spine Links（背骨）** | **3個** | 最も自然な曲線を表現します。 |
| **Fingers（指の数）** | **5個** | ヒューマノイドキャラクターの標準 |
| **Finger Links（関節）** | **3個** | 実際の指の関節構造と同じ |
| Porp | 1個 | Biped用プロップ |

---

**ご案内した設定を完了させることで、後にエンジンでアニメーション後補正作業を行う際、TAチームとエンジンチームの労力を軽減できます。**
@@

---

# rigging-master-path-setup

> slug: rigging-master-path-setup

https://youtu.be/qGYcZd67eNA?si=43ssOehRsUKK2pIi

# 3ds Max リギングマスターパス設定ガイド — プロジェクト構造のセットアップ

# 🗂️ 整えるべき作業環境

> Fast Refを100%活用するためのパイプライン構築提案

### 0. レファレンスパイプラインの概要 (Best Practice)

基本的に、リギング原本とアニメーションデータは以下のように分けて管理するのが定石です。

| **区分** | **リギング原本 (Rig)** | **アニメーションファイル (Ani)** |
| --- | --- | --- |
| **アニメーションデータ** | **X (空)** | **O (データあり)** |
| **リギングリンク状態** | 原本ファイル | リギングファイルが**リンク**された状態 |

> 💡 ご案内: ただし、3ds Maxベースのゲームアニメーション制作環境の特性上、このレファレンスベースのパイプライン方式は、やや馴染みがなかったり既存の作業方式と異なる場合があります。これは効率的なコラボレーションのための構造ですので、以下の解決策をご参照ください。

![image.png](rigging-master-path-setup/image.png)

## 1️⃣ チーム共有ドライブ環境の構築

### 推奨事項

- **NAS** または **仮想ドライブ** を使ってチーム内の **共有ドライブ** を設置
- 例: `N:\` ドライブ、`Z:\` ドライブなど

### ⚠️ NAS推奨の理由

| 方式 | メリット・デメリット |
| --- | --- |
| **NAS（推奨）** | ✅ 同期が速い、SSDベースの機器が多い |
| Googleドライブ | ❌ 同期が遅い → 作業に支障 |

---

## 2️⃣ リギングマスターデータ構造

### 核心原則

> 「リギング用マスターフォルダー」を別途作成し、
> チーム内のアニメーション作業時は必ずそのパスのファイルのみを読み込む

### 📁 推奨フォルダー構造

```
project_name (英語推奨)
│
└── rig
    │
    └── lilly (キャラクター名)
        │
        ├── lilly_rig.max        ← 🎯 マスターファイル（現在最新）
        │
        ├── texture/             ← テクスチャフォルダー
        │   └── 画像ファイル...  ← ⚠️ 必ず相対パスでリンク！
        │
        └── old/                 ← バックアップフォルダー
            ├── lilly_000_rig.max
            ├── lilly_001_rig.max
            └── ...              ← 自由に作業データをバックアップ
```

### 🎯 核心ポイント

| 項目 | 説明 |
| --- | --- |
| **マスターファイル** | 常に最新のリグだけをルートに配置 |
| **oldフォルダー** | 以前のバージョンのバックアップ用 |
| **texture** | 相対パスリンク必須！ |

---

## 3️⃣ パス規則（非常に重要！⚠️）

### ❌ 絶対禁止

```
C:\프로젝트\캐릭터\릴리_리그.max     ← 韓国語パス ❌
C:\project (복사본)\rig\lilly.max   ← 特殊文字 ❌
```

### ✅ 推奨

```
C:\project_present\rig\lilly\lilly_rig.max  ← 英語のみ ✅
```

### 🤔 なぜ韓国語パスが使えないの？

```
Pythonスクリプト使用時にエンコーディング問題が発生！

問題:
  - UTF-8とCP949など、プログラムごとに文字処理方式が異なる
  - パス認識失敗 → エラー発生確率 ↑↑

結論:
  - パイプラインの自動化のために英語パスは必須！
```

---

## 4️⃣ データ整理の推奨

### 現状（推定）

- アニメーションフォルダーにリギングデータが混在している
- どのファイルが最新か把握が難しい

### 整理の方向性

```
Before:
  animation/
    ├── shot_001.max
    ├── lilly_rig_v3.max      ← リギングファイルが混在
    └── shot_002.max

After:
  rig/                        ← リギング専用
    └── lilly/
        └── lilly_rig.max

  animation/                  ← アニメーション専用
    ├── shot_001.max          ← Fast Refでリグを連結
    └── shot_002.max
```

---

## 5️⃣ チーム内ルールの遵守（初期適応）

### 実施方針

- 最初はやや不便に感じるかもしれません
- **最低1ヶ月**はこのルールを厳格に遵守する
- その後、文化として定着します

### 📊 実際の事例（Blenderベースの会社）

```
適用期間: 1〜2ヶ月

結果:
  ✅ 「リギング同期」パイプライン文化の定着
  ✅ アニメーション作業の生産性向上
  ✅ 混乱が顕著に改善（約15%以上）
```

---

## 📋 チェックリスト

```
□ チーム共有ドライブの設定（NAS推奨）
□ リギングマスターフォルダー構造の作成
□ 既存データの整理（時間を確保して）
□ パス規則の共有（韓国語禁止！）
□ 1ヶ月ルール遵守の約束
```

---

> "このようなパイプライン構築は、長期的に作業効率化に大きく役立つでしょう！" 🚀
@@

---

# naming-convention-guide

> slug: naming-convention-guide

リギングとアニメーションパイプラインにおける一貫したネーミング規則は、単なる約束事を超え、プロジェクトの安定性を決定する重要な要素です。

## 1. ネーミングルールの重要性

自動化システムと効率的なコラボレーションのために、プロジェクトごとのルール遵守は必須です。たとえば、エンジンチームが`Root`ボーンを基準にシステムを構築しているのに、データが`root`や`world`のような任意の名前で送られてくると、パイプライン全体に大きな支障をきたす可能性があります。

## 2. ネーミングの基本構成要素

- **プレフィックス（接頭辞）：** 名前の前に付けて、オブジェクトの性質（Control、Skinなど）を定義します。
- **サフィックス（接尾辞）：** 名前の後に付けて、方向（L、R）や状態を示します。

## 3. 主要なネーミングケース

プロジェクトの性質に応じて適切な表記法を選択します。

- **パスカルケース：** `RootNode`（各単語の最初の文字を大文字にする）
- **スネークケース：** `root_node`（単語の間をアンダースコア`_`でつなぐ）
- **キャメルケース：** `rootNode`（最初の単語は小文字、以降の単語の頭文字は大文字）

## 4. 3ds Max Biped構造の理解と分析

3ds Maxの標準であるBiped（`Bip001 L Foot`）をよく見てみると、重要なルールを発見できます。

> **「なるほど！3ds Maxでは基本的にパスカルケースを採用し、単語の区切りにスペース（" "）を使っているんだ！」**

熟練した作業者であれば、既存のデータを見て **{タイプ} {方向} {部位}** というルールを読み取れるはずです。新しいプロジェクトに参加した際も、この流れを尊重して作業する柔軟性が求められます。

## 5. 実務上の推奨事項：スペース禁止・アンダースコア（`_`）の使用

既存のBipedデータにはスペースが含まれている場合が多いですが、現代的なパイプラインでは**アンダースコア（`_`）**の使用を強く推奨します。

- **理由：** スペースはMayaとの互換性問題、エンジン移行時の特殊文字置換エラーなどの原因となり、スクリプト実行時に構文エラーを引き起こす主な要因にもなります。
- **解決策：** 既存のBipedボーン名はそのまま維持し、追加のセットアップ（Controlなど）には`Ctrl_L_Prop1`のようにアンダースコアを明確に使用してください。

---

## 💡 結論：3ds Max リギングネーミングの正石

3ds Maxのリギング環境では、最も広く使われている**Bipedをベース**にするのが最善です。

1. **基本文法：** パスカルケースを基本とし、単語の区切りはエラー防止のためにスペースではなく**アンダースコア（`_`）**を使用します。
2. **Bipedボーン：** 既存Bipedシステムのボーン名は標準なので、そのまま維持します。
3. **拡張ノード：** 追加するコントローラーや補助ボーンは、Bipedの部位名称と統一感を持たせるのが理想的です。

---

## 📌 よく使われるネーミングリスト

チーム内で参考にできるよう、実務でよく使われる名称をまとめました。

### **プレフィックス（タイプリスト）**

- **`Ctrl_`**: アニメーターが実際にキーを打つコントローラー要素
- **`Off_`**: コントローラーの親となるオフセットグループ（修正・管理用）
- **`Skin_`**: メッシュにスキンノードとして割り当てられる実際のボーン
- **`Pt_`**: ポイント、主にリギングシステム内で活用される補助ノード

### **ミドル（方向と位置）**

- **`L` / `R`**: 左（Left）/ 右（Right）
- **`C` / `M`**: 中央（Center/Middle）— 通常は省略可能です。

### **サフィックス（部位名称）**

部位名はできる限り**Bipedの名称と統一する**ことが最善です。

- **推奨例：** `Ctrl_L_Calf`（○）/ `Ctrl_L_Knee`（×）
- **理由：** 膝の部位であっても、Bipedの実際のボーン名が`Bip001 L Calf`であれば、混乱を避けるために`Calf`ベースで名前を合わせるのが効率的です。
- **主要名称：** `Thigh`、`Calf`、`Foot`、`Spine`、`Neck`、`Clavicle`など
@@

---

# bone-option-pitfalls

> slug: bone-option-pitfalls

こんにちは、**OtakuSolutions**です。

本日は、リギング入門者から現場のプロまで、意外と多くの方が見落としている**3ds Max Boneオプションの落とし穴**と、それによって起こる**実際のトラブル事例**をご紹介します。

### 😱 実際の事例：「アニメーションを読み込んだらキャラクターが崩れました」

リギング作業をしていると、このような困惑する状況に出くわすことがあります。

1. **事例A（エンジンとの不一致）：** Maxのビューポートではボーンの**スクワッシュ（Squash）**効果がしっかり効いているのに、エンジン（Unity/Unreal）にアップロードするとキャラクターのシェイプがまったく動かないケース。
2. **事例B（データの幽霊）：** アニメーションデータを保存（Save/Load Animation）して読み込み直したら、触ったはずのない**ボーンに異常なスケール（Scale）値**が発生し、リギングが歪んでしまうケース。

---

### 🔍 なぜこんなことが起きるのでしょうか？

#### 1. ビューポートの「視覚的レンダリング」vs「実際のデータ」の違い

Boneオプションのストレッチとスクワッシュは、**3ds Maxのビューポート内でのみ**それらしく見える「偽の変形」です。

- **実際のデータ：** Transform（Position、Rotation、Scale）の値はまったく変化しません。
- **結果：** エンジンは「データ」をもとに動作するため、データが変わっていないボーンはエンジンでは当然動きません。Maxの画面だけ見て「おお、うまくいってる！」と思っていたら、エンジンで痛い目を見ることになります。

#### 2. アニメーション読み込み時に発生するデータの混乱

さらに大きな問題は、アニメーションデータを再利用する際に発生します。Boneオプションが有効な状態でアニメーションを保存・読み込みすると、Maxがこの「視覚的変形」を「データ」へ無理やり変換しようとしてエラーを起こします。

- **結果：** 存在しなかった**スケール値が1.1や0.9**のように勝手に入り込み、リグの差し替えやアニメーションの再利用時に作業全体が狂ってしまいます。

---

### 💡 プロリガーの解決策：「正直なリギング」

プロのゲームリガーであれば、便法オプションに頼らず**正攻法**を使うべきです。

- **LookAt Constraint & Script Controller：** ボーンの長さを調整したい場合は、2点間の距離を計算して**実際のScale値**が変化するようにリギング構造を自分で設計してください。
- **データの透明性：** そうすることで初めてエンジンでも同じ結果が得られ、アニメーションデータをやり取りする際も数値がズレません。

---

### 🚀 [Tool] 事故防止用：Boneオプション一括オフスクリプト

すでに作業済みのボーンが不安な場合は、以下のスクリプトですべてのボーンの「目くらましオプション」を一括解除してください。正しいリギングに戻るための第一歩です。

```maxscript
-- Bone의 가짜 스트레치/스쿼시 옵션을 완전히 끄고 데이터 혼선을 막습니다.
for b in objects where classof b == BoneGeometry do (
    b.realignSelf = false
    b.freezeLength = false -- 길이 고정 해제 (데이터 계산 방해 방지)
    b.stretch = #none      -- 가짜 스트레치 해제
    b.sidefin = false      -- (선택사항) 불필요한 핀 제거
    print (b.name + " : Clean up completed.")
)
```

---

### 📝 まとめ

> **「リギングは目ではなく、『データ』で行うものです。」**
> 便利そうに見えるBoneオプションですが、ゲームプロダクションではむしろ害になることがあります。今すぐご自身のボーン設定を確認してみてください！
@@

---

# 3ds Max → Unity FBX エクスポート完全ガイド

> slug: max-to-unity-fbx-export

3ds Maxでリグ・スキニングしたキャラクターを**Unityへ正しくインポート**するための標準手順です。
「なぜこうするのか」を理解すれば、シーンが変わっても自分で対応できます。

---

## 0. 成功基準 — この画面が出れば完了

FBXをUnityにドラッグ＆ドロップし、**Root**（最上位オブジェクト）を選択したとき、InspectorのTransformが以下の値になっている必要があります。

| 項目 | 値 |
|------|-----|
| **Position** | 0, 0, 0 |
| **Rotation** | 0, 0, 0 |
| **Scale** | 1, 1, 1 |

![目標 - Unityシーン全体](max-to-unity-fbx-export/image.png)

![目標 - Root Transform](max-to-unity-fbx-export/image_1.png)

**なぜこの値が重要か?**
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`メニューに入ります。

![Units Setupメニューの場所](max-to-unity-fbx-export/image_2.png)

`Display Unit Scale`を**Metric → Centimeters**に設定します。

![Units Setup - Centimeters](max-to-unity-fbx-export/image_3.png)

**なぜ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前）に合わせて方向を整列**します。

![Maxリグ階層と軸](max-to-unity-fbx-export/image_4.png)

> 3ds Max基準で**Yを上、前方（正面）をZ軸**にするとUnityの方向に合います。

整列方法：Rootを選択し、**ワールド基準でX軸+90°回転**します。（Rotate Transform Type-In → `Absolute:World` X = 90）

![World X +90°回転](max-to-unity-fbx-export/image_5.png)

**なぜX軸90°か?**
Z-up空間をY-up空間に変換するには上方向ベクトルをZからYへ90°回転させる必要があります。この回転が2つのエンジンの「上方向」定義の差を埋める値です。

---

## 4. STEP 3 — Export対象の選択（スキンボーン + メッシュのみ）

exportする際は**スキンボーンツリー + メッシュ（ジオメトリ）のみ**を選択します。コントローラー・ヘルパー・リググループ（`Ctrl_World`、`Grp_Rig`、`Drv_Root`など）は**含めません。**

![スキンボーン + メッシュツリーのみ選択](max-to-unity-fbx-export/image_6.png)

**なぜリグ全体を含めてはいけないか?**
Unityが実際に必要とするのは**スキンドメッシュ + それを動かすスケルトン**だけです。リグコントローラー/ヘルパーはゲームエンジンでは不要なだけでなく、

- 不要なボーン階層が増えてインポートが重くなり、
- スケール・オフセットがかかったコントロールノードが混入することで**Scale 0.01のような汚染**を引き起こします。

> 原則：**「ゲームに必要なものだけ」エクスポートする。**

---

## 5. STEP 4 — FBX Exportオプション

### (1) Include — アニメーション＆デフォーメーション

- **Animation** チェック
- **Deformations → Skins, Morphs** チェック（スキンウェイトとモーフが一緒に出力される必要あり）

![FBX Includeオプション](max-to-unity-fbx-export/image_7.png)

### (2) Advanced Options — 単位＆軸

最も重要な部分です。前述の単位・軸変換がここで最終決定されます。

| オプション | 値 | 意味 |
|------------|-----|------|
| **Units → Automatic** | チェック | シーン単位を自動検出して変換 |
| **Scene units converted to** | **Centimeters** | シーンがcmなのでcmで出力 |
| **Scale Factor** | **1.0** | 追加倍率なし（変換は単位が担当） |
| **Axis Conversion → Up Axis** | **Y-up** | UnityのUp軸に合わせる |

![FBX単位・軸オプション](max-to-unity-fbx-export/image_8.png)

**なぜこの組み合わせか?**
`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`で入ってくる

![悪い例 - Scale 0.01](max-to-unity-fbx-export/image_9.png)

> **デフォルト値でない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`が入ってきます。問題ですか?

![Scale 0.9999999](max-to-unity-fbx-export/image_10.png)

**結論：正常です。** 3Dグラフィックスは値を**浮動小数点（floating point）**で保存するため、複数の行列変換（回転・単位換算など）を経ると`1.0`が`0.9999999`のように微細にずれることがあります。これはエラーではなく**演算の自然な丸め結果**であり、実使用に影響はありません。

**それでもきれいに`1.0`にしたい場合**: 該当ノードのトランスフォームを**PRSチャンネルでリセット**し、Positionを**Position Constraint**、Rotationを**Orientation Constraint**に置き換えます。（Transform Scriptの代わりに純粋なPRSで整理）

![Transform Script → PRS + Constraint](max-to-unity-fbx-export/image_11.png)

こうすることで累積誤差なく値が整理されます。

![整理後 - Scale 1.0](max-to-unity-fbx-export/image_12.png)

---

## 8. 最終チェックリスト

エクスポート前にこの5点だけ確認すれば大丈夫です。

- [ ] **単位**: シーンがCentimeters（`Customize > Units Setup`）
- [ ] **軸**: RootをWorld X **+90°** 回転（Y-up整列）
- [ ] **選択**: スキンボーンツリー + メッシュのみ（コントローラー・ヘルパー除外）
- [ ] **FBXオプション**: Units `Automatic / cm`、Scale Factor `1.0`、Up Axis `Y-up`、Animation・Skins・Morphsチェック
- [ ] **Unity検証**: Root Transform = `0/0/0 · 0/0/0 · 1/1/1`

> `0.9999999`のスケールは正常な誤差です。気になる場合のみPRSリセット + Constraintで整理します。