모션 매칭

편집 역사 토론
게임 개발 컴퓨터 그래픽스 마지막 수정: 2026-08-15 04:14:22

1. 개요[편집]

모션 매칭
Motion Matching
분류데이터 주도 캐릭터 애니메이션
대체 대상상태 기계 · 블렌드 트리
매 프레임 하는 일특징 벡터 질의 → 모션 DB 최근접 이웃 검색
전이 처리관성 블렌딩(inertialization)
대표 사례For Honor (Ubisoft, 2017)
청구서모션 데이터 용량 · 프레임당 검색 비용

어떤 클립을 재생할지 미리 정하지 말고, 매 프레임 데이터베이스 전체에 물어보면 된다.

모션 매칭(motion matching)은 재생할 애니메이션을 상태 기계로 미리 배선해 두는 대신, 매 프레임 「지금 캐릭터의 포즈」와 「플레이어가 원하는 미래 궤적」을 하나의 특징 벡터로 만들어 모션 데이터베이스 전체에서 그 벡터에 가장 가까운 프레임을 검색하고, 그 프레임으로 짧게 넘어가는 데이터 주도 캐릭터 애니메이션 기법이다. 클립이라는 단위 자체를 해체해 버리는 것이 핵심이라, 애니메이션 그래프를 짜는 노동이 통째로 사라진다.

애니메이션 블렌딩이 클립 몇 개를 잘 섞어 연속적인 동작 공간을 만들려는 시도였다면, 모션 매칭은 그 문제를 검색 문제로 바꿔 버린다. 걷기·뛰기·급정지·180도 턴을 각각 노드로 만들고 전이 조건을 손으로 다는 대신, 배우에게 “아무 방향으로나 계속 걷고 뛰고 돌아 보세요”라고 시켜 모션 캡처 데이터를 수십 분 찍은 뒤, 런타임에는 그 안에서 지금 필요한 프레임을 찾는다. 리깅 노동을 데이터 용량과 검색 비용으로 환전한 것이라는 요약이 가장 정확하다.

기법의 이름과 골격은 Ubisoft Montreal이 For Honor를 만들며 정리해 2015~2016년에 공개했다.1 조상은 더 오래됐는데, 캡처 데이터 프레임을 노드로 삼아 전이 가능한 그래프를 미리 만들어 두는 모션 그래프(motion graph, Kovar 외 2002)와, 포즈 공간에 벡터장을 깔아 다음 프레임을 뽑는 모션 필드(motion field, Lee 외 2010)가 그것이다. 모션 매칭은 전처리로 그래프를 굽는 대신 매 프레임 무식하게 다시 검색한다는 점에서 이들과 갈린다.

2. 특징 벡터[편집]

특징 벡터는 두 덩어리로 나뉜다. 지금 몸이 어떤 상태인가(과거·현재)와 어디로 가고 싶은가(미래).

  • 포즈 특징 — 양발의 위치와 속도, 그리고 골반(루트)의 속도. 전부 캐릭터 로컬 좌표계, 즉 루트의 위치·요(yaw)를 제거한 좌표에서 기술한다. 월드 좌표를 그대로 쓰면 “북쪽으로 걷는 프레임”과 “남쪽으로 걷는 프레임”이 다른 것으로 취급되어 DB가 방향 수만큼 낭비된다.
  • 궤적 특징 — 앞으로 t=0.33, 0.66, 1.0t = 0.33,\ 0.66,\ 1.0초 뒤의 루트 위치(수평 2성분)와 바라볼 방향(2성분). 60 fps 기준 20·40·60 프레임 앞이며, 이 세 지점이 관례로 굳었다.

합치면 대략 25~30차원짜리 실수 벡터가 된다. 중요한 것은 후보 쪽 궤적은 DB에서 그냥 읽어 온다는 점이다. 캡처 데이터의 프레임 kk에서 20·40·60 프레임 뒤의 루트 위치는 이미 파일에 적혀 있으니, “이 프레임을 재생하면 1초 뒤 캐릭터가 어디에 가 있을지”를 전처리 때 미리 뽑아 두면 된다. 반면 질의 쪽 궤적은 실제 미래가 아니라 플레이어 입력으로부터 예측한 희망 궤적이라, 보통 스틱 입력을 임계 감쇠 스프링에 통과시켜 만든다. 이 예측기가 캐릭터의 “성격”을 절반쯤 결정한다.

3. 비용 함수와 정규화[편집]

질의 벡터 q\mathbf{q}와 DB의 후보 프레임 특징 fk\mathbf{f}_k 사이의 비용은 가중 제곱거리다.

C(k)=jwjσj2qjfk,j2C(k) = \sum_{j} \frac{w_j}{\sigma_j^{2}} \left\lVert q_j - f_{k,j} \right\rVert^{2}

여기서 jj는 특징 그룹(발 위치, 발 속도, 궤적 위치, 궤적 방향 …)이고 σj\sigma_jDB 전체에서 그 특징의 표준편차다. 이 정규화가 빠지면 아무것도 되지 않는다. 발 위치는 미터, 발 속도는 m/s, 방향은 무차원인데 이들을 그냥 더하면 단위가 큰 성분이 비용을 독식한다. 실제로 모션 매칭 튜닝 실패담의 태반이 “속도 항 가중치를 0.1로 줬는데도 속도가 전부를 결정한다”류이고, 원인은 가중치가 아니라 정규화 누락이다.2

가중치 wjw_j가 남기는 자유도는 사실상 하나다 — 포즈 항 대 궤적 항의 비율.

  • 궤적 쪽을 키우면 스틱을 꺾은 방향으로 즉시 반응한다. 대신 현재 포즈와 동떨어진 프레임이 선택되기 쉬워 포즈가 툭툭 튀고 발이 미끄러진다.
  • 포즈 쪽을 키우면 이어붙임이 매끄럽다. 대신 캐릭터가 스틱을 무시하고 하던 동작을 마저 하려 들어 “굼뜨다”는 평가를 받는다.

이 다이얼은 없앨 수 없다. 응답성과 발 미끄러짐은 같은 축의 양 끝이고, 데이터가 부족할수록 축이 짧아진다. 급정지 데이터가 DB에 없으면 어떤 가중치를 줘도 급정지는 안 나온다 — 검색은 없는 것을 만들어내지 못한다.

4. 검색과 이어붙이기[편집]

매 프레임 DB 전체를 훑는다는 게 처음 들으면 미친 소리 같지만, 실제로는 생각보다 싸다. 10분짜리 데이터베이스는 30 fps 기준 1만 8천 프레임이고, 30차원 제곱거리 1만 8천 번은 SIMD로 짜면 수십 마이크로초 수준이다. 그래서 초기 구현들은 그냥 완전탐색을 돌렸다. 그럼에도 DB가 수 시간으로 커지면 가속 구조가 필요해진다.

  • KD 트리 — 가장 먼저 떠오르는 최근접 이웃 구조. 다만 30차원에서는 차원의 저주 때문에 가지치기가 거의 안 먹혀 완전탐색 대비 이득이 실망스러운 경우가 많다. 궤적 성분만 뽑아 저차원 트리를 만들고 후보를 1차로 거른 뒤 나머지는 완전탐색으로 재랭킹하는 2단 구성이 현실적이다.
  • 군집 기반 가지치기k-평균 군집화로 DB를 수백 개 군집으로 나누고 각 군집의 경계상자까지의 하한 거리로 군집을 통째로 버린다. 고차원에서 트리보다 잘 버틴다.
  • 후보 축소 — 애초에 무기·자세·기울기 태그로 검색 대상 구간을 좁힌다. 가장 싸고 가장 효과가 크다.

검색 결과를 그대로 쓰면 또 다른 문제가 생긴다. 매 프레임 최적을 고르면 비용이 비슷한 두 프레임 사이를 매 프레임 왕복하며 캐릭터가 파르르 떨린다. 그래서 실무에서는 두 장치를 건다. 검색 주기를 0.1초 정도로 낮추고(상태가 바뀌면 즉시 강제 검색), 현재 재생 중인 프레임의 다음 프레임에 음의 편향을 준다 — 새 후보가 현재 진행보다 유의미하게 좋을 때만 갈아탄다는 뜻이다.

그리고 실제로 프레임을 갈아탈 때의 이음매는 애니메이션 블렌딩 문서의 관성 블렌딩이 처리한다. 전환 순간의 포즈 차이와 그 시간 미분을 붙잡아 5차 다항식으로 0.1~0.2초에 걸쳐 감쇠시키는 방식이라, 이전 프레임을 계속 평가할 필요가 없다. 모션 매칭이 실용화된 시점과 관성 블렌딩이 표준으로 자리 잡은 시점이 겹치는 것은 우연이 아니다 — 초당 열 번씩 점프하는 구조에서 크로스페이드는 감당이 안 된다.

5. Learned Motion Matching — 압축[편집]

모션 매칭의 청구서는 결국 메모리다. 클립을 지우지 못하니 데이터가 곧 품질이고, 데이터가 늘면 용량과 검색 시간이 같이 는다. 콘솔 메모리에 수 시간짜리 캡처를 통째로 올려 두는 것은 캐릭터 한둘이면 몰라도 부대 단위로는 불가능하다.

Learned Motion Matching(Holden 외, SIGGRAPH 2020)은 이 파이프라인의 세 단계를 각각 작은 신경망으로 바꿔 DB 자체를 메모리에서 들어낸다.3

원래 단계대체 신경망하는 일
최근접 이웃 검색Projector질의 벡터를 DB에 실재하는 특징점으로 사영
클립 재생(다음 프레임)Stepper특징 + 잠재 벡터를 한 프레임 전진
프레임 → 전신 포즈Decompressor특징 + 잠재 벡터에서 전 관절 포즈 복원

포인트는 세 망 모두 원래 알고리즘의 출력을 그대로 흉내 내도록 지도학습된다는 것이다. 새로운 동작을 지어내는 생성 모델이 아니라, 모션 매칭이라는 결정론적 함수의 압축기다. 그래서 결과 품질이 원본 모션 매칭과 거의 구분되지 않으면서 메모리는 한 자릿수 이상 줄고, 비용이 DB 크기와 무관해진다. 학습 기반 애니메이션 중에서 드물게 “무엇을 보장하는지”가 명확한 축에 속한다.

6. 현업에서의 현실[편집]

  • 데이터 촬영 계획이 곧 게임 디자인이다. 상태 기계 시절에는 필요한 클립 목록을 기획서에서 뽑았지만, 모션 매칭에서는 “속도·방향·가속을 골고루 덮는 연속 연기”를 찍어야 한다. 8자 주행, 나선형 감기, 무작위 스틱 조작 재현 같은 촬영 대본이 따로 존재한다.
  • DB에 없는 구멍은 조용히 이상한 포즈로 메워진다. 상태 기계는 전이가 없으면 대놓고 안 넘어가지만, 검색은 항상 “그나마 가장 가까운” 무언가를 돌려준다. 디버깅이 어려운 이유가 이것이고, 그래서 선택된 프레임의 출처 클립·비용 내역을 화면에 띄우는 디버그 뷰가 필수다.
  • 루트 모션과의 관계가 뒤집힌다. 애니메이션이 궤적을 만들고 게임 로직이 그걸 따라가는 것이 아니라, 게임 로직이 원하는 궤적을 던지고 애니메이션이 최대한 근접한 것을 찾아 준다. 두 궤적의 잔차가 곧 발 미끄러짐 예산이며, 남은 오차는 여전히 역운동학 풋 IK가 마무리한다.
  • 상태 기계를 걷어냈다고 로직이 사라지지는 않는다. 무기 교체·피격·상호작용 같은 이산 사건은 여전히 유한 상태 기계행동 트리가 관리하고, 모션 매칭은 그중 “이동”이라는 가장 지저분한 한 칸을 통째로 가져간 것에 가깝다.

7. 여담[편집]

  • 애니메이터 입장에서 이 기법은 해방이자 상실이다. 그래프를 짜고 전이를 다는 노동은 사라지지만, 공들여 만든 전이를 알고리즘이 마음대로 무시하기도 한다. “예술적 통제권”이 없어지는 것은 아니고 데이터 촬영 단계로 앞당겨진다고 보는 편이 맞다.
  • 특징 벡터를 주성분 분석으로 줄여 검색을 빠르게 하려는 시도는 자주 나오는데, 대개 실망스럽다. 궤적 성분과 포즈 성분은 애초에 의미가 다른 축이라 분산 기준으로 섞어 버리면 튜닝 다이얼이 사라진다.
  • 이름이 “매칭”이라 패턴 인식처럼 들리지만 하는 일은 그냥 벡터 양자화에 가까운 최근접 검색이다. 화려한 이름값의 절반은 “매 프레임 전부 다시 검색해도 된다”는 배짱에서 나온다.

8. 관련 문서[편집]

9. Footnotes[편집]

  1. Büttner, M. & Clavet, S. “Motion Matching — The Road to Next Gen Animation” (nucl.ai 2015), Clavet, S. “Motion Matching and The Road to Next Gen Animation” (GDC 2016). GDC 발표는 For Honor의 검 격투 이동을 대표 예제로 들었다. 검투 게임이 첫 사례가 된 것은 우연이 아닌데, 상대와 거리를 유지하며 옆걸음·뒷걸음으로 계속 미세 조정하는 동작은 8방향 블렌드 스페이스로는 도저히 안 나오는 종류의 움직임이기 때문이다.

  2. 표준편차 정규화는 “모든 특징을 무차원화해서 같은 출발선에 세운다”는 뜻이고, 그 위에 얹는 wjw_j가 비로소 예술적 선택이 된다. 순서를 바꿔서 가중치부터 만지면 단위 변환 계수를 손으로 재발명하게 된다. 물리 시뮬레이션에서 무차원화를 먼저 하는 이유와 똑같다.

  3. Holden, D., Kanoun, O., Perepichka, M., Popa, T. (2020). “Learned Motion Matching”. ACM TOG 39(4). Ubisoft La Forge 결과물. 셋 중 가장 얄미운 것은 Projector인데, 하는 일이 “최근접 이웃 검색 결과를 예측하는 신경망”이다. 검색을 안 하려고 검색 결과를 학습시킨다는 발상이 처음엔 순환논법처럼 들리지만, 학습은 오프라인에 한 번이고 추론은 매 프레임이라는 비대칭이 전부를 정당화한다.