---

# Ep.0 — なぜ Fast-Ref が必要なのか？(XRef の限界とプラグインの必要性)

> slug: ep00_why-fast-ref

https://youtu.be/IZtPFC-p7cI?si=oNNagK1RFl36iu-M

> **要約**: 3ds Max 標準の XRef の機能的な限界を徹底解剖し、実務アニメーションパイプラインで Fast-Ref が不可欠なソリューションである背景を解説します。

---

## 1. 現場で直面する大惨事（オープニングシナリオ）

3ds Max でアニメーション作業に集中しているアニメーターの元へ、ある日リードから衝撃的な連絡が届きます。
> **「キャラクターのボーン構造が全面改修される予定です。」**

ジャケット・スカート・帽子パーツの追加にとどまらず、ボーンの命名規則まで小文字の `root` から大文字の `Root` へ変更されると言います。
このキャラクターを使うファイルが1つだけなら、まだ救いがあります。しかし **Walk、Idle、Attack、Run などの数十のアクションクリップ** から始まり、そのキャラクターが登場する **100〜200 件のシネマティックシーンファイル** が蜘蛛の巣のように絡み合っているとしたら、どうでしょうか？

リグファイルが修正されたというだけで、アニメーターはこれら 200 件以上のファイルを 1 件ずつ手動で開いて更新しなければならない、悪夢のような重労働に直面します。これが、アニメーターが抱える最も重くて苦しいプロダクションリスクです。

---

## 2. 3ds Max の 'XRef Objects' をキャラクターリファレンスに使うと？

3ds Max で外部ファイルを参照する方法を探すと、まず目に入るのが標準機能の **XRef（外部参照）** です。デモキャラクター Mable を使って XRef Objects 機能を実際にテストしました。（テスト環境：3ds Max 2027）

XRef Objects メニューからキャラクターをロードすると、見た目は正常に表示されます。しかし実際にアニメーションキーを打ち始めると、深刻な問題が噴出します。

### 🔴 実務アニメーション適用時の致命的な限界
* **基本ボーンのキー打ち**：単純なジャンプポーズ程度はキーが入るように見えますが、不安定です。
* **カスタムアトリビュート消失**：リガーがセットアップした指コントローラーや表情アトリビュートなどのカスタムデータが画面に表示されなかったり、キーを打ってもタイムラインに登録されなかったりします。シーングラフを確認すると、元のカスタムアトリビュートデータは丸ごと消え、「XRef Object」という外殻だけが残っています。
* **リグファイル差し替え（Replace）時の崩壊**：同じ骨格を持つ別バージョンのリグファイルに差し替えようとすると、**リグ構造全体が粉砕されて壊れる現象**が発生します。
* **保存・再オープン時のデータ消失**：無理やりキーを打って保存し、再度ファイルを開くと、コントローラーのデータリンクが切れ、**打ったキーデータが完全に消えています。**

> **💡 結論**：3ds Max の標準 XRef は、キャラクターアニメーション用のリファレンス機能ではありません。Arch-Viz やアニメーションのない単純な小道具・オブジェクト配置を想定した機能です。世界中のどのプロダクションも XRef をメインのキャラクターアニメーションパイプラインに使えていない理由がここにあります。

---

## 3. Maya と Blender はどうなのか？（比較）

* **Maya（Reference）**：キャラクターのロード速度が圧倒的に速く、'R' マークで参照状態が明確に表示されます。セットアップ済みのカスタムアトリビュートが完璧に維持され、Auto Key なしでも **S** キーで全チャンネルに完璧にキーを打てます。リロードや差し替えでもデータ消失は一切ありません。世界中の Maya ベーススタジオの中核技術です。
* **Blender（Link）**：Maya ほど直感的ではありませんが、Link 機能を使ったリファレンスパイプラインはかなり優秀で、多くのチームが実務で活用しています。

このように他ツールでは、リファレンスベースのワークフローが基本かつ標準ですが、3ds Max はこの領域のソリューションが長年不在でした。

---

## 4. 「最初から完璧なリグを作って配布すればいいでしょう？」

10 年以上アニメーション TA として従事した発表者は、**一度も一発で完成したリグファイルを見たことがありません。**
* 一般的なサブキャラクターでも基本 **2〜3 回**のリグリビジョン（修正）を経ます。
* メインキャラクターは平均 **10 回以上**、酷いプロダクションでは修正依頼が **20 回、40 回、さらには 50 回**に達することもあります。

ゲームのリリース時にバグがゼロというのが不可能なように、無数のボーンとコントローラーが複雑に絡み合ったリギングも、人間が作るシステムである以上、修正なしの完璧は存在しません。アニメーターがリグ更新を避けられないなら、**更新が発生した際に苦痛なく滑らかに対処できるパイプラインシステム**が必ず構築されていなければなりません。

---

## 5. 私たちの解決策：Fast-Ref プラグイン

OtakuSolutions は、この業界の渇望を解消するために 3ds Max 専用リファレンスシステム **Fast-Ref** を開発しました。

### ✨ Fast-Ref が提供する実務的メリット
1. **高精度なアニメーション保持**：リグバージョンが v1 から v2 に変わったり、別の衣装バージョンに差し替えられたりする際、Biped モーション・通常ボーンアニメーション・複雑なコンストレイント関係まで完璧に保持したまま差し替えます。
2. **協力会社・外注パイプライン互換性**：最も驚くべき点は、**Fast-Ref がインストールされていない外部 PC でもプロジェクトファイル（.max）がまったく問題なく開ける**ことです。外部外注先にファイルを渡す際も、ツール依存の心配なく自由にデータ共有が可能です。
3. **直感的な管理 UI**：どのファイルがリファレンスとしてシーンに入っており、それが最新かどうかをトラフィックライト式のカラーマークで一目でモニタリングできます。

手動の繰り返しで工程が延び、シーンが壊れる地獄のような環境から抜け出し、Fast-Ref で Maya レベルの安定した構造化されたキャラクターリファレンスパイプラインを構築しましょう。

---

# Ep.1 — リファレンスパイプライン 101（フォルダ構造設計の法則）

> slug: ep01_reference-pipeline-101

https://youtu.be/qGYcZd67eNA?si=5uRxdGBzGYs1O8aj

> **要約**：安定したリファレンスシステムを運用するために最初にすべきことは、**「マスターリグフォルダ」と「アニメーション作業フォルダ」を徹底的に分離し、絶対に混在させないこと**です。

---

## 1. このエピソードが生まれた痛切な背景

Maya 中心のスタジオでは、骨格とアニメーションを分けるという構造が基本ルールとして定着しています。しかし 3ds Max や Blender ベースで成長したチームを調査してみると、思いのほか多くの場所で決まったフォルダ規則なしにファイルを行き当たりばったりで混在させています。
発表者の経験では、**10 社中 6 社**がフォルダ構造を完全に混乱させた状態でした。専任のリギング部門がなく、ジェネラリストが一手に担うチームほど、この問題が深刻に起きています。

Fast-Ref の導入を決めたなら、ツールを起動する前に**フォルダ構造を整理するという前提条件**が必ず満たされていなければ、パイプラインは正常に機能しません。

---

## 2. 絶対に守るべき 2 種類のファイル分類

スタジオのアニメーションパイプラインには、次の 2 種類の核心ファイルだけが存在するべきです。

| ファイル種別 | 含めるべき内容 | ❌ **絶対に入れてはいけない内容** |
|-------------|--------------|----------------------------------|
| **オリジナルリグファイル (Original Rig)** | スケルトン・コントローラー・スキンウェイト・メッシュ | **アニメーションキーフレーム** |
| **アニメーションシーンファイル (Animation Scene)** | リグファイルをリファレンスリンク (Add) した後に打ったアニメーションデータ | オリジナルリグソース自体の直接編集版 |

### 🚨 よくある悪いパターン (Anti-Patterns)
1. **テストアニメーションをオリジナルリグに保存する行為**：「このリグちゃんと動くかな？」とテストするためにマスターリグファイルにキーを打ち、うっかり保存してしまう状況です。（テストキーは必ず別の一時ファイルや `.bip` に保存してください。）
2. **リグファイルを開いて「名前を付けて保存」でアニメーション作業を始める行為**：最も多く、最も破壊的な作業方法です。元のリグファイルの接続関係をすべて断ち切り、ハードコードされた単一ファイルとしてシーンを独立させてしまうため、リグ修正時にシーン全体を捨てる羽目になります。
3. **リンクの代わりにリグをシーンへ丸ごと Merge して使う行為**：シーンに重いリグデータが固定された状態になり、リグの修正内容をまったく反映できなくなります。

---

## 3. リグファイルにアニメーションが混入した際のエンジン大惨事

これは、ある Blender ベーススタジオにアニメーション TA として参加したときの実話です。リガーに「キャラクター A のマスターリグファイルはどこですか？」と聞いて受け取ったリグファイルを開いてみると、**キャラクターの派手なアルティメットスキルアニメーションがデフォルトポーズ状態のまま焼き込まれて（Bake）いました。**
前任者がアニメーション作業後、うっかりマスターリグファイルにそのまま上書き保存してしまっていたのです。

### 😱 バインドポーズ（Bind Pose）汚染が引き起こす連鎖反応
- アニメーションキーが焼き込まれたリグを Unreal や Unity にスケルタルメッシュとしてインポートすると、**エンジンが認識するキャラクターの初期デフォルトポーズ（バインドポーズ）自体が完全に歪んでしまいます。**
- 基本の体型情報自体が壊れているため、その後どれだけ完璧なアニメーションクリップをキャラクターに適用しても、**エンジン内で関節がねじれて潰れる恐ろしいレンダリングバグ**が続出します。
- 最終的に TA が投入されてアニメーションデータを一つひとつ削除し、純粋なデフォルト A-ポーズ / T-ポーズ状態に復元するという不要な工数が発生しました。

---

## 4. 部署間の明確な「エリア整理」（推奨 NAS フォルダ構造）

数十人のアーティスト（例：35〜40 人規模のアニメーションチーム）が協業する環境では、完全に分離されたルールが必要です。

```
Project_Super/ (ネットワーク共有ドライブ)
  ├─ rigging/             ← リガー専用領域（リガーのみ書き込み権限あり）
  │   └─ CH_Mable/
  │       ├─ master_mable.max   （アニメーションキーが皆無のクリーンリグ）
  │       ├─ textures/          （相対パス指定のテクスチャフォルダ）
  │       └─ old/               （旧バージョン履歴バックアップフォルダ）
  │
  └─ animation/           ← アニメーター専用領域（アニメーターのみ書き込み権限あり）
      └─ Scene_Walk/
          └─ walk_mable_v01.max （master_mable.max を Fast-Ref で「Add」リンクしたファイル）
```

### 🚫 厳格なアクセス制限ルール
- **リガー**：アニメーターのフォルダは参照できますが、アニメーターの作業シーンに直接介入して上書きする行為は禁止です。
- **アニメーター**：リギングフォルダ内のマスターリグファイルを「読み取り専用」で開いて参照することはできますが、**リギングフォルダ内にいかなるファイルも作成・上書きしてはなりません。**

---

## 5. 「カオス比率を 7% 以下に抑えろ」

プロダクションが進むにつれ、ルールを完璧に守ることは不可能であり、一定程度の整理されていないファイルの混乱（Chaos）は避けられません。
しかし発表者は**パイプライン全体の混乱指数を最低 7% 以下**に抑えるというガイドラインを立て、ファイルが絡み始めるたびに積極的に整理します。

この整理の主体は、下の立場のアーティストが遠慮して手を出しにくいため、**チームを率いるリードや実務 TA が権限をしっかり持ち、フォルダ階層とファイルアクセス権限を規定して随時フィルタリングしなければなりません。**

このようにしっかり設計された「マスターフォルダ規則」が整って初めて、Fast-Ref の自動チェック・交換機能が本来の力を発揮できます。

---

# Ep.2 — リファレンスの追加・削除（Add / Remove と信号機ファイル状態チェック）

> slug: ep02_add-remove

https://youtu.be/-j6lYvfwz8U?si=3xzlrhYGPfVZPImV

> **要約**：リグファイルをコピーしてシーンに貼り付けるのはやめましょう。Fast-Ref の **Add** でクリーンにリンクするだけにして、シーンデータに影響なく **Remove** で外すことができます。リグファイルの状態は **緑・黄・X** の信号機カラーで 5 分ごとにリアルタイム更新されます。

---

## 1. Maya のリファレンスのように管理する

Fast-Ref の基本コンセプトは、複雑なセットアップなしに Maya の直感的な参照メカニズムを 3ds Max へ完璧に移植することです。
外部ファイルとの**「リンク関係」**だけを作成し、シーンファイルを極めて軽量に保ちながら、シーン内のあらゆる状態変更を専用のテーブルビューで簡単に制御します。

---

## 2. Add — リファレンスの登録

Fast-Ref UI を開き、元のリグフォルダ内の `.max` マスターファイル（例：`master_mable.max`）を選択して **Add** ボタンを押すと、テーブルに登録されます。

### 📊 スロット登録時に即座に有効になる操作ボタン
- 🟢 **緑マーク**：ディスク上のファイルパスが有効で、開いているシーンが**最新の完璧なリグ状態**を参照していることを示します。
- 👁️ **Visibility（表示 on/off）**：該当リファレンスを画面で非表示または表示します。1 つのシーンにキャラクターが 3〜4 人以上登場してビューポートが重くなるときに便利です。
- ❄️ **Freeze（凍結）**：誤ってキャラクターをドラッグしてビューポートで動かしてしまうミスを防ぐ、ワンクリック固定モードです。
- 🎯 **Selection helper（選択補助）**：そのリファレンスに属する複雑なリグボーン構造をワンクリックですべて一括選択します。

---

## 3. リガーがリグを修正したとき（黄色の警告ライト）

ネットワークドライブ上で作業中にリガーがリグのスキンやメッシュを修正してマスターファイルに配布したら、どうなるでしょうか？
アニメーターがリガーに「修正しましたか？」と手動で聞く必要はまったくありません。Fast-Ref テーブルのマークがすぐに **🟡 黄色**に変わります。
> **「ディスク上のファイルのタイムスタンプが最近更新されました。アニメーターさん、このシーンは古いバージョン基準です！」** という親切な警告です。

このとき選択肢は 2 つです。
1. **Reload**：ファイルパスはそのままに、ディスクに新しく上書きされた最新リグファイルの内容でシーン内のリグ構造だけを安全にリフレッシュします。
2. **Replace**：リガーが完全に別のパスに新しいファイルを作成した場合、新しいファイルパスを指定して骨格を交換します。

---

## 4. Remove — リファレンスの削除

シーンからキャラクターを除外したり不要になったりしたとき、**Remove** ボタンを押します。
従来の 3ds Max では XRef などを削除する際、ノードが絡まっていたり空のダミーノードが残骸として残り、シーンが徐々に汚染されるという慢性的な問題がありました。
しかし Fast-Ref は、**残骸ノードやスキニングデータ汚染を一切残さず、最初からなかったかのようにシーンを純粋な状態に復元**して削除します。

---

## 5. リアルタイム信号機状態検査システム（5 分検査周期）

Fast-Ref の最も賢い特徴のひとつが、バックグラウンド検知周期です。
- **ツール起動の瞬間**、すべてのスロットのディスクファイルタイムスタンプとパス状態を確認して状態を更新します。
- 作業中も**約 5 分間隔**でバックグラウンドが静かにマスターリグファイルの変更有無を自動確認します。

これにより、複数のチームメンバーが同時に協業する緊迫した実務環境でも、現在作業中のシーンが正しいパスを参照しており最新データ状態かどうかを、いつでも確実にモニタリングできます。

---

## 🚫 重要な注意事項とまとめ
- **すでに Fast-Ref としてシーンに読み込まれているファイル**を再度強制 Add しようとしたり、絡まった接続状態を放置したりすると衝突のリスクがあります。エラーを事前にフィルタリングしてくれるプラグインの親切なポップアップを必ず確認してください。
- すべてのアニメーション作業の始まりは、テーブル上部の **🟢 緑ライト**を確認することです。

---

# Ep.3 — Replace（コア機能）と Namespace による複数キャラクター管理

> slug: ep03_replace-namespace

https://youtu.be/7g6yB1Nn9do?si=KJyunD8Lv_VKMbkS

> **要約**：アニメーションが入ったリグを新しいリグに交換する際、既存の **Biped・Bone アニメーション・コンストレイント関係を完璧に維持**したまま交換（Replace）します。また、同一キャラクターが複数登場するときに名前が衝突しないよう、**Namespace 接頭辞**を付与して管理します。

---

## 1. Fast-Ref の中核機能：Replace ワークフロー

Max アニメーターが最も打ちのめされる瞬間は、「リギングデータが修正されたので作り直してください」というフィードバックを受けたときです。ボーン名が変わるだけで既存のキーがすべて壊れ、最初からやり直しになるケースが多いからです。

Fast-Ref の **Replace** 機能はこの問題を完璧に回避します。リグのソースファイルパスを新バージョンのファイルに変更するだけで、以下の核心アニメーションシステムを自動バックアップし、新しいリグに精密に移植します。

### 🛡️ 保持を保証する 3 大アニメーション核心資産
1. **Biped アニメーション**：骨盤位置・IK 情報・手足のモーションを無損失で完璧に保持します。
2. **Bone アニメーション**：バイペッドではなく通常の Max Bone でセットアップされた小道具・マント・髪のアニメーションも、バックアップ（.xaf 移植）してそのまま引き継ぎます。
3. **コンストレイント関係**：頭の上に付けたアクセサリーや手に持った武器など、キャラクターに設定された無数のコンストレイント接続構造を、手動で再ターゲットする必要なく正確なシーン全域マップで保持します。

これにより、手動コピーにかかっていた作業時間を最低 1/10 に短縮し、単純なコスチューム交換や類似骨格の別キャラクターへのアニメーション転送にも柔軟に対応できます。

---

## 2. Namespace 管理のルール（マルチキャラクターシーンの安全装置）

1 つのシーンに Mable キャラクターを 2〜3 体コピーして同時配置すると、どうなるでしょうか？
3ds Max はデフォルトで、同じ名前のオブジェクトがシーンに入ると名前の後ろに数字を自動付与してユニーク化します（`Mable_Bone_01`、`Mable_Bone_02` など）。これによりリギング構造とコントローラーリンクが絡み合い、シーンが完全に崩壊しがちです。

Fast-Ref は Maya の標準方式である**接頭辞（Namespace）分離方式**でこれを明快に防ぎます。

- Mable_A キャラクターは `Mable_A:root`、Mable_B キャラクターは `Mable_B:root` のように、ノードの前に一意の名前空間がきれいに付きます。
- **Namespace 変更**：テーブルビューでスロットの名前空間をワンクリックで簡単に変更できます。
- **Activate Space（スペースのアクティブ化）**：マルチキャラクターシーンで、現在アニメーションをつける特定キャラクターの名前空間を即座に「アクティブ」状態に固定します。これにより、アニメーターが誤って隣の別キャラクターに触れて壊してしまう大惨事を事前に完全防止します。

---

## 3. 外部ツールとの名前互換性について

会社独自の専用エクスポーターや特定スクリプトは、コロン（`:`）付きの名前空間ノード形式をまったく認識できない場合があります。
その場合は Namespace 接頭辞をオフにして元の平坦な名前でシーンに展開する必要がありますが、**名前空間をオフのまま無計画に Replace すると衝突により隣のマルチキャラクターが丸ごと消えたり絡んだりするバグ**が生じる可能性があります。

このような特殊パイプラインの互換性の悩みを解決するインテリジェントな補助機能が、**EP04（Unpack）**と **EP06（Smart Switch）**です。

---

# Ep.4 — Unpack（パッケージ構造の解除と他ツール互換性）

> slug: ep04_unpack

https://youtu.be/Jaii390A0Nw?si=2n7U_mVournDJH9X

> **要約**：Fast-Ref はシーンの安定性のためにリファレンスデータを仮想の安全パッケージでラップして管理します。社内レガシースクリプトや外部プラグインがこれを認識できない場合は、**Unpack** を有効にして純粋な元のシーン構造に一時展開するだけで解決します。

---

## 1. Fast-Ref の内部パッケージングメカニズムを理解する

シーン内のリファレンスデータが劣化したり、3ds Max 自体のガベージコレクション中に失われたりするのを防ぐため、Fast-Ref はデータを特殊にパッケージング（仮想のフェンス内に保管）して管理します。
一般的なアニメーション作業、ビューポート操作、キーフレーミングの大半は **Unpack に一切触れずデフォルト状態で完璧に動作**します。

---

## 2. Unpack がいつ、なぜ必要なのか

プロダクション環境には、多数の社内開発プラグイン・特定のフレームワークスクリプト・特殊なレガシーエクスポーターなどが混在しています。これらのツールは「通常の 3ds Max シーングラフノード」しか直接読み取れないようにハードコードされている場合が多いです。

このとき、Fast-Ref の特殊パッケージングフェンスを読み取れず外部ツールでエラーが発生したり、キャラクターが選択できなかったりする互換性問題が生じる可能性があります。このタイミングで **Unpack On** スイッチを使います。

- **Unpack を有効にすると**：Fast-Ref の安全フェンス内に隠れてラップされていたノードが **オリジナルファイルの純粋な 3ds Max ノード状態に完全展開され、シーンレベルに開かれます。**
- **管理は引き続き維持**：驚くことに、ノードが通常オブジェクトのようにシーン上に露出しても、**Fast-Ref テーブルは内部で「どのファイルと接続していて、誰の Namespace か」という所有リンクを完璧にトラッキングし続けます。**

---

## 3. Namespace と Unpack オプションの相関関係

スタジオのパイプライン制約に応じて、アーティストは以下の 3 つの核心設定軸を適切に行き来する必要があります。

1. **Namespace On**：マルチキャラクター配置時は絶対にオンにして作業するのが安全です。
2. **Namespace Off**：社内の他の専用ツールがコロン接頭辞（`:`）をまったく解釈できない場合にオフにします。（この場合ノード名が統一されるため、マルチキャラクター交換時は注意が必要です。）
3. **Unpack On**：仮想パッケージ構造を剥がして、外部レガシーツールが骨格とコントローラーを自由に解析できるよう扉を全開にする状態です。

---

## 💡 実務ガイドライン まとめ
- 通常の作業や純粋な Fast-Ref ベースのパイプラインなら **Unpack Off が最も安定**なのでそのままにします。
- 会社専用の「検査ツール」や「エクスポートエンジンプラグイン」がノードを見つけられず悲鳴を上げたときだけ、**Unpack On** をオンにして互換性の橋をかけてあげると解決します。

<!-- [REVIEW: legacy image - verify placement context] -->
![Unpack 기능 스크린샷](ep04_unpack/image.png)

---

# Ep.5 — Merge & Convert（参照の結合とリファレンスの復元）

> slug: ep05_merge-convert

https://youtu.be/MSkKN81kY6g?si=y4NE297kj1cbtAc6

> **要約**：リンク関係を完全に切断してキャラクターを現在のシーンに永久保存したい場合は **Merge** を、保存した独立オブジェクトを再びファイルパスと接続して管理したい場合は **Convert** を実行します。

---

## 1. Merge — リンクの永続解除とシーンへの焼き込み

Fast-Ref リファレンスは常にマスターリグファイルの変更をリアルタイムで追跡する動的リンク関係です。
しかし、プロダクションの最終納品段階や外注先へのファイル受け渡しのために、**外部ファイルパスを一切見ず、このシングル max ファイル内にキャラクターのリグとアニメーションデータを永久に結合（Bake）させて切り離したい**ときがあります。

- **Merge を実行すると**：ワンクリックで、仮想的に参照されていたキャラクターリグ全体が **現在の `.max` ファイル内に完全な実体ノードとして固定結合**されます。
- **適用結果**：この時点以降、リガーが元のマスターファイルをどれだけ修正しても、このシーン内のマスターデータは独立しており影響を受けません。別の PC に単一の `.max` ファイルを渡すだけで完璧に開けます。

---

## 2. Convert — 孤立ノードを再びリファレンスリンクに復元する

逆に、手動でシーンに Merge してしまったり、別のファイルからコピーしてきた未加工のキャラクターノードの塊があるとします。これらを再び Fast-Ref の安全なリンク管理下に置いてリビジョンを追跡したいときに **Convert** 機能が活躍します。

1. シーン内に漂っている結合済みのキャラクターボーングループを指定して **Convert** を実行します。
2. 該当データが Fast-Ref テーブル上の仮制御スロットとして登録されます。
3. このスロットが参照するディスク上の **マスターリグファイルパス**を手動で再指定（Point）すると、完全なファイルリファレンス関係が再び有効になります。

---

## 3. Remove と Merge の明確な使い分け

シーンからリファレンスを取り除く際、多くのアーティストがこの 2 つのメニューを混同します。

* **Remove**：キャラクター自体をシーンから跡形もなく削除するクリーンアップ動作です。（キャラクターの削除）
* **Merge**：マスターファイルとの外部接続だけを切り、キャラクターの骨格とアニメーション自体はシーン内に完全保存して通常オブジェクト化する結合動作です。（リンク切断＋シーン焼き込み）

---

## 🔄 ワークフロー パイプライン整理

```
[ディスク上の master_mable.max] 
            │ (Add リンク)
            ▼
┌─────────────────────────────────┐
│ Fast-Ref リファレンス制御状態      │
└─────────────────────────────────┘
            │
            ├─► (Remove 実行) ──► シーンから跡形なく削除（完全クリーン）
            │
            └─► (Merge 実行)  ──► シーン内部に永続オブジェクト化（リンク切断）
                                        │
                                        ▼（再び管理したいとき）
                                  ┌─────────────────────────────────┐
                                  │ Convert ──► パス再接続 ──► リンク復元 │
                                  └─────────────────────────────────┘
```

<!-- [REVIEW: legacy images - verify placement context] -->
![Merge & Convert 워크플로 1](ep05_merge-convert/image.png)

![Merge & Convert 워크플로 2](ep05_merge-convert/image_1.png)

---

# Ep.6 — Smart Switch（Namespace トグル不要の安全交換装置）

> slug: ep06_smart-switch

https://youtu.be/gb1WCwMDe1I?si=oxGpoEYPqy6vy5o8

> **要約**：スタジオのパイプライン規則上 Namespace を **Off** にして作業しなければならないアーティストも、リグ交換時に他のキャラクターノードが削除されるような惨事なく、**バックグラウンドで安全な Replace をインテリジェントに代行するオートマジック機能**です。

---

## 1. Namespace Off ワークフローが抱える致命的なリスク

最も理想的で安全な Fast-Ref ワークフローは、名前空間（`キャラクター名:ボーン名` 構造）を常にオンにして作業することです。
しかし会社の特殊なエンジンエクスポータースクリプトの制約により、**Namespace を完全にオフにし、Unpack まで有効にした状態**で作業しなければならないスタジオが多くあります。

この状態でシーン内に複数のキャラクターが同時に存在する場合、Namespace 接頭辞がないためボーン名がすべて同じです（`root`、`L_Thigh` など）。この状況で 1 キャラクターのリグだけ Replace しようとすると何が起きるでしょうか？
- Max エンジンが同名の別キャラクターのノードをターゲットに誤解します。
- 交換中に、**おとなしくそこにいた無関係な別キャラクターのノードが丸ごと削除されたり絡んだりという致命的なマージ大惨事**が発生します。

そのため旧バージョンでは安全のために名前空間がひとつでもオフになっていれば Replace 自体を完全にブロックして警告ダイアログを表示し、アーティストを強制停止させていました。

---

## 2. 手動の地獄から脱出：「Smart Switch」の誕生

リグを修正するたびにアーティストが手動で：
1. `Namespace Activate On` をオンに切り替え（安全パッケージングに切り替え）
2. `Replace` を実行してリグ交換完了
3. 交換が終わったら再度 `Namespace Off`・`Unpack On` に戻す

この 3 段階の手作業を繰り返すのは極めて面倒なうえ、途中で 1 ステップでも誤って飛ばすとシーンを丸ごと失います。**Smart Switch（スマートスイッチ）**はこのプロセス全体を自動化しました。

---

## 3. スマートスイッチがバックグラウンドで代行するフロー

Options メニューの **Smart Switch** オプションにチェックを入れておくだけで、ツールが自動的に以下の驚くべきシーケンスを実行します。

```
[Replace/Reload コマンド検出] ──► 1. 一時的に Namespace On（安全な仮想シェルに隔離）
                                               │
                                               ▼
                                     2. 安全に 1:1 マッピング Replace 実行（他キャラクター干渉ゼロ）
                                               │
                                               ▼
                                     3. 交換成功後、元の Namespace Off / Unpack On に完璧復元
                                               │
                                               ▼
[アーティストが作業画面を確認] ──► Namespace は依然 Off、レイヤーも元通りに完璧整理！
```

このインテリジェントなシーケンスのおかげで、アーティストはバックグラウンドで何が起きているか気にすることなく、自分のフラットな作業画面構成だけに没頭してリグを自由に更新できるようになりました。

---

## 4. オプションをオフにしていても機能する実務安全プロンプト

Options メニューで Smart Switch をうっかりオフにした状態で、危険な Namespace Off スロットを Replace しようとするとどうなるでしょうか？
無条件にブロックするのではなく、スマートなポップアップが表示されます。
> **「現在の設定は危険です。安全な交換のためにスマートスイッチアシスタントをこの 1 回の交換に一時適用しますか？」**

**Yes** を選択すると、その 1 回の交換だけスマートスイッチが安全にバックグラウンド代行を実行して解決します。

💡 **体感参考**：スマートスイッチが起動すると内部的に名前空間の一時割り当て・ノード分離・安全復元シーケンスがもう 1 サイクル回るため、**通常の単純な交換よりほんのわずか時間がかかる場合があります。** これはシーンの安全を完璧に守るための精密な演算ステップですので、安心して 3〜4 秒お待ちください。

---

# Ep.7 — ゲームエンジン用 FBX エクスポート（入門パイプライン概要）

> slug: ep07_fbx-export-overview

https://youtu.be/y6812vbBJH4?si=5Yi0GBRgKiob3VmJ

> **要約**：Fast-Ref は 3ds Max 内部のシーン参照ツールにとどまらず、作業完了後に **Unreal や Unity エンジンへデータを一括配信できる強力な専用 FBX エクスポーター**を内蔵しています。

---

## 1. シーン管理からゲームエンジン配信まで、単一パイプラインの構築

多くの開発チームが、アニメーションキーを打つ作業環境と、そのファイルを書き出してゲームエンジン（Unreal、Unity など）にインポートする環境を、それぞれ別の自社製ツールで分けて使っています。
しかし、それらの自社製ツールがバラバラに動作すると、バージョン管理が混乱し、骨格の軸やNamespace 規則が絡み合ってエンジン内でアニメーションが歪む事故が頻繁に起きます。

Fast-Ref は、アニメーション制作から最終的なゲームエンジンインポート仕様に最適化されたファイル配信まで、**一つの UI フローで統合（All-in-One）**するよう設計されています。

---

## 2. FBX エクスポートへのアクセスと主要機能

Fast-Ref メインウィンドウ上部の **Tools** メニューを開くと、すぐにエクスポートシーケンスにアクセスできます。

- **ワンクリック単体 / 一括エクスポート**：シーン内の 1 キャラクターだけを即座に書き出したり、1 シーンに登場する 3〜4 キャラクターのデータをそれぞれ個別 FBX として一括出力できます。
- **統合 FBX オプションシステム**：メインウィンドウの単体エクスポーターと、数十の max ファイルを一括処理する **Batch Tool（EP09）**が **完全に同一のグローバル FBX 設定値を共有**するため、アーティストとバッチが異なる出力をしてバグが生じる大惨事を根本から防ぎます。

---

## 3. 実エンジン環境での徹底検証済み（Unreal & Unity）

OtakuSolutions は Fast-Ref の開発にあたり、仮想シナリオではなく、**実際の大規模ゲーム開発プロダクション現場の TA・リガー・シネマティックアニメーターチームと緊密に協業し、Unreal Engine および Unity ビルド環境でエクスポート結果を事前に徹底検証**しました。

- 骨格軸の歪み現象防止
- Namespace 除去互換性
- ボーンスケール変形エラーの排除

このようにエンジンビルドパイプラインに即座に組み込めるよう事前に完全精製された FBX エクスポーターなので、詳細オプションを一度設定すれば、実務エンジンインポーターに信頼して投入できます。

---

## 🎯 エクスポート習得ロードマップ
* **今（EP07）**：「なるほど、Fast-Ref の中でエンジン用 FBX まで完璧に互換処理してくれるんだ！」という概念把握
* **次（EP08）**：FBX オプションパネルを開いて、実務でアニメーションクリップだけを書き出すときに Skin をオフにする理由と Smooth Groups が必要な理由を解剖
* **最後（EP09）**：そのオプションを適用してシーン 20 本以上を夜通し自動で書き出す Batch Tool の活用法習得

---

# Ep.8 — FBX Export Options（エンジンインポート用の詳細オプションガイド）

> slug: ep08_fbx-options

https://youtu.be/uXCT5PicgQU?si=iM07m4TMUj1vHdBr

> **要約**：FBX オプションパネルの**上部エリアは 3ds Max の標準 FBX エクスポート機能**に接続しており、**下部エリアは Fast-Ref 独自のネームスペース削除・ルート位置リセット・変数式ファイル名自動生成機能**を提供します。一度設定したオプションはプリセットとして保存してチームで共有しましょう。

---

## 1. オプション制御の核心メカニズム

Fast-Ref のエクスポーターパネルは設定値を **Preset（プリセット）**ファイルとしてハードディスクに保存し、単体エクスポートでも夜通し大量ファイルを処理する **Batch Tool（EP09）**でも同一プリセットで完全制御するため、出力のばらつきをゼロにします。

---

## 2. 3ds Max 標準 FBX 制御エリア（上部）

3ds Max エンジンが提供する FBX SDK オプションと接続しており、実務のヒントを中心にまとめます。

| オプション名 | 実際の機能 | 💡 **実務ガイドとヒント** |
|-------------|-----------|--------------------------|
| **Animation** | FBX にキーフレームアニメーションデータを含めるか否か | アニメーションクリップを書き出す場合は当然 **On** にします。ただしエンジンにキャラクターの外形（Skeletal Mesh）を最初に登録する際は、これをオフにして 0 フレームの T-pose 状態でクリーンに書き出すのが良いです。 |
| **Skin** | メッシュにボーンが付いたスキンバインディング情報の有無 | - **メッシュ初回登録時**：**On**<br>- **アニメーションクリップのみ抽出時**：**Off**<br>👉 エンジンにキャラクターメッシュがすでにある場合、アニメーションクリップ用 FBX を書き出すときに Skin をオフにすることで、ファイルサイズが 1/10 になりエクスポート速度が数十倍速くなる強力な実務テクニックです。 |
| **Shape** | フェイシャルアニメーションに使うブレンドシェイプ / モーフデータの有無 | フェイシャルアニメーションを使うメインキャラクターは必ず **On** にします。 |
| **Bake Animation** | 元のフレームレートに関係なく 1 フレーム単位でキーを固めて保存 | エンジン内部の物理補間衝突を防ぐために **必ず On にすること（Bake On）**が、アニメーション潰れを防ぐ実務標準です。 |
| **Smooth Groups** | 3D メッシュ面の滑らかなシェーディング情報の保存 | **必ず On にします。** うっかりオフにしてエンジンに入れると、きれいなキャラクターが**マインクラフトのキャラクターのようにカクカクした状態**で出力される大惨事になります。 |
| **Texture Embed** | テクスチャ画像ソース自体を FBX ファイル内にバイナリデータとして埋め込む | **必ず Off にします。** オンにすると、1 つの FBX ファイルに数十 MB の画像が詰め込まれてファイルサイズが制御不能になります。パスは 3D シーン内で相対パスのみで管理するようにしてください。 |
| **Up Axis** | ゲームエンジンが基準とする「上方向」軸の設定 | - **Unreal Engine**：3ds Max と同じ **Z-up** 軸設定<br>- **Unity Engine**：Unity プリセットボタンを押すと **Y-up** 軸に自動マッピング調整 |
| **Units** | エンジン内のスケール単位合わせ | 3ds Max はデフォルト cm スケールを使います。Unity（m 単位を好む）などのアウトプットに合わせて、スケール係数を Unity 用プリセットで必ず手動検証してください。縮小 / 巨大化バグを防げます。 |
| **File Version** | FBX 書き出しファイルフォーマットのバージョン | 現在業界で最もエラーが少なく安定した **FBX 2020** フォーマットに統一することが推奨されます。 |

---

## 3. Fast-Ref 専用エクスポート制御エリア（下部）

Fast-Ref 内でのみ提供される実務中心の自動化機能です。

### ✂️ Remove Namespace（ネームスペース自動除去）
マルチ配置のために一時的に付けた `Mable_A:L_Hand` のような名前から接頭辞を強制除去し、エンジンインポーターには純粋な元のボーン名 `L_Hand` のみで保存・送信します。エンジン内でリターゲットが崩れる心配は不要です。

### 🎯 Reset Root（ルートボーンの原点強制固定）
キャラクターがワールド空間を前方へ走るアニメーションが入っていても、エンジン内部のルートモーション演算やバインディング規則のために **最上位のルートボーンの位置と回転を原点（0,0,0）に強制固定して出力**しなければならない場合があります。
- 特定のルートボーン名を認識して原点に強制ホールドし、必要に応じて Z 軸 90 度などの補正回転を加えてキャラクターの前方方向を整列させます。
- 🚨 **注意点（非常に重要）**：この機能はエクスポート時にキャラクターのシーン座標を一時的に演算するため、**FBX 抽出直後に作業用 `.max` ファイルを保存せずに閉じることでシーンアニメーションの汚染を防ぎます。** リードがアーティストたちに強く叩き込むべき重要なヒントです。

---

## 4. 変数式ファイルネーミングルールの設計

出力される FBX ファイル名をアーティストが一つひとつ入力するのではなく、以下のダイナミック変数を組み合わせてルールとして定義しておくと、ファイル名が自動生成されます。

* `[Original File Name]`：現在のシーン max ファイル名
* `[Namespace]`：そのキャラクターに付与されたユニーク名
* `[Date]`：今日の日付の自動スタンプ
* `[Auto Namespace / Index]`：シーンにキャラクターが 1 名だけなら元の名前でクリーンに書き出し、**2 名以上検出された瞬間に自動で `ファイル名_Yuna`・`ファイル名_Mila` などに自動展開**する非常にスマートな自動化演算です。

### 🏷️ Create Rigging Data（Export to Selection - ES タグ）
ビューポート全体を選んで書き出すのではなく、リガーがキャラクターのマスターセットアップ時に登録した **Selection Set 名（例：Export Body）**を読み取り、メッシュとスキニングウェイトデータのみを精密にフィルタリングして書き出します。構文に問題があってエクスポーターが迷子になると、パネル右側に直感的な赤いエラーマークで教えてくれるので確認・修正が容易です。

### 📁 Create Subfolder Per Max Files（シーンファイルごとのサブフォルダ分割）
- **チェック On**：カット単位のシネマティックシーンのように複数キャラクターが入り乱れて書き出される場合、作業シーン名でサブフォルダを自動生成してまとめるのでデータの整理が楽です。
- **チェック Off**：アクションループ（Run、Walk、Idle）のように 1 キャラクターのモーションクリップだけをフラットに書き出す場合に推奨です。

<!-- [REVIEW: legacy images - verify placement context] -->
![FBX 옵션 패널 1](ep08_fbx-options/image.png)

![FBX 옵션 패널 2](ep08_fbx-options/image_1.png)

---

# Ep.9 — Batch Tool（一括 Reload と FBX 自動エクスポーター）

> slug: ep09_batch-tool

https://youtu.be/oDxD8zUEIPc?si=E30cg7eIX9IKt2X6

> **要約**：数十の max ファイルを 1 つずつ開き、更新されたリグを適用して、キャラクターごとに FBX を書き出すという過酷な単純作業を、1 回のバッチ設定で自動化（Batch）してくれる夜間作業特化の生産性ブースターです。

---

## 1. Batch Tool の実務価値を体感する

例えば、次のような状況があります。
> **「1 シーンに走りアニメーションを実行するキャラクターが 3 名登場します。このようなシーンが合計 3 つ（シネマティックカット 3 本）あります。」**

リグファイルが v2 に更新されたとき、この 3 つのシーンについてアーティストが直接更新してエクスポートしなければならない回数は合計 **9 回（3 キャラクター × 3 ファイル）**です。
ファイルが 20 個、キャラクターが 5 名なら、100 回以上の手作業が強制されます。
Fast-Ref の **Batch Tool** は、アーティストが退勤前にこの 100 ステップ以上の手動工程を、ワンクリックで夜通しコンピューターに任せる究極のバッチ処理自動化ウィンドウです。

---

## 2. バッチツールへのアクセスと構成

Fast-Ref メインウィンドウの **Tool -> Batch Tool** メニューをクリックすると、独立したバッチ制御用の大型ダイアログが展開されます。
（メイン Fast-Ref システムに内蔵され、シングルライセンスで無償統合提供されます。）

---

## 3. 核心自動化機能（2 大柱）

バッチプロセッサーは以下の 2 ステップを順次、または個別に完全自動処理します。

### 🔄 1. Reload（一括リファレンス更新）
- 登録リスト内の各 max ファイルを順番に静かに開きます。
- Fast-Ref 解析エンジンを起動して、シーン内のキャラクターリグがディスク上の最新バージョン（黄色アラートなど）より古いかどうかを検出します。
- 自動的に最新リグにリロード（Reload）して、接続構造・新骨格・スキンを反映します。

### 📤 2. Export FBX（一括エンジン用配信抽出）
- リロードが正常に完了したキャラクターの骨格とアニメーションを読み込みます。
- EP08 で事前に設定したグローバル FBX プリセットルール（Namespace 除去・Skin オフ有無・ルート原点固定など）を呼び出します。
- ファイルごと、またはファイル内キャラクタースロットごとに、固有の FBX ファイルをシーン外部フォルダへ一括出力します。

---

## 4. 安全なバッチ実行のセットアップガイド

初めてバッチを実行する際に元のファイルの破損が心配なら、以下の安全装置設定を確認してください。

- **Reload シーン保存パス分岐**：
  - **Overwrite**：更新された最新リグ状態を元の作業ファイルに上書きします。（パイプラインが完全に安定化したときに使用）
  - **Custom Path**：元のファイルには一切触れず、指定した別のバックアップディレクトリ（`D:/FR_Backup/` など）にリロード完了した新しい `.max` ファイルを複製してまとめます。（初期検証時および強く推奨のオプション）
- **FBX アウトプットパス指定**：最終的なゲームエンジンのリソースフォルダ（Content/Character など）のターゲットパスを設定しておくと、バッチ成功直後にエンジン側に更新データが一括投入されます。

---

## 5. 結果確認と詳細デバッグログ

バッチがバックグラウンドで夜通し動作している間にエラーが発生したファイルがないか確認する機能です。
- バッチがすべて完了すると、完了したスロットが鮮やかな **🟢 緑ボックス**でビジュアルパスを表示します。
- エラーが出たり Skip されたファイルがあれば、バッチウィンドウ下部の **Open Folder** ボタンを押してログディレクトリを開きます。
- 自動生成された詳細ログテキストをメモ帳で開くと、どのシーンの何フレーム目でエラーが発生したか、どのデータが欠損していたかを直感的なテキストで追跡でき、修正が非常に速くなります。

---

## 💡 実務者の視点：「私たちが自社ツールを作らない理由」

大規模スタジオでは通常、社内 TA チームが多大な工数をかけて独自の大量バッチツールを作ります。しかしメンテナンスが難しく、Max の新バージョン対応のたびに毎回エラーが出がちです。
Fast-Ref のバッチツールは、Unreal/Unity 連携の安定性・バックグラウンドリロード無失敗構造がすでに多くのプロダクションで数万ファイルの検証を経た既製品エンジンです。スタジオに導入した瞬間、開発チーム全体のファイル配信リードタイムが劇的に縮小されます。

---

## 📞 サポートとフィードバックチャンネル
動作中に特殊なカスタムコントローラーセットアップのためにバッチがスキップされたり、予想と異なる動作をするファイルが見つかった場合は、速やかに **OtakuSolutions の公式テクニカルサポートメールアドレス**に元のシーンと症状を送ってください。実務担当 TA が詳しく分析し、迅速にホットフィックスを提供します。

---

# Ep.10 — Rigging Info（共通リギングデータとセレクションセットの自動復元）

> slug: ep10_ri01-rig-structure-fbx

https://youtu.be/lthRjt9JdEM?si=VHrBrXjJn_RR4-cs

> **要約**：Fast-Ref と Biped Plus が共有する **Rigging Info（リギングインフォ）ノード**を活用して、シーンのロード速度を最大化し、3ds Max の慢性的な**セレクションセット消失バグ**を回避し、FBX エクスポート範囲を精密制御する高度なセットアップ法を学びます。

---

## 1. リギングインフォ（Rigging Info）とは何ですか？

初めて聞くと少し難しく複雑に感じるかもしれませんが、概念は非常に明快です。
**Rigging Info** は、OtakuSolutions の 2 つの核心プラグインである **Fast-Ref** と **Biped Plus** が共通してシーン（Scene）内の特定ノードに記録・共有する **「リギングメタデータ（Metadata）リポジトリ」**です。

### 🔌 アクセスポイント（同じノードにデータを保存）
* **Fast-Ref**：上部メニューまたは「リギングデータ作成（Create Rigging Data）」ボタン経由でアクセス
* **Biped Plus**：Biped Plus のエディット（Edit）ウィンドウ経由でアクセス

このメタデータノードには、バイペッド名・バイペッドノード階層情報・カスタムコントローラーリスト・スキンドメッシュのボーン情報などが凝縮されて保存されます。

このデータをリグのソースファイルに事前に焼き込んでおくと、Fast-Ref がシーンを新規ロードまたは交換（Replace）する際に **毎回全ノードを 1 つひとつ検査する必要がなくなるため、起動・マッピング速度が飛躍的に向上しはるかに安全**になります。

---

## 2. コントローラーリスト（Controller List）に登録すべき要素

バイペッド（Biped）の基本骨格を除き、アニメーターがシーン内で操作する必要のあるすべての制御装置（コントローラー）をこのリストに登録します。

* **通常ボーン（Bone）とコントローラー**：マント・髪・スカート・小道具制御用の補助ボーン
* **シミュレーションボーン**：アニメーターが頻繁に有効化するダイナミクス / シミュレーション用ボーン階層
* **フェイシャルとモーファー（Morpher）データ**：表情アニメーションキーが入るモーフターゲットデータ
* **ワイルドカード（`*`）サポート**：ボーンやコントローラーが数十〜数百個あるとき、名前の前に特定の接頭辞が付いていればワイルドカードを使って（例：`Prop_*`）一括登録できます。

> 💡 **実務ヒント**：表情制御装置などがすでに**フェイシャル UI スクリプト**にリギングで固く結びついて連動しているなら、このリストにコントローラーを手動で一つひとつ追加する必要はありません。キーが直接打たれる核心の独立ボーンを中心にセットアップするだけで十分です。

---

## 3. 3ds Max の慢性的な「セレクションセット（Selection Set）」バグの回避

多くのゲームプロダクションで、スキン用ボーンだけを選択したり（`Skin Bones`）、特定の衣装メッシュだけを選択したりするために（`Skins`）3ds Max の **セレクションセット（Selection Set）**機能を重宝して使います。

### 😭 3ds Max のセレクションセットバグ
- リグのソースファイルにどれだけ丁寧にセレクションセットを作って保存しても、**外部から Merge したり新しいシーンにロードしたりするとセレクションセットデータが自動復元されず消失してしまう 3ds Max 自体の慢性バグ**があります。

### 😎 Fast-Ref の解決策
- ソースリグでセレクションセット（`Skin Bones`・`Skins` など）を作成したあと、Rigging Info メニューで **データ更新後に保存（Refresh Save）**をクリックします。
- これによりセレクションセットデータが Rigging Info メタデータノード内に暗号化されて安全に記録されます。
- 以降 Fast-Ref を通じてキャラクターをロードすると、**Max のバグを嘲笑うかのようにリギングデータと一緒にセットアップしたセレクションセットが完璧にバックアップ復元**されてシーンに現れる奇跡を体験できます。

---

## 4. FBX エクスポート範囲の精密制御（Auto vs Defined）

Fast-Ref の強力な内蔵 FBX エクスポーターは、Rigging Info に登録されたメタデータをもとに抽出対象ボーンをインテリジェントに選別します。

### 🟢 Auto Mode（自動モード）
- スキンドメッシュに登録されたすべてのインフルエンス（スキン影響を受けるボーン）を抽出基準として自動集計して処理するモードです。
- スキン情報が明確に適用されていれば、このモードだけで完璧な FBX アウトプットが得られます。スキンのない特殊なボーンのモーションも一緒に書き出したい場合は、そのボーンを**コントローラーリスト**に追加するだけで、スキンの有無に関係なく抽出対象に自動合算されます。

### 🔵 Defined Mode（セレクションセット指定モード）
- キャラクター本体メッシュと右手に持った「武器データ（Prop）」を**それぞれ別々の独立した FBX として抽出**したい場合、どうすればよいでしょうか？
- **例**：武器メッシュと武器用ボーンをまとめて、セレクションセット名を **`Export Props`** として指定してシーンに保存し、Rigging Info を更新します。
- Fast-Ref エクスポーターで **Defined Mode** に切り替えると、記録されたセレクションセットのリストが画面に表示されます。
- ここで `Export Body` と `Export Props` を**同時にチェックして書き出すと、武器 FBX と本体 FBX の 2 ファイルがワンクリックで完璧に自動分割抽出**されます。

---

## 5. Fast-Ref UI の謎の「R」と「ES」タグの秘密

Rigging Info セットアップが完了したリグファイルを Fast-Ref テーブルに登録すると、スロット右側に **[ R ]** と **[ ES ]** という特別なタグアイコンが表示されます。

* **`R`（Read Mode）**：このキャラクターには Rigging Info メタデータが正常に装着されており、ロード・交換時の元の構造解析ステップが極限まで短縮されて超高速認識が可能であることを示す快適さの証です。
* **`ES`（Export Selection）**：武器分割抽出などのセレクションセットベースの精密エクスポートルールがこのスロットにマッピングされて動作中であることを示します。

### 🚨 R / ES タグが赤色（Red）で警告を送るとき
名前空間が有効な状態で、シーン内の実際の骨格ノードが見つからずマッピングリンクが切れていることを警告する緊急シグナルです。
**解決法**：一時的に名前空間のアクティブ状態をオフにするか、EP02 のファイル状態確認を参照してマスターパスを正しく復元すると、ボーン名が再び完璧に自動トラッキングされてタグが正常に戻ります。

---

## 一文まとめ

**Rigging Info = シーンのロードを 10 倍速くし、セレクションセットバグを完璧に回避し、武器などの複数 FBX 抽出範囲をワンクリック制御する核心ブレイン**

<!-- [REVIEW: legacy images - verify placement context] -->
![Rigging Info UI 1](ep10_ri01-rig-structure-fbx/image.png)

![Rigging Info UI 2](ep10_ri01-rig-structure-fbx/image_1.png)

![Rigging Info UI 3](ep10_ri01-rig-structure-fbx/image_2.png)

---

# Ep.21 — [FAQ] コンストレイントの復元が正しく行われません

> slug: ep21_faq-constraint-error

### 1. 状況（Scenario）

- **現象:** アニメーション作業中に Fast-Ref で設定した **Link Constraint** がリロード（Reload）後に消える、またはデータが正しく復元されない。
- **ユーザー体験:** 復元されないため、Point Constraint などを手動で使い直す手間が発生する。

---

### 2. Fast-Ref のコンストレイント復元アルゴリズム（Logic）

Fast-Ref はリロード時のデータ整合性のため、以下の**比較アルゴリズム**に基づいて復元するかどうかを決定します。

![image.png](ep21_faq-constraint-error/image.png)

| **区分** | **[Skip] リグの基本状態** | **[Restore] Fast-Ref カスタム作業** |
| --- | --- | --- |
| **判断基準** | リグ（Rig）とアニ（Ani）の両方に同じ Link がある | リグにはなく、アニにコンストレイントがある |
| **アルゴリズム動作** | 「オリジナルと同一」「オリジナルリグ優先」と判断して無視 | 「ユーザーデータ」と判断して別途記録・復元 |
| **設計意図** | 不要なコンストレイント処理を省略して最適化 | アニへの追加・コンストレイントが自動反映される |

- **[Skip] リグオリジナルと同一の場合:**
    - **リグ（Rig）ファイル:** すでにコンストレイント（Point、Orient、Link など）があり、
    - **アニ（Ani）ファイル:** にもコンストレイント（Point、Orient、Link など）がある
    ⇒ **リグの基本状態**とみなし、復元リストから除外（リグ修正が自然に反映されるため）
- **[Restore] Fast-Ref で作られた新しい変更:**
    - リグにないが、**作業者が Fast-Ref で追加した**コンストレイントは**ユーザーが作業したアニメーションデータ**として別レイヤーに記録し、Replace / Reload 時に参照して復元します。

---

### 3. 問題の原因（Root Cause）

ご報告の事象は、アルゴリズムの**判断ロジック**における例外です。

1. **データの誤認識:** リグ・アニの両方にすでにコンストレイントがある状態で作業したため、ツールが「ユーザーが新規作成したものではなく、もともとリグにあったもの」と誤認し、**復元対象から除外（Skip）**しました。

---

### 4. 解決方法（Solution）

ユーザーの意図を100%反映するため、次の方法を検討してください。

### **A案: リグファイルのクリーンアップ（最適化）**

アルゴリズムがオリジナルと作業版を混同しないよう、リグファイルをクリーンに保つ方法です。

- **説明:** リグオリジナルでは武器（Prop）などに**Link Constraint を事前に付けない**でください。
- **理由:** オリジナルにすでに Link があると、アニメーションファイルでユーザーが新しく設定した Link を**「最初からあったもの」**と誤認し、復元対象から**除外（Skip）**されることがあります。
- **推奨:** 武器は床に置いたまま（Clean）にし、Link 作業はアニメーターがアニメーションシーンで**Fast-Ref 経由**で行えば、復元は100%確実です。

---

### **B案: カスタム Attr（属性）またはドライブ接続**

コンストレイント復元ロジック自体を使わない、より専門的なリグ方式です。

- **説明:** コンストレイントを復元する代わりに、コントローラの**カスタム Attr（例: Switch 0/1）**や特定の**ドライブ（移動値 X など）**で接続を制御してください。
- **理由:** アニメーションシーンで新しいコンストレイントを作らないため、**復元すべき要素が発生せず**、データ欠落リスクを根本から防げます。
- **参考:** Maya など大手スタジオの基本リグでも推奨される方式ですが、チーム内の専任**リガー（Rigging TD）**との連携が必要です。

---

---

# Ep.22 — [FAQ] アニメーションデータが消えます

> slug: ep22_faq-removed-animation1

## 📂 Fast-Ref アニメーション消失防止・作業ガイド

### 1. 現象の把握（Issue）

- **状況:** `Fast-Ref` でファイルを読み込むとき（Load/Add）、リグオリジナルに含まれていたアニメーションデータが消える。

### 2. リファレンスパイプライン（Best Practice）

基本は、リグオリジナルとアニメーションデータを次のように分離して管理するのが定石です。

| **区分** | **リグオリジナル（Rig）** | **アニメーションファイル（Ani）** |
| --- | --- | --- |
| **アニメーションデータ** | **X（Empty）** | **O（Data Included）** |
| **リグリンク状態** | オリジナルファイル | リグファイルが **Link** された状態 |

> 💡 案内: 3ds Max ベースのゲームアニメ制作では、このリファレンス型パイプラインが馴染みにくい場合があります。効率的な協業のための構成ですので、下記の解決策をご参照ください。
>

![image.png](ep22_faq-removed-animation1/image.png)

---

### 3. 問題の原因（Root Cause）

リグオリジナルにアニメーションキーが含まれていることが原因の**データ構成上の衝突**です。

- **詳細:** Fast-Ref はリグ読み込み時に最適状態を保つため自動でアニメーションをクリーンアップします。オリジナルにテストアニメなどが含まれると、アルゴリズムが混乱しデータが失われることがあります。

---

### 4. 解決方法（Solution）

### ✅ 案 A. リグオリジナルデータの整理（推奨）

- リグオリジナル内の不要なテストアニメは可能な限り削除してください。データ構造を最もクリーンに保つ方法です。

### ✅ 案 B. 自動クリーンアップを一時的にオフ

- **[Option]** → **[General Option]** で **`Auto CleanUp Animation`** のチェックを外します。
- データ保存が必要な場合のみ**一度限り**使用し、通常は最適化のため再度オンにすることを推奨します。

![image.png](ep22_faq-removed-animation1/image_1.png)

### ✅ 案 C. [CONVERT] 機能でデータを保持

- 既存のアニメーションファイルを **[CONVERT]** で変換し、リグファイルに置き換えると、アニメーションデータを安全に保持できます。
- **参考リンク:** [Fast-Ref Convert ガイド](https://otakusolutions.com/ko/learn/fast-ref/merge-convert)

---

### 🚀 もっと知る: リファレンス作業の推奨環境

スムーズな協業とデータ管理のため、**Fast-Ref が提案する最適な作業環境**をご確認ください。フォルダ構成からパス規則まで詳しくまとめています。

👉 [**Fast-Ref リファレンスベース作業環境ガイド**](https://otakusolutions.com/ko/learn/fast-ref/quick-start) *（文書下部の「整えるべき作業環境」セクションを必ずご覧ください）*

---

# Ep.23 — [FAQ] 社内の独自 Export ツールを使うには？

> slug: ep23_faq-custom-export-tool-integration

**fast-ref** は基本的に内蔵機能によるゲームエンジン向け FBX Export の最適化を目指しています。各スタジオ固有のパイプラインとカスタマイズニーズがあることも十分理解しています。

fast-ref のすべての構成要素は **3ds Max 標準ノード** を基盤に設計されています。そのため **Export 後にシーンファイルを保存しなければ**、データ構造を自由に編集して社内ツールと連携しても問題ありません。

> **⚠️ 最重要原則: Export 作業後は絶対にシーンを保存しないでください。**
fast-ref のリファレンスシステムデータが失われ、正常な管理ができなくなります。
>

---

### 1. Reset All References 機能（v1.0.4~）

**v1.0.4** から提供される **Reset All References** を使うと、すべてのリファレンスが通常のシーンオブジェクトに変換され、**fast-ref リンクと無関係な状態**で自由に作業できます。

**パス:** `Tools → Edit → Reset All References (Merge All)`

この機能は次を自動実行します:

- すべてのネームスペースと接尾辞の整理
- 階層構造（Hierarchy）の解除
- レイヤー構造のフラット化
- fast-ref システムデータの削除

社内 Export ツールとの一時的な連携が必要なときは、この機能を実行してから Export してください。

> **⚠️ 再度強調:** Reset 後はシーンを**保存しないでください。** 保存せず Export のみ行ってください。
>

![image.png](ep23_faq-custom-export-tool-integration/image.png)

![image.png](ep23_faq-custom-export-tool-integration/image_1.png)

![image.png](ep23_faq-custom-export-tool-integration/image_2.png)

### Merge All Options（General Options で設定可能）

Reset All References 実行時に適用される suffix 整理オプションは **General Options** ダイアログで変更できます。

**パス:** `Tools → General Options → Merge All Options`

| オプション | デフォルト | 説明 | デフォルトの意図 |
| --- | --- | --- | --- |
| **Force Remove Node Suffix (.r\*)** | ✅ ON | ノード名から `.r1`, `.r2` 接尾辞を削除 | ゲームエンジンはノード名でボーン/メッシュをマッピングするため、接尾辞が残るとリターゲット・スクリプト参照が壊れる可能性 |
| **Force Remove Layer Suffix (.r\*)** | ⬜ OFF | レイヤー名から接尾辞を削除（同名時は自動統合） | 同一リソースを複数配置した場合の意図しないレイヤー統合を避けるためデフォルト OFF |
| **Force Remove SelectionSet Suffix (.r\*)** | ✅ ON | SelectionSet 名から接尾辞を削除（同名時は自動統合） | Export スクリプトが SelectionSet 名でグループ指定することが多く、接尾辞が残ると互換性問題の可能性 |

---

### 2. Script API サポート

より高度な自動化のため **Fast-Ref Script API** を提供予定です。社内 TA の方が Python でリファレンスの参照・追加・削除・Merge などを自動化できます。

```python
import sys, os, pymxs
_p = os.path.join(pymxs.runtime.getDir(pymxs.runtime.Name("userScripts")), "os_fast_ref_package")
if _p not in sys.path: sys.path.append(_p)

from os_fast_ref.api import FastRefAPI

api = FastRefAPI()
result = api.merge_all_references(
    remove_node_suffix=True,
    remove_layer_suffix=True,
    remove_selectionset_suffix=True,
)
print(result['message'])
# → "Merge 완료: 3개 성공, 0개 실패"
```

API_Guide_Link : https://docs.otakusolutions.com/api/fast-ref/merge-all-references?lang=en

---

### 3. 手動編集時の参考事項

API や Reset 機能を使わず独自スクリプトで編集する場合は、次の規則を参考にしてください。

- **ネームスペース削除:** `:` の前の文字列を削除（例: `Mable:Root.r1` → `Root.r1`）
- **接尾辞削除:** `.r*` 形式の接尾辞を削除（例: `Root.r1` → `Root`）
- **階層解除:** `[REF]` で始まるノードの子を Unparent
- **レイヤー整理:** `[REF]` で始まるレイヤー配下の子レイヤーを最上位へ移動後、`[REF]` レイヤーを削除

---

### 💡 最もおすすめの方法

最も効率的な連携は、**現在のスタジオの内部 Export 環境と要件を共有**していただくことです。ガイドライン提供の過程で、思ったより簡単な解決策が見つかることも多いです。

構造把握や連携で技術サポートが必要な場合は、いつでもお問い合わせください。

**OtakuSolutions は柔軟なパイプライン構築を積極的にサポートします。**

---

# Ep.25 — Fast-Ref vs 競合製品 比較

> slug: ep25_faq-fast-ref-vs-s-product

> 3ds Maxで**キャラクターリファレンスを管理**し、**リグが変わってもアニメーションを守り**、**エンジンへ送る**パイプラインが必要な方に向けた資料です。  
> **S製品**など他のリファレンスツールとの違い、Fast-Refが合っているかどうかを正直にまとめました。

## 一言で言うと

**Fast-Ref** は、ゲームキャラクターパイプライン向けに作られたリファレンスツールです。

- リグの `.max` をスロット単位で読み込み
- リガーがファイルを更新したとき、**Replace 一回**でアニメーション・Constraint・IK などを **3ds Max 公式復元 API** と **OtakuSolutions 独自復元アルゴリズム**で再調整し
- Unity / Unreal 向け **FBX Export** と**バッチ処理**まで連携します

**S製品**もアニメーションリファレンスを目的に作られています。ただし Maya 式の**デルタ（変更差分）オーバーライド**方式で、マスターシーンにキー・コントローラー・マテリアル・モディファイアなどの**変更差分をレイヤーのように積み重ね**、元データの更新と共存する**汎用リファレンス**に近い製品です。

**同じ「アニメーションリファレンス」でも、アプローチが違います。**

## 2つのアプローチ — 何が違うのか

| | **S製品** | **Fast-Ref** |
|---|----------|-------------|
| **核心の問い** | 「元データが変わっても**自分の上書き修正**は残るか？」 | 「リグが変わっても**自分のアニメーション・Constraint**は残るか？」 |
| **データ方式** | マスターシーンに変更差分(Delta)のみ保存 | 元ファイルを基準にReload/Replace + アニメーション・Constraint専用バックアップ/復元 |
| **元データ更新** | ローカルオーバーライド保持 + 元構造を反映 | Replace後、新リグをマージして**3ds Max公式復元API + OtakuSolutions独自アルゴリズム**で復元 |
| **向いている作業** | アニメーション・マテリアル・モディファイアの**デルタオーバーライド**が必要な汎用コラボ | **リグReplace**中心のゲームキャラアニメ → FBX Export |

Fast-Ref は 3ds Max 組み込みの XRef を「置き換える」汎用ツールではありません。**ゲームスタジオのキャラクターリファレンスパイプライン**を対象としています。

## Fast-Refが特に優れている領域

### 1. リグ更新後のアニメーション維持（Replace）

リガーがボーンを追加したり Rig_v02 をアップロードしたとき、アニメーターが設定したキーが失われてはならない状況に対応しています。

Replace 時に **3ds Max 公式復元 API** と **OtakuSolutions 独自復元アルゴリズム**を組み合わせて以下を保存・復元します：

- Biped · Bone · Prop アニメーション
- **TCB · Position List · Rotation List** などの複雑なコントローラー形式を**完全サポート**（サブチャンネル・レイヤー単位の復元含む）
- Constraint（内部・外部、キャラクター↔小道具の連結を含む）
- IK · Script Controller を含む複雑なリグ
- **Selection Set**（Rig Info ノード活用時は Replace / Reload 後も維持）

> 実務での採用理由として最も多い機能です。数十〜数百本のアクションシーンごとに手動でキーを移動していた作業を、Replace 一回に減らすことができます。

### 2. ゲームエンジン Export

- Reset Root、Remove Namespace
- Unity / Unreal / Unreal_Skel / Unreal_Ani プリセット
- スロット単位・全体 FBX Export
- **Fast Ref Batch** — 複数の `.max` を順次 Reload / Export

### 3. 単一ファイル引き渡し · パイプライン独立性

**Merge** するとリファレンスデータがシーン内に**完全に統合された単一 `.max`** になります。元データのパスなしにファイル一つだけ渡しても開けます。

S製品は **C++ ベースのプラグイン**であり、**チーム全員のインストールが必須**です。未インストール環境でファイルを開くとシーンが壊れる可能性があります。Maya 式のデルタ構造上、**単純に「Max ファイル一つだけを渡す」のも困難**です（Embedded など別途機能が必要）。

Fast-Ref は `Merge` / `Unpack` 後に**純粋な 3ds Max ノード**に戻ります。**プラグインがインストールされていない外注先**にファイルを渡しても**正常に開きます。**  
（クライアントの TA チーム向け**シーンリセットスクリプト**も別途提供）

### 4. 複数キャラクター · Namespace

`Character_01:Head` 形式の **Namespace + `.r1` suffix** により、同じリグを一つのシーンに複数配置する際の名前の衝突を低減します。  
**Smart Switch + Safe Mode** で Space OFF リファレンス作業時の Unpack/Repack を自動処理します。

### 5. スクリプト自動化

**Script API v2.1**（**Python**、UI 独立）— パイプラインスクリプトから Add / Replace / Export などを直接呼び出せます。  
（S製品は **MaxScript** API を提供します。）

## 意図的に異なる設計方針

以下は Fast-Ref の「不足」ではなく、**パイプラインの安全性を確保するための設計選択**です。

### ネスト参照（A→B→C）

Fast-Ref はネスト参照を**推奨しません。**

- どのリファレンスツールでも、ネスト構造は追跡・デバッグ・チームコラボレーションにおいてリスクが高くなります。
- ゲームの**キャラクター**パイプラインでは、A→B→C チェーンが必要な実務シナリオはほとんどありません。
- すでに Fast-Ref 化されたファイルを Add すると **`N` 警告**で通知します。

→ 環境やプロップを**参照の中に参照**として入れ子にする必要がある場合は、S製品または別のパイプラインの方が適しているかもしれません。

### モディファイア · マテリアル — 「マスターシーンで上書き」ではない

Fast-Ref はマスターシーンで Edit Poly を積み上げたりマテリアルをローカルオーバーライドしたりする方式では**ありません。**

- **元の `.max` がマスター**です。
- Reload / Replace 時に元データの**モディファイア・マテリアル・メッシュ構造が自然に反映**されます。
- リグ構造やシェーディングの変更は、**元リグファイル**で行うことが前提です。

→ マスターシーンで**マテリアルやモディファイアをローカル上書き**する作業が多い場合は、S製品のデルタオーバーライドがより適しているかもしれません。

## 機能比較 — 実務基準

### リファレンス · シーン管理

| 項目 | S製品 | Fast-Ref |
|------|:-----:|:--------:|
| 複数リファレンススロット管理 | ✅ | ✅ |
| ネスト参照（A→B→C） | ✅ | △ 推奨しない（`N` 警告） |
| Namespace / Suffix | △ 名前・Prefix 中心 | ✅ Namespace + suffix 体系 |
| ネスト・重複ファイル検出 | — | ✅ `N` / `D` タグ |
| ファイル状態追跡 | Reload オプション別 | ✅ OUTDATED / MISSING / CONVERTED |
| Convert to Reference | — | ✅ |
| **元データなしで単一ファイル引き渡し** | △ デルタ構造上困難（Embedded 等が別途必要） | ✅ **Merge**で単一 `.max` 引き渡し可能 |

### アニメーション · リギング

| 項目 | S製品 | Fast-Ref |
|------|:-----:|:--------:|
| **マスターシーンでキー・コントローラー作業** | ✅ トラック単位オーバーライド | ✅ マスターシーンでキー・アニメーション作業可能。<br />Replace 時に**3ds Max 公式 API + OtakuSolutions 独自アルゴリズム**で復元 |
| **TCB · Position / Rotation List** | △ TCB 部分 **要確認** | ✅ **完全サポート**（List サブチャンネル・レイヤー単位復元） |
| Biped IK · IK Blend 保持 | △（環境・リグにより差異） | ✅ 独自復元アルゴリズム |
| Script Controller リグ | △ 元変数構造変更時リスク | ✅ 独自復元アルゴリズム |
| 外部 Constraint（キャラクター↔小道具） | ✅ オーバーライド | ✅ 独自復元アルゴリズム |
| **Selection Set** | ✅ | ✅ Rig Info ノード活用時に Replace / Reload 後も維持 |
| CAT リグ | ✅ 公式サポート | △ Biped / Bone / Custom 中心（CAT は実務テスト推奨） |
| モディファイア · マテリアル | ✅ マスターシーン ローカルオーバーライド | ✅ **元データ基準で自動反映**（ローカル上書きではない） |

### パイプライン · サポート

| 項目 | S製品 | Fast-Ref |
|------|:-----:|:--------:|
| **定価（永久ライセンス、1シート）** | **$189** | **$95**（Fast Ref Batch 含む） |
| FBX Export（エンジンプリセット） | △ Max 標準 Export | ✅ 内蔵 + Batch |
| バッチ Reload / Export | △ スクリプトを直接構成 | ✅ Fast Ref Batch |
| **スクリプト API** | **MaxScript** | **Python**（Script API v2.0 / 公開予定） |
| 多言語 UI | — | ✅ 日 / 英 / 韓 / 中 |
| **チーム全員のプラグインインストール** | ❌ **必須**（C++ ベース — 未インストール PC でファイルを開くとシーンが壊れる） | ✅ **不要** |
| **外注・未インストール環境へのファイル引き渡し** | ❌ 受け取り側も**インストール必須** | ✅ **インストールなしで引き渡し可能** |
| 対応 Max バージョン | 2020〜2027 | 2022〜2027 |
| ネットワークレンダーノード | 無料 | 無料 |

## 正直な制限 — 導入前にご確認ください

Fast-Ref は万能ではありません。以下は公式ガイド・実務フィードバックに基づく情報です。

| 注意事項 | 説明 |
|----------|------|
| **パスは英語推奨** | UIは日/英/韓/中に対応しています。Pythonベースのため、フォルダ・ファイルパスに日本語・韓国語・中国語・特殊文字があるとエラーになる場合があります。パスは `C:\project\rig\` のように**英語に統一**することをお勧めします。 |
| **Replace の処理時間** | ノード・アニメーションデータが多い場合、バックアップ/復元計算のために数十秒かかることがあります。シーンの規模や IK の有無によって異なります。 |
| **ノード名の変更** | 元データでボーン名を変更するとマッピングが崩れる可能性があります。Namespace で衝突は減らせますが、名前変更自体は元データ・パイプラインのルールで管理することをお勧めします。 |
| **CAT · smartAnim リグ** | Biped / Custom Bone 中心で開発されています。CAT・smartAnim は **14日間 Trial** での事前確認をお勧めします。 |
| **汎用デルタオーバーライド** | マテリアル・モディファイア・環境配置などのマスターシーン変更を一つのツールで管理したい場合は、S製品をご検討ください。 |

## 自分に合っているか — 30秒チェック

| こんなチーム・作業なら | Fast-Ref を検討してください |
|-----------------|------------------------|
| Biped / Custom リグ + アクションシーン数十〜数百本 | ✅ |
| リグ更新後もアニメーション・Constraint・IK の維持が最優先 | ✅ |
| Unity / Unreal FBX + バッチ Export | ✅ |
| 外注・社内ツールへプラグインなしの .max または単一ファイルを渡す | ✅ |
| 同じキャラクターを一つのシーンに複数配置（Namespace） | ✅ |

| こんな作業が中心なら | S製品など別のアプローチを先に検討 |
|---------------------|-----------------------------------|
| アニメーション + マテリアル・モディファイアをデルタオーバーライドで一つのツールで管理 | S製品 |
| A→B→C ネスト参照チェーン | S製品または別の構造 |
| **smartAnim ベースのリギング** | **S製品を検討してください** |
| CAT 専用パイプライン | Trial で事前確認、または以下の FAQ を参照 |

## よくある質問（FAQ）

---

**Q. S製品の代わりに Fast-Ref を使うべきですか？**

A. **どちらもアニメーションリファレンス**を扱います。違いは**方式**です。  
S製品はマスターシーンでのデルタオーバーライドでキー・マテリアル・モディファイアなどの変更差分を維持し、Fast-Ref はリグ Replace 時に専用復元エンジンで Biped IK・TCB List・FBX Export などゲームキャラクターパイプラインに合わせて復元します。  
リグ更新が頻繁なゲームキャラクターアニメが中心なら Fast-Ref、アニメーション・ルックデブ・環境を一つのツールのデルタ方式でまとめたいなら S製品をご検討ください。

---

**Q. マスターシーンでアニメーションキーを設定できますか？**

A. **できます。** Fast-Ref でもマスターシーンでのキー・コントローラー操作が可能です。リグファイルが更新されると Replace 時に **3ds Max 公式復元 API** と **OtakuSolutions 独自復元アルゴリズム**でアニメーション・Constraint・IK などを再調整します。**TCB · Position List · Rotation List** などの複雑なコントローラー形式も完全サポートします。**Selection Set** は Rig Info ノードを活用しているとき、Replace / Reload 後も維持されます。

---

**Q. 元データなしで Max ファイルを一つだけ渡せますか？**

A. **Fast-Ref は Merge で可能です。** リファレンスがシーンに完全に統合された単一 `.max` になるため、元データのパスなしに渡すことができます。S製品は Maya 式のデルタ構造上、単純な引き渡しは困難で Embedded などの別途手順が必要です。

---

**Q. プラグインなしでファイルが開きますか？外注先に渡しても大丈夫ですか？**

A. **Fast-Ref は可能です。** `Merge` / `Unpack` 後は純粋な Max ノードのみになるため、プラグインがインストールされていない外注先にファイルを渡しても正常に開きます。  
一方 S製品は C++ ベースのプラグインのためチーム全員のインストールが必須であり、未インストール環境ではシーンが壊れる可能性があります。

---

**Q. ネスト参照はなぜ推奨しないのですか？**

A. ネスト構造はどのツールでもリスクが高く、キャラクターパイプラインでの実益も少ないです。単一レベルのリファレンスを推奨しており、ネストされたファイルは `N` 警告で表示されます。

---

**Q. モディファイアやマテリアルは変更できませんか？**

A. マスターシーンで上書きする方式ではありません。**元データが変わると Reload/Replace 時に自動反映**されます。変更は元リグファイルで行います。

---

**Q. スクリプトで自動化するには？**

A. Fast-Ref は **Python** API（v2.1）を提供します。S製品は **MaxScript** API を提供します。社内パイプラインの言語に合わせて選択してください。

---

**Q. smartAnim と CAT はサポートされていますか？**

A. Fast-Ref の開発・検証の焦点は、3ds Max リギングの大半が Biped ベースという点に合わせて **Biped / Custom Bone** に当てています。  
CAT・smartAnim パイプラインは公式の主力対象外です。ただし、該当リグへの需要が十分に確認された場合はサポートを検討することがあります。

- **smartAnim ベースのリギング**が中心の場合 → まず S製品を検討することをお勧めします。
- 導入前には **14日間 Trial** で実際のリグファイルを使い Replace / Reload を必ずテストしてください。
- Trial でも不十分でサポートが必要な場合 → [contact@otakusolutions.com](mailto:contact@otakusolutions.com) にリグサンプルとともにお問い合わせください。

---

**Q. 日本語・韓国語・中国語で使えますか？**

A. **UIは日本語・英語・韓国語・中国語に対応しています。** ツール画面や案内文は該当言語で利用できます。  
ただし、プロジェクトのフォルダ・ファイルパスは Python のエンコードの問題を避けるために英語に統一することをお勧めします。（例：`C:\project\rig\character.max`）

## まとめ

```
┌──────────────────────────────────────────────────────────────┐
│  S製品    →  アニメーション・マテリアル・モディファイアなどの  │
│              変更差分をデルタで積み重ね、                     │
│              元データが変わっても維持する汎用リファレンス      │
│              (MaxScript)                                     │
│                                                              │
│  Fast-Ref →  元リグを基準として管理し、                      │
│              リグが変わっても 3ds Max API + 独自アルゴリズムで │
│              アニメーション等を復元                           │
│              (Rig Info 時 Selection Set 維持)                 │
│              Merge · Export                                  │
└──────────────────────────────────────────────────────────────┘
```

Fast-Ref は**ゲームキャラクターアニメーション制作**のために作られました。  
すべての 3ds Max リファレンスニーズに最善の答えではありません — それを明確にお伝えすることが、導入後の満足度を高める道だと確信しています。

*OtakuSolutions · Fast-Ref v1.2.3 基準 · お問い合わせ：[otakusolutions.com](https://www.otakusolutions.com)*