모션 매칭

 

Reference

https://dev.epicgames.com/community/learning/tutorials/lwlG/unreal-engine-your-first-60-minutes-with-motion-matching

 

http://journal.cg-korea.org/archive/view_article?pid=jkcgs-29-3-159

 

https://www.gdcvault.com/play/1023280/Motion-Matching-and-The-Road

 

https://youtu.be/KSTn3ePDt50?si=oEy0Wp8rFkRyHlex

 

모션 매칭 등장 배경

유비 소프트에서 For Honor 라는 게임을 개발하고 있었음. 이 게임은 멀티 플레이 게임인데 상단, 좌단, 우단의 세 방향으로 공격과 가드를 하고 가드브레이크(잡기)와 회피, 쳐내기(패링), 캔슬 등 다양한 액션이 있는 게임임.

이 게임의 다양한 캐릭터의 움직임을 실제 인간처럼 자연스럽게 구현하려니 애니메이션을 관리하는 state machine이 매우 복잡해지고, 관리하기 어려워짐 (아래는 예시 이미지)

인간의 복잡한 움직임을 구현할 수 있으면서, 애니메이션들을 간단하게 관리할 수 있는 방법이 필요해짐.

 

그러다 모션필드라는 개념을 발견함. 모션 필드는 캐릭터 애니메이션을 위한 새로운 모션 표현 방식으로, 각 프레임에 캐릭터의 현재 모션과 연결할 수 있는 모든 모션들 중 한 모션을 선택하여 단일 프레임 동안 현재 모션에서 선택된 모션으로 움직임. 애니메이션의 프레임들을 점처럼 찍어 이어서 캐릭터의 상태가 흐르는 이 방식은 사용자가 실시간으로 캐릭터를 제어할 수 있으며 캐릭터가 완전히 연속적으로 작동할 수 있게 함. 따라서 상태 머신과 비교했을 때 사용자 명령에 짧은 시간내에 반응할 수 있게 되며, 모션 간의 전환을 하나하나 정의하고 관리할 필요가 없어진다는 장점이 있음.

게 멋진 모션 필드는 왜 지금까지 게임에서 사용되지 않았을까? 방정식 무서엉….복잡행… 스테이트 머신도 잘 동작하는데 이 복잡한 수학 공식이 가득한 방식을 사용할 필요가 없었던 것.

암튼 유비 소프트에서는 이 모션 필드에서 “어떤 프레임이든 우리가 원한다면 해당 프레임으로 건너뛰기 할 수 있다.” 라는 아이디어를 가지고 와서 자기네 게임에 적용하기로 함.

그렇게 모션 필드 개념을 가져와 연구하던 중 한가지 문제에 부딛힘. 상태가 갑자기 변화할 때 어떤 것을 기준으로 최적의 프레임을 선택할 것인가? 예를 들어, 캐릭터가 달리다가 갑자기 멈출 때 어느 시점에 Stop Animation을 시작할 건지?

캐릭터 포즈를 기준으로(pose matching)? 혹은 캐릭터의 속도를 기준으로(velocity matching)?

아니면 정밀하게 멈출 지점을 계산하여서 해당 지점에 맞춰서 멈춰야 하나? (precise end position matching) 3가지 방법을 모두 섞는다면? 3가지 방식에 가중치를 두어서 적절한 시점을 계산하는 방식으로 말이지.

 

모션 매칭 ?

그렇게 개발하게 된 개념이 “모션 매칭”. 직접 자기들 말로 구현하기 쉽고, 간단하고, 멋진 방식이라고 소개함.

모션 매칭은 한 문장으로 A ridiculously brute-force approach to animation selection. 여기서 brute-force는 우리가 아는 그 완전 탐색 알고리즘이 맞음. 모션 매칭이 일정 프레임 간격으로 (움직임 정보가 모두 담긴 15~20분 분량의) mocap 애니메이션의 프레임들을 살펴보고 “다음 모션(jumping point)”을 찾아내 해당하는 애니메이션 프레임으로 점프하는 알고리즘이라서 ‘애니메이션 선택을 위한 터무니없는 완전 탐색법’ 이라고 표현하는 거임.

During the online motion generation phase, we draw the best-matching pose from the database based on the current pose and projected future trajectory. This operation is carried out at every 20-frame interval.

“다음 모션(Jumping Point)”을 선정하기 위해 애니메이션 프레임들의 ‘비용(cost)’ 계산 함.
비용은 다음 2개의 조건을 바탕으로 계산 됨.

1. 현재 포즈와 얼마나 매치 되는지 (Pose/Velocity Matching)
2. 우리가 원하는 방향으로 가는 모션인지 (Trajectory Matching)

두 가지 조건을 모두 완벽히 충족한다면 비용은 0.

현재 포즈와 속도 그리고 캐릭터가 이동할 궤도가 이 비용을 판단하는데 필요함.

비용이 가장 적은 포즈가 현재 포즈에서 이어질 포즈로 선택됨.

현재 포즈와 후보 포즈가 매치될 수 있는지 비교(Pose/Velocity Matching)하기 위해서는 당연히 두 포즈를 비교하는데,

이때 몇 개의 본(bone)만을 비교하여 두 포즈가 매치될 수 있는지 비교함.

예를 들어서

1. Local velocity
2. Feet positions (Character Local)
3. Feet velocites (Character Local)
4. 기타 등등 사용자가 원하는 조건 (머리 방향이라던가… 무기 위치라던가…)

등을 고려해서 후보 포즈의 cost 를 계산. 그리고 이런 비교에 필요한 정보들은 미리 계산해서 애니메이션이랑 함께 저장하여 런타임 비교시에 빠르게 계산할 수 있도록 함. 그리고 양발을 비교하는 이유는 캐릭터가 이족 보행일 경우 두 발을 교차해서 이동하기 때문에 움직임이 가장 많기도 하고 다른 bone으로 비교하면 캐릭터가 한 쪽 발로만 걷거나 하는 문제가 생기기도 하기 때문이라고 한다.

캐릭터를 원하는 방향(궤도)대로 가게하려면 애니메이션의 어떤 프레임을 재생했을 때, 애니메이션의 진행궤도가 원하는 궤도와 최대한 유사해야함. 이때 아래 정보를 바탕으로 원하는 방향과 얼마나 유사한지 비교한다.

1. Future position
2. Future orientation
3. Future velocity/acceleration

int m_CurrentAnimIndex;
float m_CurrentAnimTime;

class TrajectoryPoint
{
	Vector3 m_Position; // 가고자 하는 월드 위치
	float m_Sight;      // 가고자 하는 월드 방향
	float m_TimeDelay;  // m_Position 까지 가는데 걸리는 시간
};

class Goal
{
 Array<TrajectoryPoint> m_DesiredTrajectroy;
 // ... 기타 원하는 것
};

// Goal - goal of this frame , dt - delta time
void AmoUpdate(Goal goal, float dt) 
{
	m_CurrentAnimTime += dt;
	Pose currentPose = EvaluateLerpedPoseFromData(m_CurrentAnimIndex, m_CurrentAnimTime);
	
	float bestCost = MAX_NUMBER; 
	Pose bestPose;
	
	// loop all mocap
	for(int i = 0; i < m_Poses.Size(); i++)
	{
		Pose candidatePose = m_Poses[i];
		
		// every candidate jumping point has a cost
		float thisCost = ComputeCost(currentPos, candidatePos, goal)
		if(thisCost < bestCost)
		{
			// remember the best candidate
			bestCost = thisCost;
			bestPose = candidatePos;
		}
	}
	
	bool theWinnerIsAtTheSameLocation = 
		m_CurrentAnimIndex == bestPose.m_AnimIndex && 
		fabs(m_CurrentAnimTime - bestPose.m_AnimTime) < 0.2f;
		
	if(!theWinnerIsAtTheSameLocation)
	{
		// blend to the winning location
		m_CurrentAnimIndex = bestPose.m_AnimIndex;
		m_CurrentAnimTime = bestPose.m_AnimTime;
		PlayAnimStartingAtTime(m_CurrentAnimIndex, m_CurrentAnimTime, 0.25f);
	}
}

float ComputeCost(Pose currentPose, Pose candidatePose, Goal goal)
{
	float cost = 0.0f; 
	
	// how much the candidate jumping position matches the current situation
	cost += ComputeCurrentCost(currentPose, candidatePose);
	
	static float resonsivity = 1.0f;
	
	// how much the candidiate piece of motion matched the desired trajectory
	coost += resonsivity * ComputeFutureCost(candidatePose, goal);
	
	return cost;
}

언리얼에서의 모션 매칭

언리얼에서 5.4 부터 모션 매칭을 정식으로 지원하기 시작했음. 언리얼에서는 모션 매칭을 모션 그래프에서 노드간의 트랜지션을 자동화한 기능이라고 표현한다.

모션 매칭 노드는 포즈 히스토리 노드로부터 수집된 기존의 정보와 Characetr Move Component의 모션 모델 예측을 사용해서 지정된 데이터베이스에서 다음 애니메이션을 검색함. 검색 결과에 따라 현재 포즈와 연속되지 않는 애니메이션의 포즈가 선택된 경우, 모션 매칭 노드는 현재 애니메이션 포즈와 새로 선택된 포즈를 블랜딩.

PoseSearchSchema

: Motion Matching에서 필요한 포즈간의 메트릭을 정의하고 매칭하려는 항복을 지정하는 에셋이다.

예를 들어서, 캐릭터의 발 위치와 예상 궤적 그리고 각 매칭 항복의 가중치인 weight를 설정할 수 있다.

(Sample Rate(데이터 베이스의 에니메이션 데이터 샘플링 업데이트 빈도)를 설정하거나 Pose Matching 과 Trajectory Matching의 가중치를 설정하거나, Pose Match의 Sample Bone을 설정할 수 있다.)

스키마는 Channel들의 집합으로 정의되는데, 각 채널에서는 궤도, 포즈, 헤딩, 페이즈 등 다양한 모션 매칭 규칙을 설정할 수 있다.

 

Trajectory Matching Channel

(offset은 미래 정보 쿼리를 위해 설정하는 데이터이다. 예를들어 Offset이 0.5 라면 0.5초 뒤의 flag에 해당하는 정보를 의미한다.)

 

Position Matching Channel

 

 

PoseSearchDatabase

: 모션 매칭 시 캐릭터의 다음 프레임으로 연결될 수 있는 애니메이션들과 PoseSearchSchema에 따른 샘플링 데이터가 저장된 에셋. PoseSearchSchema에서 설정했던 Sample Channel에 따라 애니메이션 데이터를 샘플링하여 저장한다. 모션 매칭 시 이 샘플링 해뒀던 데이터를 바탕으로 다음 프레임에 연결될 애니메이션을 찾는다.

 

Pose Search Normalization Set

 

Chooser Table