Ep.25 — Fast-Ref vs 경쟁제품 비교
마크다운 다운로드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 |
|---|---|---|
| 마스터 씬에서 키·컨트롤러 작업 | ✅ 트랙 단위 오버라이드 | ✅ 마스터 씬에서 키·애니 작업 가능. 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 으로 리그 샘플과 함께 문의해 주세요.
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