---

# Ep.0 — 왜 Fast-Ref가 필요한가? (XRef의 한계와 플러그인의 필요성)

> slug: ep00_why-fast-ref

https://youtu.be/YBKaFZNNBXE?si=AIoLViwCf5eRLfDl

> **한 줄 요약**: 3ds Max 자체 XRef의 기능적 한계를 낱낱이 파헤쳐 보고, 실무 애니메이션 파이프라인에서 왜 Fast-Ref가 필수적인 솔루션인지 그 배경을 알아봅니다.

---

## 1. 우리가 직면하는 실무의 대참사 (오프닝 시나리오)

3ds Max에서 열심히 애니메이션을 잡고 있는 애니메이터에게 어느 날 메인 리드로부터 청천벽력 같은 연락이 옵니다.
> **"캐릭터 본 구조가 전면 수정될 예정입니다."**

단순히 재킷, 스커트, 모자 파츠가 추가되는 것을 넘어 본 네이밍 규칙마저 소문자 `root`에서 대문자 `Root`로 바뀐다고 합니다.
이 캐릭터가 쓰이는 파일이 단 하나라면 그나마 다행입니다. 하지만 **Walk, Idle, Attack, Run 같은 수십 개의 액션 클립**부터 시작해, 해당 캐릭터가 등장하는 **100~200개의 시네마틱 씬 파일**들이 거미줄처럼 얽혀 있다면 어떨까요?

리깅 파일이 수정되었다는 이유만으로 애니메이터는 이 200여 개의 파일을 일일이 수동으로 열어 업데이트해야 하는 끔찍한 막노동에 직면하게 됩니다. 이것이 애니메이터들이 겪는 가장 무겁고 고통스러운 프로덕션 리스크입니다.

---

## 2. 3ds Max의 'XRef Objects'를 캐릭터 레퍼런스로 써본다면?

3ds Max에서 어떻게든 외부 파일을 참조해서 쓰는 방법을 찾다 보면 가장 먼저 마주치는 것이 기본 기능인 **XRef(외부 참조)** 입니다. 데모 캐릭터인 Mable을 사용해 실제로 XRef Objects 기능을 테스트해보았습니다. (데모 환경: 3ds Max 2027)

XRef Objects 메뉴에서 캐릭터를 로드하면 겉보기에는 화면에 정상적으로 표시됩니다. 하지만 실제로 애니메이션 키를 잡기 시작하면 심각한 문제들이 터져 나옵니다.

### 🔴 실무 애니메이션 적용 시 치명적인 한계점들
* **기본 본(Base Bone) 키잉**: 단순한 점프 포즈 정도는 키가 잡히는 것처럼 보이지만 불안정합니다.
* **커스텀 어트리뷰트(Custom Attribute) 소실**: 리거가 셋업해 둔 손가락 컨트롤러나 표정 어트리뷰트 등 커스텀 데이터가 아예 화면에 나타나지 않거나, 키를 주어도 타임라인에 등록되지 않습니다. 씬 그래프를 확인해 보면 원본에 있던 커스텀 어트리뷰트 데이터가 통째로 사라져 있고, 단지 'XRef Object'라는 껍데기만 남아 있습니다.
* **리깅 파일 교체(Replace) 시 붕괴**: 동일한 골격을 가지고 의상(코스튬)만 다른 버전으로 리그 파일을 교체하려고 시도하면, **전체 리깅 구조가 산산조각 나며 깨져버리는 현상**이 발생합니다.
* **저장 후 다시 열었을 때 데이터 소실**: 어떻게든 키를 억지로 잡고 저장한 뒤 다시 파일을 열어 보면, 연결된 컨트롤러 데이터 링크가 끊기면서 **잡아둔 키 데이터가 완전히 날아가 있습니다.**

> **💡 결론**: 3ds Max의 기본 XRef는 캐릭터 애니메이션을 잡기 위한 레퍼런스 용도가 아닙니다. 건축 시각화(Arch-Viz)나 애니메이션이 없는 단순 소품/오브젝트 배치를 타겟으로 설계된 기능입니다. 전 세계 어떤 프로덕션에서도 XRef를 메인 캐릭터 애니메이션 파이프라인으로 쓰고 있지 못하는 이유가 바로 여기에 있습니다.

---

## 3. Maya와 Blender는 어떨까요? (비교)

* **Maya (Reference)**: 레퍼런스로 캐릭터를 로드하는 속도가 압도적으로 빠르고, 'R' 마크와 함께 참조 상태임이 명확히 표시됩니다. 미리 셋업된 커스텀 어트리뷰트가 완벽히 유지되며, Auto Key를 켜지 않아도 단축키 **S**를 눌러 수동으로 완벽하게 모든 채널에 키를 잡을 수 있습니다. 당연히 리로드하거나 캐릭터를 교체해도 데이터 유실이 전혀 없습니다. 전 세계 마야 기반 스튜디오의 핵심 근간이 되는 기술입니다.
* **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로 바뀌거나 다른 의상 버전으로 교체(Replace)될 때, Biped 모션, 일반 본 애니메이션, 그리고 까다로운 Constraint 관계까지 완벽히 보존하며 교체해 줍니다.
2. **협력사 및 외주 파이프라인 호환성**: 가장 놀라운 점은 **Fast-Ref가 깔려있지 않은 외부 PC에서도 프로젝트 파일(.max)이 아무 문제 없이 잘 열린다**는 것입니다. 따라서 외부 외주 업체에 파일을 넘길 때 툴 종속성 걱정 없이 자유롭게 데이터 공유가 가능합니다.
3. **직관적인 관리 UI**: 씬 안에 어떤 파일들이 레퍼런스로 들어와 있고, 그것이 최신인지 아닌지를 신호등 같은 색상 마크로 바로 모니터링할 수 있습니다.

수동으로 매번 노가다를 반복하며 일정이 늘어지고 씬이 깨지는 지옥 같은 환경에서 벗어나, Fast-Ref를 통해 마야 수준의 안정적이고 구조화된 캐릭터 레퍼런스 파이프라인을 구축해 보시기 바랍니다.

---

# Ep.1 — 레퍼런스 파이프라인 101 (폴더 구조 설계 법칙)

> slug: ep01_reference-pipeline-101

https://youtu.be/nSFv1HpeLnY?si=lxXO4Qg-AhsQrOo5

> **한 줄 요약**: 레퍼런스 시스템을 안정적으로 굴리기 위해 가장 먼저 해야 할 일은 **'마스터 리그 폴더'와 '애니메이션 작업 폴더'를 철저히 쪼개고 섞이지 않게 차단하는 것**입니다.

---

## 1. 이 에피소드가 만들어진 뼈아픈 배경

마야 중심 스튜디오는 뼈대와 애니메이션을 나누는 구조가 기본 규칙으로 정착되어 있습니다. 하지만 3ds Max나 Blender 기반으로 성장한 팀들을 검사해 보면, 생각보다 많은 곳이 정형화된 폴더 규칙 없이 파일을 마구잡이로 섞어 씁니다.
발표자의 경험상 **10개 회사 중 6개 회사**는 폴더 구조가 완전히 뒤엉켜 있었습니다. 리깅 부서가 따로 없고 제너럴리스트가 도맡아 하는 팀일수록 이러한 현상이 심각하게 발생합니다.

Fast-Ref를 도입하기로 마음먹었다면, 툴을 켜기 전에 **폴더 구조를 정리하는 전제 조건**이 반드시 충족되어야 파이프라인이 정상적으로 동작합니다.

---

## 2. 우리가 절대 지켜야 할 두 가지 파일 유형

스튜디오의 애니메이션 파이프라인에는 딱 두 종류의 핵심 파일만 존재해야 합니다.

| 파일 종류 | 들어가야 할 내용 | ❌ **절대 넣으면 안 되는 내용** |
|-----------|------------------|----------------------------------|
| **오리지널 리깅 파일 (Original Rig)** | 스켈레톤, 컨트롤러, 스킨 웨이트, 메시 | **애니메이션 키프레임** |
| **애니메이션 씬 파일 (Animation Scene)** | 리깅 파일을 참조 링크(Add)한 후 잡은 애니메이션 데이터 | 오리지널 리깅 소스 자체의 직접 수정본 |

### 🚨 흔히 범하는 안 좋은 패턴 (Anti-Patterns)
1. **테스트 애니메이션을 오리지널 리그에 저장하는 행위**: "이 리깅 잘 움직이나?" 테스트해 본답시고 마스터 리깅 파일에 키를 준 뒤 무심코 저장해 버리는 상황입니다. (테스트 키는 반드시 임시 파일이나 `.bip`로 따로 저장해 두어야 합니다.)
2. **리그 파일 열고 '다른 이름으로 저장' 해서 애니 시작하는 행위**: 가장 흔하고 끔찍한 파괴적 작업 방식입니다. 원본 리그 파일의 연결 관계를 다 끊어버리고 하드코딩된 단일 파일로 씬을 분리하게 만들어, 리깅 수정 시 씬 전체를 버려야 하는 참사를 낳습니다.
3. **링크 대신 리그를 씬에 통째로 Merge해서 쓰는 행위**: 씬에 무거운 리그 데이터가 가득 찬 상태로 고정되어, 리그 수정 사항을 일절 반영할 수 없게 만듭니다.

---

## 3. 리깅 파일에 애니메이션이 들어갔을 때의 엔진 대참사

실제 어떤 Blender 기반 스튜디오에 애니메이션 TA로 합류했을 때의 실화입니다. 리거에게 "Character A의 마스터 리그 파일이 어디 있나요?"라고 묻자 건네준 리그 파일을 열어보았더니, **캐릭터의 화려한 궁극기 스킬 애니메이션이 default 포즈 상태에 그대로 구워져(Bake) 있었습니다.**
전임자가 애니메이션을 작업한 뒤 깜빡하고 마스터 리깅 파일 위에 그대로 덮어쓰기 저장을 해버렸던 것입니다.

### 😱 바인드 포즈(Bind Pose) 오염이 일으키는 나비효과
- 애니메이션 키가 박힌 리그를 언리얼(Unreal)이나 유니티(Unity) 엔진에 스켈레탈 메시로 임포트하게 되면, **엔진이 인식하는 캐릭터의 최초 기본 자세(바인드 포즈) 자체가 완전히 일그러지게 됩니다.**
- 기본 체형 정보 자체가 망가졌기 때문에, 이후 해당 캐릭터 모델에 아무리 완벽한 애니메이션 클립들을 얹어도 **엔진 안에서는 관절이 뒤틀리고 찌그러지는 끔찍한 렌더링 버그**가 지속적으로 터지게 됩니다.
- 결국 TA가 투입되어 애니메이션 데이터를 일일이 지우고 순수한 디폴트 A-pose/T-pose 상태로 복구해야 하는 불필요한 공수가 발생했습니다.

---

## 4. 부서 간의 명확한 '영역 정리' (권장 NAS 폴더 구조)

수십 명의 아티스트(예: 35~40명 규모의 애니메이션 팀)가 협업하는 환경에서는 완벽하게 격리된 규칙이 필요합니다.

```
Project_Super/ (네트워크 공유 드라이브)
  ├─ rigging/             ← 리거 전용 영토 (리거만 쓰기 권한 있음)
  │   └─ CH_Mable/
  │       ├─ master_mable.max   (애니메이션 키가 0.001초도 없는 클린 리그)
  │       ├─ 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/iixA2dJK3R0?si=7oO0wQsBKoB17TbL

> **한 줄 요약**: 리깅 파일을 복사해서 씬에 붙여넣지 마세요. Fast-Ref **Add**로 깔끔하게 링크만 연결하고, 씬 데이터에 영향 없이 **Remove**로 뺄 수 있습니다. 리그 파일의 상태는 **녹·노랑·X** 신호등 색상으로 5분마다 실시간 갱신됩니다.

---

## 1. Maya 레퍼런스처럼 관리하기

Fast-Ref의 기본 콘셉트는 복잡한 세팅 없이 마야의 직관적인 참조 메커니즘을 3ds Max로 완벽히 복제해 오는 것입니다.
외부 파일과의 **'링크 관계'**만 생성한 채 씬 파일은 아주 가볍게 유지하며, 씬 안에서 일어나는 모든 상태 변경을 전용 테이블 뷰를 통해 간편하게 제어합니다.

---

## 2. Add — 레퍼런스 등록하기

Fast-Ref UI를 열고 원본 리깅 폴더 안의 `.max` 마스터 파일(예: `master_mable.max`)을 선택하여 **Add** 버튼을 누르면 테이블에 등록됩니다.

### 📊 슬롯 등록 시 즉시 활성화되는 제어 버튼들
- 🟢 **녹색 마크**: 현재 디스크상에 존재하는 파일 경로가 유효하며, 내가 열고 있는 이 씬이 **최신의 완벽한 리그 상태**를 참조하고 있다는 증거입니다.
- 👁️ **Visibility (가시성 on/off)**: 해당 레퍼런스를 화면에서 숨기거나 보여줍니다. 한 씬에 캐릭터가 3~4명 이상 등장해 뷰포트가 무거워질 때 유용합니다.
- ❄️ **Freeze (동결)**: 실수로 캐릭터를 드래그하여 마우스로 뷰포트에서 움직이는 실수를 차단하기 위해 원클릭 고정 모드를 지원합니다.
- 🎯 **Selection (선택 도우미)**: 해당 레퍼런스에 속한 복잡한 리그 본 구조들을 단 한 번의 클릭으로 모두 일괄 선택해 주는 기능입니다.

---

## 3. 리거가 리그를 수정했을 때 (노란색 알림 불빛)

네트워크 드라이브 상에서 작업 도중 리거가 리그의 스킨이나 메시 일부를 고쳐서 마스터 파일로 배포하면 어떻게 될까요?
애니메이터가 수동으로 리거에게 "수정됐나요?" 물어볼 필요가 전혀 없습니다. Fast-Ref 테이블에서 즉각 마크가 **🟡 노란색**으로 바뀝니다.
> **"현재 디스크에 있는 파일의 타임스탬프가 최근 수정되었습니다. 애니메이터님, 이 씬은 구버전 기준입니다!"** 라는 친절한 경고입니다.

이때 선택지는 두 가지로 나뉩니다.
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/wkxaUCW9DQY?si=7g6yB1Nn9do

> **한 줄 요약**: 애니메이션이 잡힌 리그를 새로운 리그로 바꿀 때, 기존 작업한 **Biped, Bone 애니메이션, Constraint 관계를 완벽히 유지**하며 교체(Replace)합니다. 또한 동일 캐릭터가 여러 명 등장할 때 충돌하지 않도록 **Namespace 접두사**를 부여하고 제어합니다.

---

## 1. Fast-Ref의 핵심 무기: Replace 워크플로

대부분의 Max 애니메이터들이 가장 좌절하는 순간은 "리깅 데이터가 수정되었으니 새로 작업해야 한다"는 피드백을 받을 때입니다. 뼈대 이름만 바뀌어도 기존에 잡았던 키가 다 깨져나가 처음부터 다시 작업해야 하는 경우가 허다하기 때문입니다.

Fast-Ref의 **Replace** 기능은 이 문제를 완벽하게 우회합니다. 리그 소스 파일 경로를 새로운 버전의 파일로 변경해 주기만 하면, 아래의 핵심 애니메이션 시스템을 자동으로 백업했다가 새 리그에 정밀하게 이식합니다.

### 🛡️ 보존을 보장하는 3대 애니메이션 핵심 자산
1. **Biped 애니메이션**: 골반 위치, IK 정보, 다리/팔의 모션을 유실 없이 완벽히 살립니다.
2. **Bone 애니메이션**: 바이페드가 아닌 일반 Max Bone으로 세팅된 소품이나 망토, 머리카락 애니메이션 역시 백업(.xaf 이식)하여 그대로 가져옵니다.
3. **Constraint (제한자) 관계**: 머리 위에 붙인 장신구나 손에 쥔 무기 등 캐릭터에 설정된 내/외부의 무수한 Constraint 연결 구조를 수동으로 다시 타겟팅할 필요 없이 정확한 씬 전역 맵으로 보존합니다.

이를 통해 수동 복사에 걸리던 작업 시간을 최소 1/10 수준으로 단축하며, 단순 코스튬 교체나 유사 골격을 지닌 다른 캐릭터로의 애니메이션 트랜스퍼 작업까지도 유연하게 처리할 수 있습니다.

---

## 2. Namespace 관리 법칙 (다중 캐릭터 씬의 안전장치)

한 씬 안에 Mable 캐릭터를 2~3개 복사해서 동시에 배치하면 어떻게 될까요?
3ds Max는 기본적으로 동일한 이름의 오브젝트들이 씬에 들어올 경우 이름 뒤에 숫자를 자동으로 붙여 고유하게 바꾸어 버립니다 (`Mable_Bone_01`, `Mable_Bone_02` 등). 이로 인해 리깅 구조와 컨트롤러 링크가 얽혀 씬이 완전히 박살나기 십상입니다.

Fast-Ref는 이를 마야의 표준 방식인 **접두사(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/T-jlxNTNUDc?si=VGjE6yuPEZcDJtZd

> **한 줄 요약**: Fast-Ref는 씬 안정성을 위해 레퍼런스 데이터를 가상의 안전 패키지로 포장해 관리합니다. 만약 사내 레거시 스크립트나 외부 플러그인이 이를 인식하지 못한다면 **Unpack** 기능을 켜서 순수한 원본 씬 구조로 임시 전개해 주면 됩니다.

---

## 1. Fast-Ref 내부의 패키징 메커니즘 이해하기

Fast-Ref는 씬 안의 레퍼런스 데이터가 변질되거나, 맥스 자체의 쓰레기 데이터 정리 프로세스(Garbage Collection) 중 유실되는 현상을 막기 위해 데이터를 특수하게 패키징(가상의 울타리에 보관)하여 관리합니다.
대부분의 일반적인 애니메이션 작업, 뷰포트 탐색, 키 프레이밍은 **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/tuY6WOch4bc?si=aNJ3zjCldsc1m_lE

> **한 줄 요약**: 링크 관계를 완전히 끊고 캐릭터를 현재 씬에 영구 박제하고 싶다면 **Merge**를, 박제된 독립 오브젝트들을 다시 파일 경로와 연결하여 관리하고 싶다면 **Convert**를 실행합니다.

---

## 1. Merge — 링크의 영구 해제와 씬 박제

Fast-Ref 레퍼런스는 언제나 마스터 리그 파일의 변경 점을 실시간으로 추적하는 동적 링크 관계입니다.
하지만 프로덕션의 마지막 최종 납품 단계나, 외주사에 전달하기 위해 **더 이상 외부 파일 경로를 보지 않고 이 단일 맥스 파일 안에 캐릭터 리깅과 애니 데이터를 영구히 병합(Bake)** 시켜 끊고 싶을 때가 있습니다.

- **Merge를 실행하면**: 단 한 번의 클릭으로 가상으로 참조되어 있던 캐릭터 리그 전체가 **현재 `.max` 파일 내에 완전히 실물 노드로 고정 병합**됩니다.
- **적용 결과**: 이 시점부터 리거가 원본 마스터 파일을 아무리 고쳐도, 이 씬 안의 마스터 데이터는 독립되어 영향을 받지 않으며, 다른 PC로 단일 `.max` 파일만 넘겨도 완벽히 열립니다.

---

## 2. Convert — 고아 노드를 다시 레퍼런스 링크로 환원하기

반대로, 수동으로 씬 안에 병합(Merge)해 버렸거나 다른 파일에서 카피해 온 날것의 캐릭터 노드 뭉치가 있다고 해봅시다. 이것들을 다시 Fast-Ref의 안전한 링크 관리 하에 두고 리비전을 추적하고 싶을 때 **Convert** 기능이 활약합니다.

1. 씬 안에 떠돌아다니는 합쳐진 캐릭터 본 그룹을 지정하고 **Convert**를 실행합니다.
2. 해당 데이터가 Fast-Ref 테이블 상의 임시 제어 슬롯으로 환원 등록됩니다.
3. 이제 이 슬롯이 가리킬 디스크상의 **마스터 리깅 파일 경로**를 수동으로 재지정(Point)해 주면, 완벽한 파일 레퍼런스 관계가 다시 활성화됩니다.

---

## 3. Remove vs Merge 확실하게 구분하기

많은 아티스트들이 씬에서 레퍼런스를 걷어낼 때 두 메뉴를 혼동합니다.

* **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/Jn6h0dS-0LA?si=nKB81W0I0j_p7uF0

> **한 줄 요약**: 사내 파이프라인 규칙상 Namespace를 **Off**한 채로 일해야만 하는 아티스트도, 리그 교체 시 다른 캐릭터 노드가 지워지는 등의 참사 없이 **안전한 Replace를 백그라운드에서 지능적으로 대행해 주는 오토 매직 기능**입니다.

---

## 1. Namespace Off 워크플로가 안고 있는 치명적인 위협

가장 이상적이고 안전한 Fast-Ref 워크플로는 네임스페이스(`캐릭터명:본이름` 구조)를 항상 켠 채로 일하는 것입니다.
하지만 회사의 특수 엔진 익스포터 스크립트 제약 때문에 어쩔 수 없이 **Namespace를 완전히 끄고(Off), Unpack까지 활성화한 상태**로 일해야만 하는 스튜디오들이 많습니다.

이 상태에서 씬 안에 여러 캐릭터가 동시에 있는 경우, Namespace 접두사가 없기 때문에 본 이름들이 모두 똑같습니다 (`root`, `L_Thigh` 등). 이 상황에서 한 캐릭터의 리그만 바꾸겠다고 Replace를 시도하면 어떤 일이 벌어질까요?
- 맥스 엔진이 동일한 이름의 다른 캐릭터 노드를 타겟으로 오해합니다.
- 교체 도중 **옆에 얌전히 잘 있던 엉뚱한 다른 캐릭터 노드가 통째로 날아가 삭제되거나 꼬여버리는 치명적인 병합 참사**가 터집니다.

그렇기 때문에 과거 구버전에서는 안전을 위해 네임스페이스가 하나라도 꺼져 있으면 Replace 자체를 아예 막아버리고 경고창을 띄워 아티스트를 중단시켰습니다.

---

## 2. 수동의 지옥에서 탈출하기: "Smart Switch"의 탄생

매번 리그를 수정할 때마다 아티스트가 손으로:
1. `Namespace Activate On` 토글 켜기 (안전 패키징 전환)
2. `Replace` 실행하여 리그 교체 완료
3. 교체가 끝나면 다시 `Namespace Off`, `Unpack On`으로 되돌리기

이 삼단계 노가다를 수동으로 반복하는 것은 극도로 귀찮을 뿐만 아니라, 중간에 한 단계라도 실수로 빠뜨리면 씬을 통째로 날리게 됩니다. **Smart Switch(스마트 스위치)**는 이 전체 과정을 오토메이션화했습니다.

---

## 3. 스마트 스위치가 백그라운드에서 대행하는 흐름

Options 메뉴의 **Smart Switch** 옵션을 체크해 두기만 하면, 툴이 알아서 다음과 같이 기적적인 트릭을 실행합니다.

```
[Replace/Reload 명령 인식] ──► 1. 임시로 Namespace On (안전 가상 쉘 가두기)
                                           │
                                           ▼
                                 2. 안전하게 1:1 매핑 Replace 실행 (다른 캐릭터 간섭 제로)
                                           │
                                           ▼
                                 3. 교체 성공 후, 원래 쓰던 Namespace Off / Unpack On으로 완벽 복원
                                           │
                                           ▼
[아티스트 작업 화면 확인] ──► 네임스페이스는 여전히 Off, 레이어도 원래 상태로 완벽 정리!
```

이 지능형 시퀀스 덕분에 아티스트는 백그라운드에서 어떤 일이 일어나는지 신경 쓸 필요 없이, 오직 자신의 평면적인 작업 화면 구조에만 몰입하면서 리그를 자유롭게 업데이트할 수 있게 되었습니다.

---

## 4. 옵션을 꺼 두어도 작동하는 실무 안전 프롬프트

만약 Options 메뉴에서 Smart Switch를 깜빡하고 끈 상태에서 위험한 Namespace Off 슬롯을 Replace 하려 하면 어떻게 될까요?
무조건 작업을 블락하는 대신, 영리하게 팝업창이 뜹니다.
> **"현재 세팅이 위험합니다. 안전한 교체를 위해 스마트 스위치 도우미를 이번 교체에 임시 적용할까요?"**

여기서 **Yes**를 선택하면 해당 교체 단 한 번만 스마트 스위치가 안전하게 백그라운드 대행을 돌려 해결해 줍니다.

💡 **체감 참고**: 스마트 스위치가 켜지면 내부적으로 네임스페이스 임시 할당, 노드 격리, 안전 복원 시퀀스가 한 바퀴 더 구르기 때문에 **일반 naive 교체보다 아주 약간 시간이 더 걸릴 수 있습니다.** 이는 씬의 안전을 완벽히 수호하기 위한 정밀 물리 연산 단계이므로 안심하고 3~4초 더 기다려 주시면 됩니다.

---

# Ep.7 — 게임 엔진용 FBX 익스포트 (첫 시작 파이프라인 개요)

> slug: ep07_fbx-export-overview

https://youtu.be/JhU9KESPbaU?si=vki7-d0X7m6dxrlK

> **한 줄 요약**: Fast-Ref는 단순한 3ds Max 내부 씬 참조 툴에 그치지 않고, 작업 완료 후 **Unreal이나 Unity 엔진으로 데이터를 한 번에 밀어내어 배포할 수 있는 강력한 전용 FBX 익스포터**를 내장하고 있습니다.

---

## 1. 씬 관리에서 게임 엔진 배포까지, 단일 파이프라인 구축

많은 개발팀들이 애니메이션 키를 잡는 작업 환경과, 이를 파일로 뽑아 게임 엔진(Unreal, Unity 등)에 임포트하는 환경을 각기 다른 수제 툴로 분리해 씁니다.
그러나 수제 툴들이 제각각 작동하면 버전 관리가 꼬이고, 뼈대 축이나 네임스페이스 규칙이 엉켜 엔진에서 애니가 뒤틀리는 사고가 빈번합니다.

Fast-Ref는 애니메이션 제작부터 최종 게임 엔진 임포트 규격에 최적화된 파일 배포까지 **단 하나의 UI 흐름 하에 통합(All-in-One)** 하도록 고안되었습니다.

---

## 2. FBX 익스포트 진입로 및 핵심 특징

Fast-Ref 메인 윈도우 상단의 **Tools** 메뉴를 열면, 즉시 익스포트 시퀀스에 접근할 수 있습니다.

- **원클릭 단일/일괄 익스포트**: 씬에 잡힌 단 한 명의 캐릭터만 즉시 뽑거나, 한 씬에 등장하는 3~4명의 캐릭터 데이터를 각각 한 번에 나누어 개별 FBX로 출력할 수 있습니다.
- **통합 FBX 옵션 시스템**: 메인 창의 단일 익스포터와, 수십 개의 max 파일을 일괄 처리하는 **Batch Tool(EP09)**이 **완전히 동일한 글로벌 FBX 설정 값**을 공유하므로, 아티스트나 배치가 각기 다르게 출력하여 버그가 발생하는 대참사를 원천 방지합니다.

---

## 3. 철저한 엔진 실무 검증 완료 (Unreal & Unity)

오타쿠솔루션즈는 Fast-Ref를 개발하며 가상 시나리오가 아닌, **실제 대규모 게임 개발 프로덕션 현장의 TA, 리거, 시네마틱 애니메이터 팀들과 긴밀히 협업하여 Unreal Engine 및 Unity 빌드 환경 하에 철저하게 익스포트 결과물을 사전 검증**했습니다.

- 뼈대 축 뒤틀림 현상 방지
- 네임스페이스 제거 호환성
- 본 스케일링 변형 오류 제거

이처럼 엔진 빌드 파이프라인에 즉시 태울 수 있도록 사전에 완전히 정제된 FBX 익스포터이므로, 세부 옵션만 세팅해 두면 신뢰하고 실무 엔진 임포터에 태우실 수 있습니다.

---

## 🎯 익스포트 정복을 위한 로드맵
* **지금 (EP07)**: "아, Fast-Ref 안에서 엔진용 fbx까지 완벽하게 호환 처리해 주는구나!" 개념 파악
* **다음 (EP08)**: fbx 옵션 패널을 열어, 실무에서 애니 클립만 뽑을 때 왜 Skin을 꺼야 하고 Smooth Group은 왜 필요한지 낱낱이 해부
* **마지막 (EP09)**: 이 옵션을 적용해 씬 20여 개를 밤새 자동으로 뽑아내 주는 Batch Tool 활용법 습득

---

# Ep.8 — FBX Export Options (실무 엔진 임포트용 상세 옵션 가이드)

> slug: ep08_fbx-options

https://youtu.be/afkE93EkaHM?si=ZT6Pt09ddX46uM8F

> **한 줄 요약**: FBX 옵션 창의 **상단 영역은 3ds Max의 기본 FBX 익스포트 기능**을, **하단 영역은 Fast-Ref가 독자 제공하는 네임스페이스 제거·루트 정렬·변수식 파일명 생성 기능**을 다룹니다. 한 번 맞추어 둔 옵션은 Preset으로 저장해 일괄 공유하세요.

---

## 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** | 얼굴 표정에 쓰이는 블렌드 쉐이프(Blend Shape / Morph) 데이터 포함 유무 | 페이셜 애니메이션이 쓰이는 메인 캐릭터라면 무조건 **켜둡니다.** |
| **Bake Animation** | 원본 프레임 레이트와 무관하게 1프레임 단위로 키를 굳혀 저장 | 엔진 내부 물리 보간 충돌을 막기 위해 **무조건 켜두는 것(Bake On)**이 애니메이션 찌그러짐을 방지하는 실무 표준입니다. |
| **Smooth Groups** | 3D 메시 면들의 매끄러운 쉐이딩 정보 저장 | **무조건 켜둡니다.** 이걸 실수로 끄고 엔진에 올리면 이쁜 캐릭터가 **마치 마인크래프트 캐릭터처럼 온통 거칠고 각진 상태**로 출력되는 대참사가 터집니다. |
| **Texture Embed** | 캐릭터 이미지 텍스처 소스 자체를 fbx 파일 내에 이진 데이터로 강제 내장 | **무조건 꺼둡니다(Off).** 이를 켜는 순간 fbx 파일 하나에 수십 메가의 이미지가 꼬여 파일 용량이 통제 불능 상태가 됩니다. 경로는 3D 씬 내부에서 상대 경로로만 관리하게 두세요. |
| **Up Axis** | 게임 엔진이 기준 삼는 '하늘 방향' 축 설정 | - **Unreal Engine**: 3ds Max와 결이 같은 **Z-up** 축 설정<br>- **Unity Engine**: Unity 프리셋 단추를 누르면 **Y-up** 축으로 자동 매핑 조정됨 |
| **Units** | 엔진 안의 스케일 단위 맞춤 | 3ds Max는 기본 cm 스케일을 씁니다. 유니티(m 단위 선호) 등 아웃풋에 맞추어 스케일 계수를 꼭 유니티용 프리셋을 통해 수동 매핑 검증해 주셔야 축소/비대화 버그가 없습니다. |
| **File Version** | FBX 내보내기 파일 포맷 연식 | 현재 업계에서 가장 오류가 적고 안정적인 **FBX 2020** 포맷으로 통일해 두는 것이 권장됩니다. |

---

## 3. Fast-Ref 전용 특수 익스포트 제어 영역 (하단)

오직 Fast-Ref 안에서만 제공하는 실무 중심의 자동화 기능들입니다.

### ✂️ Remove Namespace (네임스페이스 자동 박탈)
씬 안에 멀티 배치를 위해 임시로 붙여 둔 `Mable_A:L_Hand` 같은 이름에서 접두사를 강제로 떼어내어, 엔진 임포터에는 순수 원본 뼈대인 `L_Hand` 이름으로만 저장해 전송합니다. 엔진 안에서 리타겟팅이 깨지는 현상을 우려하지 않아도 됩니다.

### 🎯 Reset Root (루트 본 원점 강제 동결)
캐릭터가 월드 공간 앞으로 뛰어 나가는 애니메이션이 박혀 있더라도, 엔진 내부 루트 모션 연산이나 바인딩 규칙을 위해 **최상위 루트 본(Root Bone)의 원점(0,0,0) 위치와 회전을 강제로 묶어둔 채 출력**해야 할 때가 있습니다.
- 특정 루트 본 이름을 인식해 원점으로 강제 홀드하고, 원할 경우 Z축 90도 같은 보정 회전을 주어 캐릭터 전방 방향을 정렬합니다.
- 🚨 **주의점 (매우 중요)**: 이 기능은 익스포트 순간에 강제로 캐릭터 씬 좌표를 임시 연산하므로, **FBX를 추출한 직후 해당 작업용 `.max` 파일은 세이브(Save)하지 않고 닫아야 씬 애니메이션이 오염되지 않습니다.** 리드가 아티스트들에게 강력하게 박아두어야 할 꿀팁입니다.

---

## 4. 변수식 파일 네이밍 룰 설계

출력될 fbx 파일의 이름을 아티스트가 일일이 적지 않고, 아래의 다이내믹 변수를 조합해 식(Rule)으로 정의해 두면 파일명이 자동 생성됩니다.

* `[Original File Name]`: 현재 씬 맥스 파일명
* `[Namespace]`: 해당 캐릭터에 부여된 고유 이름
* `[Date]`: 오늘 날짜 자동 스탬프
* `[Auto Namespace / Index]`: 캐릭터가 씬에 단 한 명이면 굳이 이름을 붙이지 않고 깔끔한 원본 명으로 뽑고, **2명 이상 존재함이 감지되는 순간 자동으로 이름 구분을 위해 `파일명_Yuna`, `파일명_Mila` 등으로 자동 전개 분리**하여 번호를 붙여주는 대단히 똑똑한 자동화 연산입니다.

### 🏷️ Create Rigging Data (Export to Selection - ES 태그)
아티스트가 뷰포트 전체를 잡고 뽑지 않고, 리거가 캐릭터 마스터 셋업 시 등록해 둔 **Selection Set 이름(예: Export Body)**을 읽어서 메시 및 스키닝 웨이트 데이터만 정밀 필터링해 뽑아줍니다. 문법이 꼬여서 익스포터가 해매면 패널 우측에 직관적인 붉은 에러 마크로 알려 주므로 확인 후 수정이 용이합니다.

### 📁 Create Subfolder Per Max Files (씬 파일당 서브 폴더 분리)
- **체크 On**: 컷 단위 시네마틱 씬처럼 여러 캐릭터가 마구 얽혀서 뽑혀야 할 때, 작업용 씬 명으로 하위 폴더를 자동 생성해 묶어주므로 데이터 정리가 편합니다.
- **체크 Off**: 일반 액션 루프(Run, Walk, Idle)처럼 한 캐릭터의 모션 클립만 플랫하게 쏟아내야 할 때 추천합니다.

<!-- [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/sCv6kRaUKSk?si=bh_bYs64miCM9jRz

> **한 줄 요약**: 수십 개의 애니메이션 맥스 파일을 하나씩 열고, 갱신된 리그를 적용하고, 캐릭터별로 FBX를 다시 뽑는 가혹한 단순 노가다를 단 한 번의 배치 설정으로 자동화(Batch)해 주는 야간 작업 특화 생산성 부스터입니다.

---

## 1. Batch Tool의 실무 가치 체감하기

예를 들어 다음과 같은 상황이 있습니다.
> **"한 씬에 달리기 동작을 수행하는 캐릭터 3명이 등장합니다. 이런 씬이 총 3개(3개의 시네마틱 컷) 존재합니다."**

리그 파일이 v2로 업데이트되었을 때, 이 3개의 씬에 대해 아티스트가 직접 업데이트하고 익스포트해야 하는 횟수는 총 **9번(3 캐릭터 x 3개 파일)** 입니다.
만약 파일이 20개, 캐릭터가 5명이라면 100번이 넘는 수작업이 강제됩니다.
Fast-Ref의 **Batch Tool**은 아티스트가 퇴근하기 전 이 100여 개의 수동 공정을 단 한 번의 버튼 클릭으로 밤새 알아서 컴퓨터가 일하도록 세팅하는 궁극의 배치 처리 자동화 창입니다.

---

## 2. 배치 툴 진입 및 구성

메인 Fast-Ref 윈도우의 **Tool -> Batch Tool** 메뉴를 클릭하면 독립적인 배치 제어용 대형 다이얼로그 창이 전개됩니다.
(메인 Fast-Ref 시스템에 내장되어 단일 라이센스로 무상 통합 제공됩니다.)

---

## 3. 핵심 자동화 기능 (양대 축)

배치 프로세서는 아래의 두 단계를 순차적으로, 혹은 개별적으로 완벽히 오토메이션 처리합니다.

### 🔄 1. Reload (일괄 레퍼런스 업데이트)
- 등록된 목록 안의 각 max 파일을 차례로 조용히 엽니다.
- Fast-Ref 분석기(Engine)를 가동해, 해당 씬 내부의 어떤 캐릭터 리그가 디스크의 최신 버전(노란색 알림 등) 상태보다 구버전인지 감지합니다.
- 자동으로 최신 리그로 리로드(Reload)하여 연결 구조와 신형 뼈대, 스킨을 반영합니다.

### 📤 2. Export FBX (일괄 엔진용 배포 추출)
- 리로드가 성공적으로 끝난 캐릭터의 뼈대와 애니메이션을 읽어들입니다.
- EP08에서 미리 세팅해 둔 글로벌 FBX 프리셋 규칙(네임스페이스 제거, 스킨 Off 여부, 루트 원점 동결 등)을 호출합니다.
- 각 파일별, 혹은 파일 내 캐릭터 슬롯별로 고유한 FBX 파일을 씬 외부 폴더로 일괄 쏟아내 줍니다.

---

## 4. 안전한 배치 실행 세부 셋업 가이드

배치를 처음 돌릴 때 원본 파일 훼손이 걱정된다면 아래의 안전장치 세팅을 확인하세요.

- **Reload 씬 저장 경로 분기**:
  - **Overwrite**: 갱신된 최신 리그 상태를 원본 작업 파일 위에 그대로 덮어씁니다. (파이프라인이 완전 안정화되었을 때 사용)
  - **Custom Path**: 원본은 절대 건드리지 않고, 지정한 별도 백업 디렉터리(`D:/FR_Backup/` 등) 안에 리로드 완료된 새 `.max` 파일을 복제해 모아줍니다. (초기 검증 및 강력 추천 옵션)
- **FBX 아웃풋 경로 지정**: 최종 게임 엔진 리소스 폴더(Content/Character 등)의 타겟 경로를 정해 두면, 배치 성공 즉시 엔진 측에 갱신된 데이터가 한 번에 꽂힙니다.

---

## 5. 결과 확인 및 상세 디버깅 로그

배치가 백그라운드로 밤새 구동되는 와중에 오류가 발생한 파일이 있는지 확인하는 기능입니다.
- 배치가 모두 완료되면, 완료된 슬롯들은 화사한 **🟢 녹색 박스**로 시각적 패스를 안내해 줍니다.
- 에러가 나거나 Skip된 파일이 있다면, 배치 창 하단의 **Open Folder** 버튼을 눌러 로그 디렉터리를 엽니다.
- 자동으로 생성된 상세 로그 텍스트를 메모장으로 열어 보면, 어느 씬의 몇 번째 프레임에서 오류가 났는지, 어떤 데이터가 누락되었는지를 직관적인 텍스트로 트래킹할 수 있어 교정이 매우 빠릅니다.

---

## 💡 실무자의 시선: "우리가 자체 툴을 만들지 않는 이유"

큰 규모의 스튜디오들은 대개 인하우스 TA팀이 엄청난 공수를 들여 자체적인 대량 배치 툴을 만듭니다. 하지만 유지 보수가 어렵고 맥스 신 버전 호환 시 매번 에러를 뿜기 일쑤입니다.
Fast-Ref의 배치 툴은 이미 언리얼/유니티 연동 안정성, 백그라운드 리로드 무실패 구조가 수많은 프로덕션에서 수만 장의 파일로 검증된 기성품 엔진이므로, 스튜디오에 태우는 순간 개발팀 전체의 파일 배포 리드가 비약적으로 축소됩니다.

---

## 📞 사용자 지원 및 피드백 채널
작동 도중 특수한 커스텀 컨트롤러 셋업 때문에 본 배치가 스킵되거나 예상과 다르게 꼬이는 파일이 발견되면, 지체 없이 **오타쿠솔루션즈 테크니컬 서포트 팀 공식 이메일**로 원본 씬과 증상을 보내주세요. 실무 담당 TA가 면밀히 분석하여 신속하게 핫픽스를 제공해 드립니다.

---

# Ep.10 — Rigging Info (공통 리깅 데이터와 셀렉션셋 자동 복원)

> slug: ep10_ri01-rig-structure-fbx

https://youtu.be/sVRz95C60-U?si=388fsFO31dNJnTl_

> **한 줄 요약**: 패스트레퍼와 바이패드플러스가 공유하는 **Rigging Info(리깅 인포) 노드**를 활용하여, 씬 로드 속도를 극대화하고 3ds Max의 고질적인 **셀렉션셋 소실 버그**를 우회하며, FBX 익스포트 범위를 정밀 제어하는 고급 셋업법을 배웁니다.

---

## 1. 리깅 인포(Rigging Info)란 무엇인가요?

처음 접하면 이름이 다소 생소하고 복잡하게 느껴질 수 있지만, 개념은 매우 명쾌합니다.
**Rigging Info**는 오타쿠솔루션즈의 두 핵심 플러그인인 **패스트레퍼(Fast-Ref)**와 **바이패드플러스(Biped Plus)**가 공통으로 씬(Scene) 내부의 특정 노드에 기록하고 공유하는 **'리깅 메타데이터(Metadata) 저장소'**입니다.

### 🔌 진입로 (동일한 노드에 데이터 저장)
* **패스트레퍼**: 상단 메뉴 혹은 '리깅 데이터 생성(Create Rigging Data)' 버튼을 통해 접근
* **바이패드플러스**: 바이패드플러스의 에디트(Edit) 창을 통해 접근

이 메타데이터 노드에는 바이패드 이름, 바이패드 노드 계층 정보, 커스텀 컨트롤러 목록, 스킨드 메시 본 정보 등이 함축되어 저장됩니다.

이 데이터를 리그 원본에 미리 구워두면, 패스트레퍼가 씬을 새로 불러오거나 교체(Replace)할 때 **매번 전체 노드를 일일이 검사할 필요가 없어지기 때문에 구동 및 매핑 속도가 비약적으로 빨라지고 훨씬 안전**해집니다.

---

## 2. 컨트롤러 리스트(Controller List)에 담아야 할 요소들

바이패드(Biped) 기본 골격을 제외하고, 애니메이터가 조작해야 하는 씬 안의 모든 제어 장치(컨트롤러)를 이 리스트에 등록합니다.

* **일반 본(Bone) 및 컨트롤러**: 망토, 머리카락, 치마, 소품 제어용 보조 본
* **시뮬레이션 본**: 애니메이터가 자주 활성화하는 다이내믹/시뮬레이션용 본 계층 구조
* **페이셜 및 모퍼(Morpher) 데이터**: 표정 애니메이션 키가 들어가는 모프 타겟 데이터
* **와일드카드(`*`) 지원**: 본이나 컨트롤러가 수십~수백 개일 때, 이름 앞에 특정 접두어가 붙어 있다면 와일드카드를 사용해 (예: `Prop_*`) 한 번에 골라 일괄 등록할 수 있습니다.

> 💡 **실무 팁**: 표정 제어 장치 등이 이미 **페이셜 UI 스크립트**에 리깅으로 단단히 묶여 연동되어 있다면, 굳이 이 리스트에 수동으로 컨트롤러를 한 땀 한 땀 추가할 필요는 없습니다. 키가 직접 박히는 핵심 독립 본 위주로만 세팅해 주세요.

---

## 3. 3ds Max의 고질적인 '셀렉션셋(Selection Set)' 버그 우회하기

많은 게임 프로덕션에서 스킨용 본만 따로 고르거나(`Skin Bones`), 특정 의상 메시만 따로 고르기 위해(`Skins`) 3ds Max의 **셀렉션셋(Selection Set)** 기능을 요긴하게 씁니다.

### 😭 3ds Max의 치명적인 셀렉션셋 버그
- 리깅 원본 파일에 아무리 열심히 셀렉션셋을 만들어 저장해 두어도, **이를 외부에서 머지(Merge)하거나 새 씬에 불러올 때 셀렉션셋 데이터가 자동으로 복원되지 않고 소실되는 맥스 자체의 만성적인 버그**가 있습니다.

### 😎 패스트레퍼의 해결책
- 리그 원본에서 셀렉션셋(`Skin Bones`, `Skins` 등)을 만든 뒤, 리깅 인포 메뉴에서 **데이터 업데이트 후 저장(Refresh Save)**을 누릅니다.
- 이렇게 하면 셀렉션셋 데이터가 리깅 인포 메타데이터 노드 내에 암호화되어 안전하게 기록됩니다.
- 이제 패스트레퍼를 통해 캐릭터를 불러오면, **맥스의 버그를 비웃듯이 리깅 데이터와 함께 우리가 셋업한 셀렉션셋이 완벽하게 백업 복원**되어 씬에 나타나는 기적을 경험하실 수 있습니다.

---

## 4. FBX 익스포트 범위 정밀 제어 (Auto vs Defined)

패스트레퍼의 강력한 내장 FBX 익스포터는 리깅 인포에 등록된 메타데이터를 기반으로 추출 대상 본을 지능적으로 선별합니다.

### 🟢 Auto Mode (자동 모드)
- 스킨드 메시(Skinned Mesh)에 등록된 모든 인플루언스(Influence - 스킨 영향을 받는 본들)를 추출 기준으로 자동 합산해 처리하는 모드입니다.
- 스킨 정보가 명확히 입혀져 있다면 이 모드만으로 완벽한 FBX 아웃풋이 나옵니다. 만약 스킨이 안 발려 있는 특수 본 모션도 같이 뽑고 싶다면, 해당 본을 **컨트롤러 리스트**에 얹어주기만 하면 스킨 유무와 상관없이 추출 대상에 자동으로 합산됩니다.

### 🔵 Defined Mode (정의된 셀렉션셋 모드)
- 만약 캐릭터 본체 메시와 오른손에 쥔 "무기 데이터(Prop)"를 **따로 떼어 각각 개별 FBX로 독립 추출**하고 싶다면 어떻게 해야 할까요?
- **예시**: 무기 메시와 무기용 본들을 한꺼번에 묶어 셀렉션셋 이름을 **`Export Props`**라고 지정해 씬에 저장하고 리깅 인포를 업데이트합니다.
- 패스트레퍼 익스포터에서 **Defined Mode**로 전환하면, 기록된 셀렉션셋 목록이 화면에 나타납니다.
- 여기서 `Export Body`와 `Export Props`를 **동시에 체크하고 내보내면, 무기 FBX와 본체 FBX 두 개의 파일이 단 한 번의 클릭으로 완벽히 자동 분할 추출**됩니다.

---

## 5. 패스트레퍼 UI 상의 신비로운 'R'과 'ES' 태그의 비밀

리깅 인포 셋업이 완료된 리그 파일을 패스트레퍼 테이블에 등록하면, 슬롯 우측에 **[ R ]** 과 **[ ES ]** 라는 특별한 태그 아이콘이 표시됩니다.

* **`R` (Read Mode / 리드 모드)**: 이 캐릭터에는 리깅 인포 메타데이터가 정상 장착되어 있어서, 로딩 및 교체 시 원본 구조 분석 단계가 극도로 단축되어 초고속 인식이 가능하다는 쾌적함의 상표입니다.
* **`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가 있는 경우 | 리깅(Rig)에는 없으나, 애니(Ani) 파일에서 컨스트레인트가 존재하는 경우 |
| **알고리즘 동작** | “원본과 동일함”, “원본 리깅 우선”으로 판단하여 무시 | "사용자 데이터"로 판단하여 별도 기록 및 복원 |
| **설계 의도** | 불필요한 컨스트레인트 처리를 생략함으로서 최적화 | 애니 및 컨스트레인트 추가 사항이 애니에 자동 반영되도록 함 |

- **[Skip] 리깅 원본과 동일한 경우:**
    - 리깅(Rig) 파일  : 자체에 이미 컨스트레인트(포인트, 오리엔트,링크 등)이 걸려 있고,
    - 애니(Ani) 파일 : 에서도 컨스트레인트(포인트, 오리엔트,링크 등)이 걸려 있다면
    ⇒ 이는 "리깅의 기본 상태"로 판단하여 복원 리스트에서 제외합니다. (리깅 수정 사항이 자연스럽게 반영되도록 하기 위함)
- **[Restore] Fast-Ref로 생성된 새로운 변화:**
    - 리깅 파일에는 없지만, **작업자가 Fast-Ref 기능을 통해 추가한**  컨스트레인트 는 "사용자의 작업한 애니메이션 데이터"로 인식하여 별도 레이어에 기록하고 교체 및 리로드 시 참고하고 복원합니다.

---

### 3. 문제 원인 (Root Cause)

윗 애니메이터님이 겪으신 이슈는 알고리즘의 **'판단 로직'**에서 발생한 예외 상황 때문입니다.

1. **데이터 오인식:** 리깅 파일에도 / 애니 파일에도 이미 컨스트레인트가 걸려 있는 상태에서 작업을 하니, 툴이 "이건 사용자가 새로 만든 게 아니라 원래 리깅에 있던 거야"라고 착각하여 **복원 대상에서 누락(Skip)**시킨 것입니다.

---

### 4. 해결 방법 (Solution)

사용자의 의도를 100% 반영하기 위해 알고리즘을 다음과 같이 업데이트합니다.

### **A안: 리깅 파일의 클린업 (최적화)**

알고리즘이 원본과 작업본을 비교할 때 혼동을 주지 않도록 리깅 파일을 깨끗하게 유지하는 방법입니다.

- **설명**: 리깅 원본 파일에는 무기(Prop) 같은 요소에 미리 **Link Constraint를 걸어두지 마세요.**
- **이유**: 원본에 이미 링크가 있으면, Fast-Ref는 애니메이션 파일에서 사용자가 새로 설정한 링크를 **"원래부터 있던 것"**으로 착각하여 복원 대상에서 제외(Skip)할 수 있기 때문입니다.
- **권장**: 무기는 그냥 바닥에 놓인 채로(Clean) 두고, 링크 작업은 애니메이터가 애니메이션 씬에서 **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는 리깅 파일을 불러올 때 최적의 상태를 유지하기 위해 자동으로 애니메이션을 정리(Clean-up)하는데, 원본에 테스트 애니메이션 등이 포함되어 있으면 알고리즘 상 혼선이 생겨 데이터가 유실될 수 있습니다.

---

### 4. 해결 방법 (Solution)

### ✅ 방안 A. 리깅 원본 데이터 정리 (권장)

- 리깅 원본 파일 내의 불필요한 테스트 애니메이션은 가급적 정리해 주세요. 데이터 구조를 가장 깨끗하게 유지하는 방법입니다.

### ✅ 방안 B. 자동 정리 옵션 일시 해제

- **[Option]** → **[General Option]**에서 **`Auto CleanUp Animation`** 체크를 해제합니다.
- 단, 이 설정은 데이터 보존이 필요한 경우에만 **1회성으로 사용**하시고, 평상시에는 최적화를 위해 다시 체크해 두시는 것을 권장합니다.

![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 환경과 요구사항을 저희 측에 공유**해 주시는 것입니다. 저희가 직접 가이드라인을 제공해 드리는 과정에서 의외로 더 간단한 해결책을 찾을 수 있는 경우가 많습니다.

구조 파악이나 연동 과정에서 기술적인 지원이 필요하시다면 언제든지 아래 연락처로 문의해 주시기 바랍니다.

**오타쿠 솔루션즈는 여러분의 유연한 파이프라인 구축을 적극 지원합니다.**

---

# 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식 **델타(변경분) 오버라이드** 방식으로, 마스터 씬에서 키·컨트롤러·재질·모디파이어 등 **변경분을 레이어처럼 쌓아** 원본 업데이트와 공존하는 **범용 레퍼런스**에 가깝습니다.

**같은 "애니 레퍼런스"라도, 접근 방식이 다릅니다.**

## 두 가지 접근 — 무엇이 다른가

| | **S제품** | **Fast-Ref** |
|---|----------|-------------|
| **핵심 질문** | "원본이 바뀌어도 **내가 덧씌운 수정**이 남아 있나?" | "리그가 바뀌어도 **내가 잡은 애니·Constraint**가 남아 있나?" |
| **데이터 방식** | 마스터 씬에 변경분(Delta)만 저장 | 원본 파일을 기준으로 Reload/Replace + 애니·Constraint 전용 백업/복원 |
| **원본 업데이트** | 로컬 오버라이드 유지 + 원본 구조 반영 | Replace 시 새 리그 merge 후 **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식 델타 구조상 **단순히 "맥스 파일 하나만" 넘기기도 어렵습니다.** (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에서 파일 열면 씬 깨짐) | ✅ **불필요** |
| **외주·미설치 환경에 파일 전달** | ❌ 수신 측도 **반드시 설치** 필요 | ✅ **설치 없이 전달 가능** (Merge / Unpack 시 순수 Max 노드, 안 깨짐) |
| 지원 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 참고 |

## 자주 묻는 질문

---

**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. 원본 없이 맥스 파일 하나만 넘길 수 있나요?**

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)*