[번역] UE5 스켈레탈 애니메이션 정지(Stop) 방안 탐구 (완결)

저자: DarkFlameMaster

대기(Idle), 출발(Start), 걷기·달리기 루프(Cycle), 정지(Stop). 이 네 상태가 지면 위 이동 루프의 아주 표준적인 프레임을 이룬다. 오늘은 정지 상태를 만드는 데 어떤 방안들이 있을 수 있는지 같이 이야기해 보려 한다.

시작하기 전에 한 가지를 분명히 해 두자. 방안의 선택에는 우열이 없고, 맞느냐 틀리느냐만 있다.

방안 선택은 반드시 프로젝트에 맞춰——

게임 장르:（FPS는 보통 ARPG만큼 애니메이션을 중시하지 않는 식）

플레이어 층:（플레이어가 무엇을 중시하는지, 미적 감각이 어디까지인지）

애니메이션 리소스 특성: 자세가 중립적인지, 긴 전환인지 짧은 전환인지 등（경험은 아직 얕으니, 고수 여러분의 보충을 부탁드린다）

성능 비용과 유지 난이도: 보통 정지 로직이 복잡할수록 비용도 커지고 유지하기도 어려워진다. Motion Matching은 예외다.

——종합해서 결정해야 한다. 어느 방안이 더 화려해 보인다고 그걸 고르는 게 아니다.

0.가장 원초적인 정지 방안

이 방안은 Locomotion 애니메이션을 크게 중시하지 않거나, 애니메이션 기술력이 약한 게임에서 자주 보인다. 예를 들어 P5R, 코이카츠 같은 작품들.（물론 P5의 플레이어 층은 거친 애니메이션도 받아들일 수 있게 만들기도 한다. 아, 그런데 ATLUS는 NPC 시선 추종까지 해 놓고, 걷기 미끄러짐이나 출발·정지 같은 손쉬운 일은 왜 안 하는지 도무지 모르겠다）

이 방안에서 흔한 방식은 Cycle을 Stop 애니메이션 하나와 그냥 블렌딩하는 것이다. 더 심한 경우는 “Stop” 상태 자체가 없다（Stop이 없으면 보통 Start도 없다）. 캐릭터가 발을 멈출 때 Cycle을 Idle로 바로 블렌딩해 버린다.

정지 애니메이션이 하나뿐이면 단점이 꽤 뚜렷하다. 예를 들어 왼발이 앞에 있는 정지 애니메이션만 있다고 치자. 캐릭터는 아무 순간이나 걷기를 끝내고 정지로 들어갈 수 있다. 마침 왼발이 앞에 있어 정지 애니메이션 시작 포즈와 가깝다면, OK. 거의 이음매 없이 섞일 수 있다. 그런데 그때 오른발이 앞에 있다면, “발이 끌려가는 현상”이 거의 반드시 생긴다.

위 GIF처럼, 정지 애니메이션이 왼발 앞 포즈뿐이라 오른발이 앞에 있는 상태에서 정지로 들어가면, 오른발이 재빨리 뒤로 끌려가고 왼발이 재빨리 앞으로 끌려와 정지 포즈에 맞추려 한다. 반면 왼발이 앞에 있는 상태로 들어가면 두 발은 거의 움직이지 않아도 된다.

1.왼발·오른발 중 누가 앞에 있는지 구분하는 정지 방안（그리고 가능한 개선 전략들）

이 방안은 사실 앞 절에 “왼발과 오른발 중 누가 앞에 있는가” 판단을 더한 것이다. 그래서 왼발 앞 정지 애니메이션이냐, 오른발 앞 정지 애니메이션이냐를 고른다.

듣기엔 단순해 보이지만, 실제로 붙이면 넘어야 할 문제가 더 있다.

먼저, 보통 이 방안의 전제는 쓰는 애니메이션 라이브러리의 정지 애니메이션이 왼발·오른발을 구분해 둔 상태라는 점이다. 없으면 UE5 미러 노드로 한 벌을 직접 만들어야 하고, 만들 때도 주의가 필요하다. 예를 들어 캐릭터가 한 손으로 대검을 어깨에 멘 타입이라면, 하반신만 미러하고 상반신 데이터는 미러하지 않는 편이 나을 수 있다.（이 그림에 다크소울을 예로 든 건 사실 아주 적절하진 않다. 다크소울의 상반신 무기 홀드는 보통 오버레이라 Locomotion 뒤에 두기 때문이다）

다음으로, 캐릭터 서 있는 자세가 ALS처럼 “중립 위치”라면 괜찮다. 어느 발이 앞에 있는 정지 애니메이션이든, 같은 걸음 수를 걷고 나면 결국 발이 중립으로 돌아가니까.

그런데 0절 GIF처럼 왼발 앞·오른발 뒤의 개성 있는 스탠스라면, 아티스트가 정지 애니메이션을 만들 때 고민이 생긴다.

논의를 더 또렷하게 하려고 먼저 이렇게 가정하자. Idle 상태에서 캐릭터는 왼발 앞, 오른발 뒤 스탠스를 유지한다. 정지 애니메이션은 왼발 앞과 오른발 앞 두 종류. 왼발 앞 정지 애니메이션은 캐릭터가 감속하면서 두 걸음을 걷고, Idle 시작 프레임까지 전환을 끝낸다.

그렇다면 아티스트가 오른발 앞 정지 애니메이션을 만들 때, 이런 고민에 부딪힐 가능성이 크다. 오른발 앞 정지가 왼발 앞 정지와 같은 걸음 수(즉 2걸음)를 걸으면, 끝난 뒤에는 분명 오른발 앞·왼발 뒤 Idle 스탠스로 들어간다. 이때 가능한 해결책은 몇 가지다.

1. 오른발 앞 정지 애니메이션이 왼발을 한 걸음 더 내딛게 한다（혹은 한 걸음 줄인다）. 단점은, 왼발·오른발 시작 순간의 속도가 같은데 정지 걸음 수와 애니메이션 길이가 달라지고, 루트 모션 속도도 달라진다는 점이다. 표현을 좋게 만들려면 왼발 앞 정지를 미러한 뒤 한 걸음만 덜어 내는 식으로는 절대 안 된다.

2. 어차피 오른발 앞 Idle로 들어가니, 오른발 앞 Idle 포즈를 하나 더 만들면 되지 않나? 단점은, 오른발 앞 Idle을 만들었으면 오른발 앞 Start 포즈도 만들어야 한다는 것이다.

캐릭터가 앞 방향 이동 애니메이션만 있을 때는 그럭저럭일 수 있지만, 여덟 방향 이동(Strafe)이 필요하면 4（전후좌우）×3（Start·Cycle·Stop）×2（왼발 앞/오른발 앞）가 되어 애니메이션이 한꺼번에 12개 더 생긴다. 애니메이션 리소스 관리와 상태 머신 유지에 분명 부담이다.

UE5 미러 노드로 어느 정도 완화할 수는 있지만, 써 본 독자라면 잠재 골칫거리를 느낄 것이다. 예를 들어 Stride Warping과 같이 쓸 때 Graph 모드 자동 계산에 버그가 있어, 워핑 방향이 제때 미러되지 않아 가위발이 나올 수 있다. 지금으로서는 마음 놓고 쓰기 어려운 기능이다.

예전에 톈즈유 Redu 면접을 볼 때, 기술 담당자가 원신의 정지 방안을 조사한 이야기를 해 주었다. 결론은 원신이 왼발·오른발 구분에 그치지 않고, 그 위에 각각 두 구간을 더 나눈다는 것이었다（예를 들어 왼발 앞일 때 최대 보폭을 N이라 두고, 중립에서 0.25N / 0.75N으로 또 나눈다）. 정지 애니메이션이 네 구간. 이게 사실이라면 미러 없이 원신은 최소 애니메이션 24개를 더 써야 한다……

정지의 위상을 잘게 나눌수록 효과는 분명 더 자연스럽지만, 로직 복잡도·유지 용이성·메모리 사용량이 희생된다. 이 부분은 다음 절 ALS 정지도 어느 정도 참고할 만하다. 마찬가지로 위상을 4구간으로 나누지만, 절차적 정지라 애니메이션 리소스 복잡도는 높지 않다.

3. 캐릭터가 바로 정지하지 않고, 왼발이 앞에 올 때까지 한 걸음 더 걷고 난 뒤 정지한다. 에, 이러면 오른발 앞 정지 애니메이션조차 안 만들어도 되니 좋지 않나? 하지만 이 방안 역시 손맛과 조작감을 해친다. 플레이어가 멈추고 싶을 때 어떤 때는 바로 멈추고, 어떤 때는 굳이 한 걸음 더 가야 한다. 다만 고속 질주 때는 그 한 걸음 시간이 아주 짧아 조작감 영향이 작으니 고려할 만하다（그런데 사실 질주 정지는 속도가 높아 애초에 어색함이 잘 안 드러나기도 한다……）

2.ALS의 정지

ALS, 애니메이션 시스템의 교과서, 우리의 오랜 친구. ALS의 정지 방안은 전용 정지 애니메이션을 쓰지 않는다. 핵심 아이디어는 걷기·달리기(Cycle) 애니메이션을 Idle과 바로 블렌딩하되, 그 과정에서 먼저 FootLock（발 락）을 넣어 정지 시 미끄러짐을 한 번에 잡고, 그다음 발걸음을 다잡는 Additive 애니메이션을 섞어 정지 연출을 흉내 내는 것이다.

필자 개인적으로 보면, ALS 정지 방안이 다른 방안 대비 눈에 띄는 포인트는 “Cycle 주기의 4구간 위상 분할”（효과는 분명 왼발·오른발만 나누는 2구간보다 더 세밀하고 자연스럽다）、“절차적 정지”、“FootLock”이다.

먼저 결론과 장단점: ALS가 애니메이션 시스템의 교과서라 참고할 가치가 크다고 해서, 모든 방식이 최선·최적은 아니다. 그중 한 예가 지금 말하는 정지다. 위 GIF를 보면, 조작자가 마음만 먹으면 ALS 정지도 “발이 뒤로 끌려가는” 결과가 나올 수 있고, 정지할 때 “발이 너무 끈적하다”, “너무 갑작스럽다”는 느낌이 든다.

ALS가 지금 이 모양이 된 주된 이유는 “이 설계가 최고라서”가 아니다. 당시 ALS 작성자가 제한된 시간 안에 고품질 로코모션 애니메이션을 많이 뽑을 여력이 없어, 출발과 정지 모두 절차적 수단으로 “차선책”을 택할 수밖에 없었던 것이다. Lyra 애니메이션 시스템도 ALS 작성자 손에서 나왔다. 전문 아티스트 지원이 생기고 애니메이션 리소스 부족이 해소되자, ALS 작성자도 곧바로 전용 출발·정지 애니메이션 품으로 돌아간 걸 볼 수 있다.

다시 말하지만, 애니메이션 방안은 우열이 아니라 적합 여부다. 올해 오픈한 서브컬처 TPS 《칼라비츄》도 ALS 이 세트를 쓴다. 대다수 플레이어에게 ALS 정지 효과는 충분히 만족스럽고, 이 “차선책”의 미세한 이질감까지 감별할 안목이 꼭 있는 것은 아니다.

그래서 ALS 방안도 간단히 이야기해 보겠다（물론 이미 ALS에 아주 익숙한 독자는 구현 부분은 건너뛰어도 좋다）

정지 애니메이션을 만드는 흐름은 이렇다. Cycle에서 Stop으로 전환한다. 전환의 끝점은 서 있는 상태의 정지 포즈다. 전환 중에는 한편으로 Cycle（걷기·달리기 루프）에서 정지 포즈로 애니메이션을 넘기고, 한편으로 Additive 발걸음 정리 애니메이션을 더하고, 한편으로 일정한 순서로 왼발과 오른발을 하나씩 락한다. 이 “세 개의 한편”이 ALS의 복잡한 절차적 정지 방안 전부다.

1.1 Cycle에서 Idle로 전환

“정지 전환의 전체 과정”은 Locomotion States 상태 머신 안 Stop에서 Not Moving으로 넘어가는 흐름에 드러난다. Not Moving 안에는 서 있는 Pose, 즉 Idle이 들어 있다. Stop 노드 안에는 대체로 “Cycle에서 Idle로 넘어가는 상태”가 들어 있다. 이게 첫 번째 “한편”이다.

Pre-stop 안에는 Cycle 애니메이션이 들어 있다. FootDown 도관이 가리키는 둘에도 들어 있지만 FootLock 커브가 켜져 있고, FootUp 도관이 가리키는 두 상태에는 아예 걸음에 대응하는 접촉 프레임 애니메이션이 들어 있다. 다 익숙한 이야기고, 새로 말할 건 많지 않다.

많은 독자 인식에서 LeftFoot / RightFoot은 “정지 시 왼발이 앞인가 오른발이 앞인가”를, FootDown / FootUp은 “앞에 있는 발이 내려가는 중인가 올라가는 중인가”를 나눈다. 필자 개인 시선으로 보면, Left/Right와 FootDown/FootUp을 나누는 본질은 한 번의 완전한 보폭 안 위상을 나누는 일이다（왼발 한 번 + 오른발 한 번을 합쳐 하나의 보행 주기라 부른다）.

나는 이런 번잡한 “왼발 앞”, “왼발 접촉 프레임”, “오른발 극한 프레임” 호칭 대신 “위상”으로 나누는 쪽을 좋아한다. “왼발 앞 접촉 프레임（왼발을 앞으로 내딛고 땅에 닿는 순간）” 위상을 0, “오른발 앞 접촉 프레임（오른발을 앞으로 내딛고 땅에 닿는 순간）” 위상을 π로 두면, 나머지 위치도 위상으로 설명하기 쉽다.

본질이 위상 분할이니, 이 구분들이 전부 애니메이션 시퀀스의 Feet_Position 커브를 써서 정지 과정 전체를 4단계로 나눈 것도 이해할 수 있다.

Feet_Position 커브 절댓값이 1이 되는 순간은 발이 지면과 완전히 닿는 “접촉 프레임”이고, 절댓값이 0.2가 되는 순간은 한 발이 최고점까지 올라갔다가 내려오기 시작하는 순간이라 “극한 프레임”이라 부른다.

1.2 발걸음 정리

Stop 상태 머신의 네 상태 노드에 들어가면, 대응하는 블루프린트 이벤트가 트리거된다. 그 이벤트는 몽타주 형태로 발걸음 정리 Additive 애니메이션을 재생한다.

이건 일부 독자에게 꽤 신선할 수 있다. 보통 인식에서 몽타주는 전투 스킬이나 공격 Clip 재생에 자주 쓰이니까. Additive 애니메이션을 몽타주로 재생해 애니메이션에 “임시” 오버레이를 더하는 쓰임은 상대적으로 드물다.

Grounded Slot에서 재생되는 발걸음 정리 애니메이션은, 자연스럽게 BaseLayer 중단, MainGrounded States 뒤에서 Grounded Slot 노드로부터 “불려 나오거나”, 말하자면 “떠올라”, 그 입력과 Additive로 합쳐진다.

1.3 순서대로 왼발·오른발 락하기

ALS 발 락은 간단히 “언제 락할지 판단”과 “발을 어디에 락할지” 두 문제로 나눌 수 있다. 락 타이밍 문제는 기본적으로 발걸음 정리 애니메이션에 기록된 커브가 알려 준다. 발을 들면 당연히 락을 풀고, 땅에 내리면 락한다.

발걸음 정리 애니메이션 안에는 FootLock 커브가 보인다. FootLock_L을 예로 들면, 값 범위는 -1~0이다.

기억날 것이다. “왼발 앞 정지” 상태 노드에 들어갈 때마다 FootLock_L 커브를 1로 세팅한다. 결국 FootLock 커브를 수정하는 곳이 두 군데인데, 어느 쪽을 기준으로 할까?

사실 Additive 애니메이션의 커브는 BasePose 위에 그대로 더해진다. 즉 발걸음 정리 애니메이션 안 값은 -1~0이지만, 왼발을 먼저 락하는 상태 노드에서 FootLock_L을 1로 두었으니, 실제 범위는 1+(-1)~1+0, 곧 0~1이 된다.

（ps: 왜 처음부터 시퀀스 안 footlock 범위를 0~1로 두지 않고, 굳이 전체적으로 더했다 빼는 단계를 만드는지 알고 싶다면, 필자의 새 책이 나온 뒤 책에서 답을 찾아 보시면 된다~）

FootLock 커브 값은 FootLock 알파에 직접 영향을 준다. ALS는 미끄러짐을 피하려고 발 락의 페이드아웃만 허용하고 페이드인은 막았다. 다시 말해 발이 “락되지 않은 상태에서 순간적으로 락된 상태”로 바뀌길 원한다.

또한 발 락에는 “어디에 락할까” 문제도 있다. 이 문제는 발 뼈의 월드 스페이스 위치에서 그 프레임 스켈레탈 메시 이동량을 빼, 역으로 이전 프레임 위치를 얻는 방식으로 풀 수 있다. 바꿔 말하면, 정지 과정에서 캐릭터 무브먼트 컴포넌트는 감속하는데, 정상 상태라면 발이 미끄러지기 쉽다. 그런데 이 과정에서 발 위치가 메시와 같이 움직이지 않게 하면（매 프레임 메시 이동량을 계속 빼는 식으로）, 발 락이 구현된다.

마지막으로 간단히 정리하면, ALS 발 락은 Cycle에서 Idle로 전환하는 동안（혹은 FootUp에서 먼저 접촉 프레임으로, 다시 Idle로） 진행되고, 연출을 위해 감속 중 Additive 발걸음 정리 애니메이션을 Slot으로 출력에 동적으로 더하며, 감속 시 미끄러짐을 막기 위해 그 애니메이션에 기록된 FootLock 커브로 FootIK 발 락을 맞춘다.

3.Distance Match 주도 vs 싱크 그룹 주도

3.1 Lyra의 거리 매칭

Lyra의 이 정지 사고는 “정지를 얼마나 자연스럽게 만들까”보다 “정지할 때 어떻게 안 미끄러지게 할까”에 더 가깝다. 이 방안은 Lyra 애니메이션 팩처럼 아주 긴 정지 애니메이션에 더 잘 맞는다. 앞쪽 잉여 구간을 잘라 내기 때문이다. Cycle에서 Idle까지 10프레임도 안 되는 짧은 정지 애니메이션에는 잘 안 맞는다.

Distance Match는 이전 글에서 자세히 다뤘으니, 여기서 구현을 길게 반복하진 않겠다. UE5 스켈레탈 애니메이션 Lyra 거리 매칭 속도 매칭 - 즈후 (zhihu.com)

짚고 갈 점은, Distance Match 구상은 듣기엔 아름답지만 넘기 어려운 문제도 있다는 것이다. “멈추려면 아직 얼마나 더 가야 하는가”로 정지 애니메이션 StartPosition을 계산하기 때문에, StartPosition 자리의 위상과 현재 Cycle 위상 적합도는 거의 보지 않는다.

그래서 극단적인 경우 0절과 같은 문제가 생긴다. 위 Lyra 정지 녹화처럼, 질주 중 오른발이 앞에 있을 때 정지하면 왼발이 앞으로 재빨리 끌려가는 장면이 보인다. Lyra 표현이 그나마 봐줄 만해 보이는 이유는 Cycle에서 Stop으로 블렌딩할 때 FastFeet 블렌드 설정을 써서 발 블렌딩을 크게 가속하기 때문이다. 플레이어는 발이 “끌려” 간 게 아니라 한 걸음 더 내딛은 것처럼 느낀다. 이 점은 참고할 만하다.

3.2 싱크 그룹과 싱크 마커 주도

또 다른 아름다운 구상은 싱크 그룹과 싱크 마커를 쓰는 것이다. 싱크 마커 자체가 사실상 두 다리 위상의 분할이니까——게다가 “L-R 마디, 35%”처럼 비율까지 아주 정밀하다. Stop을 팔로워로 두고, 지금 Cycle이 있는 위상으로 재생 시작 위치를 정하면 얼마나 좋겠는가?

생각은 아름답지만, 현실은 늘 뜻대로만 가지 않는다.

UE4 UE5 싱크 마커, 정말 제대로 쓰고 있나? 짚신벌레도 이해되는 싱크 마커 - 즈후 (zhihu.com)

이전 싱크 그룹 글에서 이 함정을 말한 바 있다. Cycle은 루프 애니메이션이라 리더로 두고 Stop을 팔로워로 두면, Stop이 멈추거나 점프하거나 심지어 Cycle과 같이 루프하는 이상 현상이 난다. 그래서 Stop은 리더만 될 수 있다.

그런데 곧 알게 되겠지만, Stop은 사실 리더조차 못 된다.

Lyra를 보면 Start와 Cycle은 같은 싱크 그룹 Locomotion에 묶여 있고, Stop은 그들과 같은 그룹에 아예 안 들어 있다. 왜일까?

셋의 관계가 Start에서 Cycle로 단방향 전환이기 때문이다. Start가 리더고, Cycle이 자신의 StartPosition을 맞춰 현재 재생 위치에 협력한다. Cycle에서 Stop으로 단방향 전환할 때는 논리상 Stop이 StartPosition을 맞춰 위상에 협력해야 하는데, Stop을 리더로 두고 첫 프레임부터 자연 재생하면, 원래 Cycle 애니메이션이 그 때문에 점프해 버린다——당연히 블렌드 결과도 점프한다.

다만 프로그래머 입장에서, 정지가 일어날 때 Cycle의 싱크 마커（즉 위상 정보）를 가져와 Stop 시작 위치를 정하는 흐름을 손으로 짜는 건 어렵지 않다. 그러니 싱크 그룹 아이디어는 빌리되, UE 싱크 그룹에 묶일 필요는 없다.

4.국소적인 간이 Motion Matching

위상 분할의 번거로움에 시달릴 때, 다른 방안이 새로운 가능성을 열어 준다——Motion Matching, 혹은 Pose Search를 써서, 캐릭터 양발의 위상 매칭으로 정지 애니메이션에서 알맞은 StartPosition을 바로 검색하는 것이다.

먼저 효과를 보자. 이건 내가 대충 만든 간이 버전이라 정지·출발에 미끄러짐 방지까지는 안 붙였다. 그래도 여기서 “정지, 출발, Idle 모두 좌우를 구분”하는 건 구현했다.

이번 절의 주된 목적은, Motion Matching이 1절에서 말한 “왼발·오른발 구분”이 가져올 수 있는 애니메이션 블루프린트 로직 복잡도 배수 증가 문제를 어떻게 넘는지 보여 주는 데 있다.

많은 독자가 Motion Matching을 아주 거창한 것, 트리플A나 아주 복잡한 구기 종목 게임에서나 쓰는 것으로 느낀다. 사실 오해다.

Motion Matching（이하 MM）이 모션 캡처·고복잡도 애니메이션 블루프린트와 자주 같이 등장하는 건 맞지만, MM의 사고 본질은 평소 쓰는 상태 머신과 크게 다르지 않다. 둘 다 “수많은 애니메이션 리소스 중 재생하고 싶은 것을 골라낸다”는 점이다.

전통 방식에서는 위상이나 커브 같은 잡다한 걸 직접 계산해 “선별 방식”을 정해야 할 때가 많다. MM은 Pose Match와 Trajectory Match, 즉 포즈와 궤적 적합도에 더 기대는 편이다. 그 관점에서 MM은 애니메이션을 고르는 여러 방식 중 하나일 뿐이고, 다른 방식과 얼마든지 섞어 쓸 수 있다.

이 글에서 줄곧 다룬 문제, 사실 “Cycle에서 정지로 섞을 때 어느 프레임부터 재생하는 게 맞나”인데, 이 문제는 Pose Match로 풀기에 아주 잘 맞는다. 이제 트리플A + 방대한 모캡 라이브러리와는 다른, 작지만 예쁜 Motion Matching을 보여 드리겠다.

（Tips: 이런 MM은 훨씬 단순하지만, 기초는 먼저 살짝 익혀 두어야 한다. 여기서는 길게 풀지 않겠다. 필자 이전 글 UE5 Motion Matching 파라미터 튜닝 혈루사 입문에서 무덤까지 - 즈후 (zhihu.com)를 참고하면 된다. 좋은 튜토리얼도 많이 추천해 두었다.

）

먼저 파일 구조를 보자. 미러 테이블 하나, Schema 하나, 나머지 Idle부터 Stop까지 네 상태가 이 Schema를 공유한다. 어디까지나 데모용이라 그렇고, 실제 프로젝트에서는 애니메이션 특성에 맞춰 상태마다 Schema 수치를 미세 조정하는 편이 일반적이다.

1.2절 방식에서는 골치 아팠던 문제가, 이제는 미러 데이터 테이블 하나로 해결된다.

애니메이션 블루프린트에서는 네 상태가 각각 MM 노드 하나를 쓰고, 대응하는 Database를 붙인다.

핵심 내용은 대체로 이 정도다. 의외로 적지 않은가?

보면, 우리 Motion Matching은 모든 애니메이션을 Database 하나에 쑤셔 넣지 않았다. Database마다 애니메이션 하나면 충분하다（Strafe를 안 한다면）. Database 하나에 애니메이션을 잔뜩 넣는 건 사실 매우, 매우 비추천이다. 이유를 설명하겠다.

첫째, 포즈 검색 난이도가 올라간다. Cycle만 계속 재생하고 싶은데 Stop 전반이 Cycle과 거의 같아서 Stop이 검색되어 나올 수 있다（그리고 Search 간격 설정과, 애니메이션을 더 이어 재생하고 검색을 줄이려는 성향 때문에, Cycle이어야 할 때 Stop 동작이 나와 버릴 수 있다……）.

둘째, 성능 비용이 커진다. 이 프레임에는 정지 애니메이션만 찾고 싶은데 Idle과 Start까지 데이터베이스에 섞여 검색에 참여하면, 쓰일 리 없는 프레임을 잔뜩 계산하게 된다.

다만 짚어두면, 이런 MM은 정말 잘 먹고 특히 프로토타입에서 게으름 피우기 좋지만, 현재 UE 완성도는 아직 아주 높진 않다.

예를 들어 UE5 애니메이션 노드 바인드 함수는 시퀀스 플레이어·이밸류에이터에 쓸 만한 게 많은데, MM 노드도 애니메이션 샘플링 패밀리인데 쓸 만한 함수가 거의 없다（Distance Match를 MM에 쓰려면 손수 또 손봐야 한다）.

또 애니메이션 상태 머신에서 Start→Cycle, Stop→Idle 전환 조건으로 자주 쓰는 “현재 애니메이션 시퀀스 남은 시간”（재생 종료까지 남은 시간 판단）도 MM에는 안 맞는다.

이런 것들은 사실 어렵지 않고 만들기도 쉬운데, MM 자체가 아직 이터레이션 단계라 잔가지를 지금 만들면 나중에 MM 변경에 따라 다시 만들어야 해서 인력이 낭비될 수 있다.

마지막으로, 어떤 독자 마음속에는 MM 성능 비용이 크다는 고정관념이 있을 수 있다.

동작 라이브러리에 넣는 시퀀스 수는 많지 않아도, 시퀀스마다 수십 프레임이 쌓이면 무시하기 어려운 비용이 된다. 그럼 어떻게 할까?

여전히 위에서 말한 “트리플A 방식을 그대로 베끼지 말고, 작지만 예쁘면 충분하다”는 사고를 따른다. 동작 라이브러리에 시퀀스가 몇 개뿐이라면, MM이 검색할 프레임도 몇 개뿐이면 안 될까?

예를 들어 Cycle에서 Stop으로 넘어가는 시간은 사실 그 정도고, Stop 뒤쪽 대부분 동작은 전환이 끝난 뒤 자연 재생된다. 바꿔 말하면 “Stop 애니메이션 블렌드인 윈도우”가 시퀀스 전체에서 차지하는 비중은 아주 작다. 이 사고를 따라 BlockTransitions 애니메이션 노티파이 상태를 쓰면, Stop 애니메이션 대부분 프레임은 자연 스테핑으로만 재생되고, MM 검색의 “시작 프레임”으로는 나오지 않게 만들 수 있다.

마찬가지로 다른 애니메이션 시퀀스도 이 사고로 최적화할 수 있다.

후기（잡담）

안녕하세요, DarkFlameMaster입니다. 석 달 만에 또 글 하나를 올렸습니다. 이 정도면 업데이트 속도가 일본 신작 애니 분기 편성 수준이네요…… 가을 신작, 겨울 신작, 일 년에 네 편…… 농담이고, 올해 상반기는 회사 다니느라 바빴던 게 사실이지만, 업데이트 빈도가 이렇게 떨어진 주된 이유는 역시——

“내가 나누고 싶은 내용이 다들 이미 아는 거, 혹은 영양가 없는 내용 아닐까? 글 물타기처럼 느껴지진 않을까?”

이런 생각 때문에 반쯤 쓴 글이 두세 편 사장됐습니다. 실력이 오를수록 “인터넷에 없고, 아무도 안 썼고, 비교적 어려운” 걸 나눠야 할 의무가 있다고 느꼈고, 겹치는 내용을 쓰기 싫어졌습니다. “좀 물은” 글을 내는 건 독자 시간을 낭비하는 일이라고 생각했습니다.

그중 사장된 한 편

그중 사장된 한 편

【위 이미지 설명 · 한국어 번역】

2.1 커브로 구원! 오리엔테이션 워핑의 실패한 보간 피하기

UE5.1까지, 오리엔테이션 워핑(Orientation Warping)을 보여 주는 Lyra에서는 캐릭터 이동 방향이 정오른쪽에서 오른쪽 뒤로 바뀔 때, 엉덩이 방향이 정왼쪽에서 오른쪽 뒤로 135도 돌아야 한다. 이는 Lyra에 ALS처럼 정방향 걷기와 뒷걸음 걷기, 좌우 이동 애니메이션 두 세트를 따로 준비해 두지 않았기 때문이다.

그래도 보면, Lyra에서 엉덩이를 이 135도 돌릴 때 조금 너무 빨라서 부자연스러워 보인다. 물론 눈치 빠른 독자라면 커브로 구원하는 방식을 떠올렸을 것이다. 오리엔테이션 워핑에 넣는 Angle 파라미터를 보간해서 조금 느리게 만들면 되지 않느냐고.

아쉽게도, 버그 때문인지 설계 자체 문제인지는 모르겠지만（오리엔테이션 워핑 소스 코드를 자세히 보진 않았다）, Angle 파라미터를 보간해도 캐릭터 엉덩이 회전은 여전히 매우 빠르다——심지어 애니메이션 표현은 더 나빠지기까지 한다. 아야, 이건 정말 골치 아프다.

작년 말, 나는 Lyra 오리엔테이션 워핑에 보간을 걸어 보려 했지만 원하는 결과를 얻지 못했다. 풀이 죽어 있던 내가 올해 우연히 UMS 시스템을 열었다가, 나도 모르게 책상을 치며 감탄했다. 맞아, 바로 이거다!

이렇게 하니 좋은 점은, 올해 쓴 세 편은 어느 편이든 인터넷에서 보기 드문 글이고, 품질과 내용이 독자에게 부끄럽지 않다고 자신할 수 있다는 점입니다. 나쁜 점은, 올해 겨우 세 편만 썼다는 점……

그런데 지금은 생각이 정리됐습니다. 처음 이 길을 걸을 때 선배들 발자국을 서툴게 흉내 내다 비틀거렸고（가장 먼저 쓴 가비지 컬렉션 글을 보면 됩니다）, 애니메이션을 막 배울 때도 남이 가르친 내용을 반복·정제하는 글을 썼습니다.

그런데 그게 어쨌단 말입니까? 글을 쓰기 시작한 초심은 가르치며 배우는 것이었고, 지식을 더 잘 이해하고 익히기 위함이었으며, 그다음이 그 과정에서 글을 잘 써서 읽는 이에게도 도움이 되게 하는 것이었습니다. 지금 제 눈에는 “물”처럼 보여도, 입문한 지 얼마 안 된 초심자에게는 도움이 될 수 있고, 누군가 조금이라도 도움을 받으면 제 글은 헛되지 않습니다.

그래서 이후 업데이트 빈도는 올라갈 것 같습니다(아마). 최근 반쯤 써 둔 여덟 방향 이동 방안 글도 곧 올릴 예정입니다.

그리고, 다들 아시듯 저는 아직 대학생이고 내년에 졸업합니다. 이 한두 달 가을 채용을 겪어 보니, 솔직히 이렇게 어려울 줄은 몰랐습니다.

저한테는 “워, 새 메일, 면접 잡힌 건가?”로 바꿔야 할 정도……

저한테는 “워, 새 메일, 면접 잡힌 건가?”로 바꿔야 할 정도……

즈후에서 기술 글만으로 팔로워 1만을 모았고, 스켈레탈 애니메이션 쪽에서 어느 정도 영향력도 있으니, 다른 신입보다 경쟁력은 있을 거라 생각했습니다. 그런데 지금까지 지원한 곳, 그리고 피피 형 같은 열정 있는 분들이 내밀어 준 곳까지 합치면 이미 30곳인데, 정식 오퍼는 하나도 없습니다……（텐센트는 더합니다. 열정 있는 분 세 분과 선배 한 분이 내밀어 주셨는데, 지금까지 면접조차 안 잡힙니다……）

솔직히, 정보가 부족해 가을 채용 준비를 최선으로 못 했고, 방향도 뒤늦게 또렷해져 귀한 기회를 여러 번 흘려보냈습니다. 알고리즘도 단단하지 못해, 필기 프로그래밍 네 문제 중 쉬운 앞부분만 풀고 뒤쪽 복잡한 문제·시뮬레이션 문제에서는 늘 막힙니다（그래서 지금까지 필기를 통과한 곳이 없습니다）. 네, 압니다. 저 자신에게도 문제가 많다는 걸.

독자 여러분께 웃음거리가 됐네요.

하지만, 글 앞머리와 끝에 인용한 《연애 마음대로 링크》 대사처럼——

저는 제가 아주, 아주 많은 우회로를 걸었고, 많은 곳에서 완벽하지 못했다는 걸 압니다. 그래도 그건 그때의 제가 제한된 조건에서 할 수 있는 최선이었습니다. 저는 전지전능하지 않고, 게으름도 피우고, 그저 평범한 사람입니다. 우회로도 많고 좌절도 많았지만, 바로 그것이 지금의 저를 만들었고, 저는 제 자신을 부정하고 싶지 않습니다.

올해 가을 채용 형세는 어렵습니다. 동기 열 명 중 정식 오퍼를 받은 사람은 한 명뿐입니다. 환경이 정말 나쁩니다. 하지만 환경이 나쁘다고 한탄해 봐야 달라지는 건 없습니다. 한숨 한 번 쉬고, 그다음 이 모든 걸 받아들입니다. 어떤 어둠 속에 있든 빛을 찾는 일을 포기하지 않는 것——그게 바로 싸움이 아니겠습니까?

마지막으로, 모두 건강하시길 빕니다. 경제의 상승과 하강은 몇 년, 십수 년을 한 순환 주기로 돌 뿐이지만, 인생 수십 년 동안 그런 시기를 한 번만 겪지는 않을 겁니다. 일자리를 찾느냐 못 찾느냐는 한때의 일이고, 건강은 평생의 일입니다.

스켈레탈 애니메이션 교류방: 916274600. 속상한 일이 있으면 와서 이야기해요.

사람들은 자주 자기 처지만 원망한다. “그렇게 돼 버려서 그렇다”고 투덜대고, 그렇게 된 일을 원망하며, “그게 아니었더라면” 하는 존재하지도 않는

허구의 세계를 그린다.

클래식 영전!

클래식 영전!