Game Animation Technologies: Technical Comparison

 

이 리서치 문서는 중국 테크 블로그 및 해외 테크 블로그 자료를 토대로 초안을 정리 하고 AI 를 사용하여 최종문서화 되었습니다.

Motion Matching · MotionBricks · UE5 Pose Search

본 문서는 현대 게임 애니메이션 파이프라인을 주도하는 세 가지 핵심 기술 — Motion Matching(원본 알고리즘), MotionBricks(NVIDIA의 생성형 모델), UE5 Pose Search(Epic Games의 엔진 내장 구현) — 을 심층 비교 분석합니다. 각 기술의 아키텍처, 작동 원리, 장단점, 그리고 프로덕션 적용 관점을 다룹니다.

---

Table of Contents

1. Executive Summary
2. Motion Matching: 원본 알고리즘
3. UE5 Pose Search: 엔진 내장 구현
4. MotionBricks: 생성형 접근법
5. Core Loop Architecture 비교
6. Cost Function & Search Methodology 비교
7. Performance & Scalability 비교
8. Memory & Data Management 비교
9. 제어 가능성(Control) 비교
10. Production Integration 비교
11. 종합 비교 테이블
12. 결론 및 전망
13. References

---

1. Executive Summary

세 기술은 근본적으로 다른 패러다임으로 게임 캐릭터 애니메이션을 해결합니다:

구분	Motion Matching	UE5 Pose Search	MotionBricks
패러다임	데이터베이스 검색 (Query-based)	데이터베이스 검색 (Engine-integrated)	생성형 모델 (Generative)
출처	Ubisoft LaForge (GDC 2016)	Epic Games (UE 5.4+)	NVIDIA (SIGGRAPH 2026)
코어 아이디어	매 프레임 DB에서 최저 비용 포즈 검색	Schema 기반 Feature Vector 검색 + Chooser	VQ-VAE 토큰화 + 생성형 백본
대표 타이틀	For Honor, Far Cry 6, 흑신화: 오공	UE5 프로젝트 전반	UE5 데모, Unitree G1 로봇
데이터 처리	원본 모캡 데이터를 그대로 유지	Schema 채널별 Feature Vector 인덱싱	35만+ 클립을 단일 모델로 학습
GPU 의존도	낮음 (CPU 검색)	낮음–중간	높음 (RTX 5090 기준 2ms)

핵심 차이점: Motion Matching과 UE5 Pose Search는 "저장된 애니메이션 중 최적의 프레임을 찾는" 검색 기반 접근이며, MotionBricks는 "새로운 모션을 생성하는" 생성형 AI 접근입니다.

---

2. Motion Matching: 원본 알고리즘

2.1 역사적 배경

Motion Matching은 2002년 SIGGRAPH의 Motion Graph 기술과 2012년의 motionFields 연구를 기반으로, Ubisoft LaForge가 2016년 GDC에서 발표한 실시간 애니메이션 기법입니다 citation:Motion Matching GDC 2016. For Honor에 처음 상업 적용되었으며, 이후 Far Cry 6, 흑신화: 오공 등에 도입되었습니다 citation:Motion Matching Guide. (생각해 보니 저 발표 세션때 저도 가서 들었네요)

2.2 Core Loop

Motion Matching의 런타임 루프는 4단계로 구성됩니다:

Motion Matching Core Loop — EVALUATE → PREDICT → SEARCH → BLEND 순환 루프 (30–60 Hz)

2.3 Cost Function (매칭 비용 함수)

Motion Matching의 핵심은 Feature Selection과 Cost Function에 있습니다. Ubisoft의 구현에서 사용하는 Feature 세트는 다음과 같습니다 citation:Learned Motion Matching - Ubisoft:

Feature	설명	역할
Foot positions (left, right)	발의 3D 위치	풋슬라이딩 방지
Foot velocities	발의 속도 벡터	접지 타이밍 정확도
Hip velocity	골반 속도	이동 방향/속도 매칭
Future trajectory positions	미래 궤적 위치 (여러 시간 스냅샷)	경로 추종 정확도
Future trajectory directions	미래 궤적 방향	회전/방향 전환 매칭

Cost Function은 이 Feature 벡터들의 L2 거리(유클리디안 거리) 를 가중합하여 계산합니다:

Cost(query, candidate) = Σᵢ wᵢ · ‖fᵢ(query) - fᵢ(candidate)‖²

where:
  fᵢ = i번째 Feature 추출 함수
  wᵢ = i번째 Feature의 가중치

이 Cost는 단순한 그리디 서치(greedy search) 로 최소값을 찾습니다. 매 프레임 전체 DB를 순회하며 최저 Cost 프레임을 선택합니다.

2.4 장단점

장점:

• 상태 머신 불필요 — 애니메이션 데이터 추가만으로 품질 향상
• 자연스러운 반응성 — 입력 변화에 즉각 대응
• 구현이 직관적이고 디버깅 용이

단점:

• 메모리 병목: 대규모 모캡 데이터 전부를 메모리에 유지해야 함
• 검색 비용: DB 크기에 비례하는 선형 검색 시간
• Feature 설계: 수동 Feature 선택 및 가중치 튜닝 필요
• 확장성: 스타일/상황이 많아질수록 DB가 기하급수적으로 커짐

2.5 Learned Motion Matching

Ubisoft LaForge는 2020년 Learned Motion Matching(LMM) 을 발표하여 메모리 문제를 해결 citation:Learned Motion Matching. 핵심 아이디어:

• Step Database를 신경망으로 대체하여 메모리 사용량 대폭 감소
• 4-step 파이프라인: Stepper → Projection → Decomposer → Synthesis
• 원본 Motion Matching과 동등한 품질을 유지하면서 메모리를 수십 배 절감
• ML을 통한 "압축"으로, 여전히 검색 기반 패러다임

---

3. UE5 Pose Search: 엔진 내장 구현

3.1 시스템 아키텍처 — Three Pillars

UE5의 Pose Search는 Schema → Database → Chooser 3개의 핵심 에셋으로 구성됩니다:

3.2 Pose Search Schema (UPoseSearchSchema)

Schema는 검색 인덱스의 포맷 계약을 정의합니다 — 어떤 데이터를 쿼리할지, 어떻게 구조화할지를 결정합니다.

속성	타입	설명
SampleRate	int32	DB 내 애니메이션 데이터 샘플링 주기 (1–240)
DataPreprocessor	enum	Feature Vector 정규화 전략
NumberOfPermutations	int32	DB의 다중 인덱싱 패스 수
bAddDataPadding	bool	16바이트 정렬 (SIMD 최적화)

기본 Locomotion Schema 채널 구성:

1. Trajectory Channel — Motion Trajectory Component에서 궤적 점 샘플링
2. Pose Search Channel — 현재 골격 포즈 vs DB 포즈 비교

3.3 Feature Channel Types

UE5 Pose Search의 핵심 강점은 다양한 Feature Channel 타입입니다:

Channel	용도	비고
Position	본 위치 비교	주로 발(foot_l, foot_r)에 사용
Velocity	본 속도 비교	미래 속도 매칭 가능 (SampleTimeOffset)
Heading	본 방향 비교
Distance	본 간 거리
Curve	애니메이션 커브 값	IK 타겟, 블렌딩 웨이트
Phase	위상 정보	순환 애니메이션(걷기 등)
TimeToEvent	이벤트까지의 시간	풋 플랜트, 임팩트
FilterCrashingLegs	다리 교차 페널티

각 채널은 Weight 속성으로 Cost Function 내 비중을 조절합니다.

3.4 Pose Search Database (UPoseSearchDatabase)

Database는 Animation Sequence를 Schema에 정의된 채널에 따라 Feature Vector 공간으로 인덱싱합니다.
인덱싱 프로세스:

1. 각 Animation Sequence를 Schema의 SampleRate로 샘플링
2. 각 샘플 포인트에서 Schema 채널별 Feature Vector 추출
3. 선택적 정규화 (Schema의 DataPreprocessor)
4. 인덱싱된 데이터를 검색 가능한 구조로 저장

Anim Notify 시스템:

Notify	목적
PoseSearchBranchIn	모션 매칭이 진입할 수 있는 지점 표시
PoseSearchBlockTransition	해당 구간의 검색 결과 오버랩 방지
PoseSearchExcludeFromDatabase	DB에서 완전 제외
PoseSearchModifyCost	특정 구간의 선택 Cost 조정
PoseSearchOverrideContinuingPoseCostBias	현재 포즈 유지 비용 바이어스 오버라이드

3.5 Chooser 시스템

Chooser는 런타임에 동적으로 어떤 Database를 사용할지 결정하는 데이터 주도 선택 시스템입니다:

• Gameplay Tag, 변수 등을 기반으로 조건 평가
• 무기 유무, 이동 모드(걷기/수영/엎드리기)에 따라 다른 DB 선택
• Animation Blueprint 수정 없이 새 이동 모드 추가 가능

3.6 런타임 Core Loop

UE5 Pose Search의 프레임별 실행 흐름:

UE5 Pose Search — 프레임별 실행 파이프라인 (6단계)

---

4. MotionBricks: 생성형 접근법

4.1 개요

MotionBricks는 NVIDIA가 SIGGRAPH 2026에 발표한 모듈형 잠재 생성 모델(Modular Latent Generative Model) 기반 실시간 모션 합성 프레임워크입니다 citation:MotionBricks arXiv. 기존 검색 기반 방식과 근본적으로 다른 "생성" 패러다임을 채택합니다.

4.2 시스템 아키텍처

4.3 State Representation (Dual-Root System)

MotionBricks의 독특한 설계는 Global/Local 이중 루트 표현입니다:

표현	구성	차원	사용 모듈
Global Subset	Global Root(5) + Body(409)	414 dims	Root Module
Local Subset	Local Root(4) + Body(409)	413 dims	Pose Module / Tokenizer
Full Dual	Global Root(5) + Local Root(4) + Body(409)	418 dims	최종 출력

Body Features (409 dims):

Feature	Dims	설명
ric_data	99	글로벌 관절 위치 (33 비루트 관절 × 3)
global_rot_data	204	글로벌 6D 연속 회전 (34 관절 × 6)
local_vel	102	관절별 속도 (34 관절 × 3)
foot_contacts	4	이진 접지 상태 (4개 발 관절)

4.4 Structured Multi-headed Tokenizer

VQ-VAE 기반 토크나이저가 모션을 4× 시간 압축된 이산 토큰으로 변환합니다:

• 아키텍처: U-Net 스타일 (인코더-디코더)
• 다운샘플링: 2개 레이어로 4× 시간 압축
• 레이어 구조: 3개 Residual 1D Conv (1024 채널)
• 총 파라미터: 23.5M
• 재구성 오차: ~2 × 10⁻⁶ (거의 완벽한 재구성)
• Multi-head 설계: Body/Root 특징을 분리된 토큰 스트림으로 인코딩

4.5 Neural Backbone (Root + Pose Module)

Root Module (2-step):

1. 히든 스테이트 초기화 + 타이밍 예측
2. 제어 신호 기반 루트 궤적 추정 (월드 스페이스 위치 + 헤딩)

Pose Module:

• Root Module의 출력에 조건화되어 이산 포즈 토큰 분포 예측
• Root 먼저 → Body 나중 순서로 모듈 분리하는 것이 실시간 성능 핵심

4.6 Smart Primitives

MotionBricks의 실용적 인터페이스 계층:

프리미티브	기능	특징
Smart Locomotion	속도/방향/스타일 기반 이동	스타일 믹싱, 재훈련 불필요
Smart Objects	오브젝트-씬 인터랙션	줍기, 장애물 점프, 착석
Smart In-betweening	키프레임 간 자동 채움	가변 수 제약, 프로덕션 품질

핵심: 모든 태스크에 Zero-Shot Generalization — 추가 파인튜닝, 태스크별 태깅 불필요.

4.7 성능 지표

지표	값
Throughput	15,000 FPS
Latency	2 ms
커버 모션 스킬	350,000+ clips
추론 하드웨어	RTX 5090
토크나이저 파라미터	23.5M

---

5. Core Loop Architecture 비교

핵심 차이점

관점	Motion Matching  / UE5 Pose Search	MotionBricks
런타임 연산	DB 검색 (검색 공간 ∝ DB 크기)	신경망 순전파 (고정 비용)
출력	기존 모캡 프레임 선택	새로운 모션 생성
블렌딩	선택 프레임으로 블렌딩 (필요시)	디코더가 연속 모션 직접 생성
결정론	동일 입력 → 동일 결과 (그리디)	확률적 생성 (다양성)
지연 구조	DB 크기에 종속	2ms 고정 (RTX 5090)

---

6. Cost Function & Search Methodology 비교

6.1 Motion Matching (원본)

Cost = Σᵢ wᵢ · ‖fᵢ(query) - fᵢ(candidate)‖²

Features: {foot_pos, foot_vel, hip_vel, trajectory_pos, trajectory_dir}
Search: Linear scan (전체 DB 순회)
Selection: Argmin(Cost)

• Feature는 수동 설계 (Hand-picked)
• 가중치 wᵢ는 경험적 튜닝
• 검색은 완전 탐색 (Brute-force)

6.2 UE5 Pose Search

Cost = Σ_channels wₖ · ‖channelₖ(query) - channelₖ(candidate)‖²

Channels: {Position, Velocity, Heading, Distance, Curve, Phase, TimeToEvent, ...}
+ Continuing Pose Cost Bias
+ PoseSearchModifyCost notifies
Search: Feature Vector 인덱스 순회
Preprocessing: Schema.DataPreprocessor (정규화)

• Schema 기반 채널 시스템 — 모듈화된 Feature 설계
• Anim Notify로 Cost를 데이터 주도 방식으로 수정 가능
• Continuing Pose Bias로 불필요한 전환 억제
• Permutation 시스템으로 다중 인덱싱 패스 지원

6.3 MotionBricks

생성형 모델 — 명시적 Cost Function 없음

대신:
  Token Loss = CrossEntropy(predicted_tokens, target_tokens)
  Trajectory Loss = MSE(predicted_root, target_root)
  
런타임: 모델 순전파만으로 모션 생성
검색 과정 자체가 존재하지 않음

• 검색 불필요 — 생성형 모델이 직접 출력
• 학습 시 Loss가 Cost 역할 (Cross-Entropy + Trajectory MSE)
• 런타임에는 고정 비용의 순전파만 수행

비교 요약

항목	Motion Matching	UE5 Pose Search	MotionBricks
Feature 설계	수동 (5종)	Schema 채널 (10+종)	학습 기반 (자동)
Cost 계산	L2 가중합	채널별 L2 + Bias	없음 (생성형)
검색 방식	Brute-force	인덱스 순회	없음 (순전파)
Cost 튜닝	가중치 수동	Notify + 채널 Weight	학습 시 결정

---

7. Performance & Scalability 비교

7.1 검색 비용 vs 생성 비용

7.2 확장성 분석

관점	Motion Matching	UE5 Pose Search	MotionBricks
DB/데이터 증가 시	검색 시간 선형 증가	검색 시간 선형 증가	영향 없음 (고정 모델)
새 모션 추가	DB에 추가 후 리인덱스	DB에 추가 후 리인덱스	재학습 필요 (또는 제로샷)
새 스켈레톤	DB 전체 리빌드	DB 전체 리빌드	리타겟 + 재학습
스케일링 한계	수천~수만 클립	수천~수만 클립	35만+ 클립 단일 모델
GPU 요구사항	불필요 (CPU)	선택적 (SIMD)	필수 (RTX급 GPU)

7.3 Learned Motion Matching의 중간 지점

Ubisoft의 LMM은 검색 기반 방식의 메모리/검색 병목을 신경망으로 완화:

• DB를 신경망으로 "압축"하여 메모리 절감
• 여전히 검색 기반 패러다임 (생성형 아님)
• MotionBricks보다 GPU 요구사항 낮음
• Motion Matching보다 메모리 효율 높음

---

8. Memory & Data Management 비교

8.1 데이터 파이프라인

단계	Motion Matching	UE5 Pose Search	MotionBricks
입력	Raw 모캡 클립	Animation Sequence + Notify	35만+ 모션 클립
전처리	Feature Vector 추출	Schema 채널 인덱싱	VQ-VAE 토큰화
저장	전체 모캡 + Feature	인덱싱된 Feature Vector	학습된 모델 가중치
런타임	DB 전체 로드	선택적 DB 로드 (Chooser)	모델 가중치만 로드

8.2 메모리 사용량

기술	메모리 패턴	규모 추정
Motion Matching	∝ (클립 수 × 프레임 수 × Feature 차원)	수백 MB ~ 수 GB
UE5 Pose Search	∝ (클립 수 × Feature 차원) + 패딩	DB당 수십~수백 MB
MotionBricks	고정 (23.5M params + Backbone)	수백 MB (모델 가중치)

UE5 Pose Search는 Chooser 시스템으로 메모리를 최적화 — 필요한 DB만 메모리에 올리고 상황에 따라 교체.

8.3 데이터 준비 워크플로우

데이터 준비 워크플로우 — 검색 기반 vs 생성형 파이프라인 비교

검색 기반: 각 프로젝트마다 DB를 맞춤 구축해야 함
생성형: 한 번 학습하면 다양한 태스크에 Zero-Shot 적용

---

9. 제어 가능성(Control) 비교

9.1 제어 인터페이스

제어 유형	Motion Matching	UE5 Pose Search	MotionBricks
속도/방향	궤적 Feature	Trajectory Channel	Velocity Command
스타일	별도 DB 분리	Chooser로 DB 전환	Style 파라미터
키프레임	미지원 (기본)	미지원 (기본)	Smart In-betweening
오브젝트 인터랙션	별도 시스템 필요	별도 시스템 필요	Smart Objects
커스텀 채널	Feature 수정	Schema Channel 추가	학습 데이터 수정
Cost 바이어스	가중치 튜닝	Notify 시스템	모델 학습에 의해 결정

9.2 제어 세밀도

UE5 Pose Search가 가장 세밀한 제어를 제공:

• Anim Notify로 프레임 단위 Cost 제어
• Schema 채널로 Feature 레벨 커스터마이징
• Chooser로 게임 로직과 애니메이션 결합
• Continuing Pose Bias로 전환 빈도 조절

MotionBricks는 고수준 제어에 강점:

• Velocity/Style만으로 복잡한 모션 생성
• Zero-Shot으로 새 태스크에 즉시 적용
• Smart Primitives로 오브젝트 인터랙션 자동 처리
• 단, 로우레벨 Cost 제어는 불가능

---

10. Production Integration 비교

10.1 에디터 통합

항목	Motion Matching	UE5 Pose Search	MotionBricks
에디터 UI	커스텀 구현	네이티브 UE5 에디터	UE5 플러그인 (NVIDIA)
디버그 툴	커스텀	빌트인 시각화	프로젝트 페이지 데모
Anim Blueprint	커스텀 노드	Motion Matching 노드	전용 노드 (예상)
Control Rig 연동	수동	네이티브 지원	예상 지원

10.2 학습 곡선

학습 곡선 — 기술별 진입 장벽 비교 (낮을수록 좋음)

10.3 대표 타이틀/데모

기술	적용 사례
Motion Matching	For Honor, Far Cry 6, 흑신화: 오공
UE5 Pose Search	UE5 Game Animation Sample, Lyra Starter Game
MotionBricks	UE5 프로덕션 데모 (2:40 무편집), Unitree G1 로봇

---

11. 종합 비교 테이블

기준	Motion Matching	UE5 Pose Search	MotionBricks
패러다임	DB 검색	DB 검색 (엔진 통합)	생성형 AI
출처	Ubisoft (2016)	Epic Games (5.4+)	NVIDIA (SIGGRAPH 2026)
런타임 연산	선형 검색	인덱스 검색	신경망 순전파
지연 시간	DB 크기 비례	DB 크기 비례	2ms 고정
GPU 요구	불필요	선택적	필수
Feature 설계	수동 (5종)	Schema 채널 (10+종)	자동 (학습)
메모리	∝ DB 크기	∝ DB 크기 (선택적 로드)	고정 (모델 크기)
확장성	수천 클립 한계	수천 클립 한계	35만+ 클립
제어 세밀도	중간	높음	중간 (고수준)
새 모션 추가	DB 추가	DB 추가 + 리인덱스	재학습
학습 곡선	중간	낮음	높음
에디터 통합	커스텀	네이티브 UE5	플러그인
키프레임 인비트위닝	미지원	미지원	Smart In-betweening
오브젝트 인터랙션	미지원	미지원	Smart Objects
로봇 공학 적용	어려움	어려움	Zero-Shot 전이
오픈소스	N/A	UE5 소스 공개	GitHub 공개

---

12. 결론 및 전망

12.1 기술 선택 가이드

상황	추천 기술
UE5 프로젝트, 빠른 프로토타이핑	UE5 Pose Search — 에디터 내장, 샘플 프로젝트 활용
대규모 오픈월드, 다양한 이동 모드	UE5 Pose Search • Chooser — DB 분리로 확장
로봇 공학, 실시간 전신 제어	MotionBricks — Zero-Shot 전이, 2ms 지연
고품질 인비트위닝 필요	MotionBricks — Smart In-betweening
GPU 리소스 제약적 모바일/인디	Motion Matching (순수 CPU 구현)
최소한의 아티스트 워크플로우	MotionBricks — DB 구축/튜닝 불필요

12.2 기술 수렴 전망

검색 기반 → 생성형으로의 수렴이 뚜렷합니다:

1. Motion Matching (2016): 순수 검색, CPU 기반
2. Learned Motion Matching (2020): 신경망으로 DB 압축
3. UE5 Pose Search (2024): 엔진 통합, 모듈화된 Schema/Channel
4. MotionBricks (2026): 완전 생성형, 대규모 모델

향후 UE5 Pose Search에 생성형 요소가 통합될 가능성이 높으며, NVIDIA와 Epic의 협력으로 MotionBricks가 UE5에 네이티브 통합되는 시나리오도 예상됩니다.

12.3 핵심 시사점

1. 검색 기반 방식의 한계: DB 크기에 비례하는 검색 비용은 본질적 병목. Learned Motion Matching으로 메모리는 절감했지만 검색 시간 문제는 여전히 존재.
2. 생성형의 약속과 과제: MotionBricks는 확장성과 제어 유연성 면에서 패러다임 전환을 보여주지만, GPU 의존도와 학습 데이터 요구사항이 현실적 장벽.
3. UE5 Pose Search의 실용성: 현재 프로덕션 환경에서 가장 즉시 활용 가능한 솔루션. Schema/Channel 시스템은 확장 가능하고, Chooser는 실용적인 DB 관리를 가능하게 함.
4. 하이브리드의 가능성: UE5 Pose Search의 세밀한 제어(Control Rig 연동, Notify 시스템)와 MotionBricks의 생성 능력을 결합하는 하이브리드 접근이 미래의 유력한 방향.

---

13. References

Primary Sources

• MotionBricks arXiv Paper — Tingwu Wang et al., SIGGRAPH 2026
• MotionBricks Project Page — NVIDIA Research
• MotionBricks GitHub — NVlabs
• Motion Matching in Unreal Engine — Epic Games Official Documentation
• Introducing Learned Motion Matching — Ubisoft LaForge
• Motion Matching and The Road to Next-Gen Animation — GDC 2016 Talk

UE5 API Reference

• UPoseSearchSchema — UE API Reference
• UPoseSearchDatabase — UE API Reference
• UPoseSearchFeatureChannel — UE API Reference
• PoseSearch API — UE API Reference

Supplementary

• Motion Matching: The Future of Game Animation — MCO Blog
• Motion Matching - part I — xiaoniao blog
• Motion Matching and Control Rig in UE5 — StraySpark Studio
• Devlog 58: Motion Matching — unreal-mmo-dev
• Hugging Face Paper Page — MotionBricks