[번역] UE4 UE5 골격 애니메이션 고급 로코모션 시스템: 점프

저자: DarkFlameMaster

최근 언리얼 엔진의 골격 애니메이션 관련 지식을 공부하고 있다. 가르치면서 배우자는 생각으로, 여기서 애니메이션 관련 글을 좀 써서 방금 배운 것을 바로 팔아먹어보려 한다.

뭐라고? 점프 같은 간단한 것에 뭐 설명할 게 있냐고? 어어어, 잠깐 가지 마라. 점프 하나를 구현하는 건 쉽지만, 자연스럽고 진짜 같은 점프를 구현하는 건 결코 쉽지 않다.

게임 속 골격 애니메이션이든 일본 2D 손그림 애니메이션이든, 가장 중요한 것은 걷기, 달리기, 점프처럼 일상생활에서 어디서나 볼 수 있는 동작을 잘 처리하는 것이다. 이런 동작은 우리가 현실에서 너무 많이 봐왔기 때문에, 조금만 부자연스러워도 금방 뭔가 이상하다는 것을 알아차린다. (반대로 마법을 쓰거나 검극으로 싸우는 동작 같은 것은 현실에서 거의 본 적이 없으니 기준을 찾을 수 없고, 그래서 이런 동작에 대한 관용도는 더 높다.)

따라서 한 게임의 애니메이션 수준은, 흔히 이런 가장 기초적이고 게임에서도 현실에서도 가장 많이 쓰이는 동작에서 드러난다. (일본 손그림 2D 애니메이션도 마찬가지다.)

먼저 최종 완성 효과 이미지를 하나 올려 독자를 붙잡아보겠다. (급하게 이 글을 닫지 말고) 어떻게 만드는지 궁금하다면 같이 아래로 따라와 보면 된다.

(다만 이 완성본도 아직 완벽하다고 할 수는 없다. 발 고정도 아직 하지 않았고, 관성화 처리도 아직 하지 않았다.)

설령 이 글이 정말 별로라고 느껴지거나 흥미가 생기지 않더라도, 떠나기 전에 좋아요 하나만 눌러주고 가주면 좋겠다. 부탁이다 ≥﹏≤

내가 쓴 기술 블로그는 예전에 많은 사람에게 도움이 된 적이 있다. 이제는 나도 여러분의 도움을 받고 싶다! (작은 좋아요 버튼 한 번만 누르면 된다!)

1. 모두가 쓰지만, 사실 쓰기 좋은 것은 아닌 구현방안

내가 감히 모두가 써봤다고 장담할 수 있는 방안이 무엇이냐고? 그건 당연히……!

언리얼 엔진의 템플릿 프로젝트다 = = 어쨌든 블루프린트를 배워본 사람이라면 엔진에 딸려오는 3인칭 템플릿 프로젝트는 반드시 써봤을 것이다.

우리가 3인칭 UE 템플릿 프로젝트를 하나 열고, 스켈레탈 메시를 따라 애니메이션 블루프린트를 찾아 들어가면, 이런 상태 머신을 볼 수 있다.

이 상태 머신은 매우 간단하고 이해하기 쉽다. Idle/Run은 캐릭터가 정상적으로 지면에 서 있을 때의 상태 집합을 대표한다. JumpStart는 기상, 즉 점프 시작이고, 점프 시작 애니메이션이 재생되면 공중 체공 애니메이션을 루프한다. 착지할 때는 착지 애니메이션을 재생하고, 재생이 끝나면 다시 지면 상태로 돌아간다.

이 방식의 신뢰도는 간신히 합격선에는 도달했다고 볼 수 있다. CF 같은 게임에 쓰면, 모두가 익숙하게 보아와서 딱히 부자연스럽다고 느끼지는 않을 것이다. 하지만 ALSV4로 만든 효과와 비교하면 곧바로 초라해진다. 주요 문제는 다음과 같다.

1. 기상 시 왼발이 앞인지 오른발이 앞인지 구분하지 않고, 하나의 점프 시작 애니메이션만 통일해서 사용한다. 캐릭터 이동 속도가 빠를 때는 그럭저럭 들키지 않지만, 속도가 느릴 때는 비교적 분명하게 드러난다.
2. 기상 시 캐릭터의 이동 속도에 따라 점프 시작 애니메이션을 구분하지 않는다. 속도 0의 제자리 점프와 전력 질주 중의 점프에 같은 애니메이션 세트를 사용한다. (생각해보라. 현실에서 제자리에서 수직으로 뛰는 것과, 한참 도움닫기를 해서 앞으로 뛰는 동작이 같을 수 있겠는가.)

글 첫머리의 GIF는 걷기, 달리기, 전력 질주 세 상태에서의 점프 시작 동작을 보여준다. 아주 분명히, 동작 폭이 완전히 다르다.

1. 점프 과정 중 무게중심이 변화하는 과정이 없다. 기상, 공중, 나아가 착지할 때까지, 우리의 무게중심은 몸의 균형을 유지하기 위해 변화한다. 구체적인 변화 과정은 일률적으로 말하기 어렵다. 예를 들어 제자리 멀리뛰기 착지 시 무게중심은 앞으로 이동할 수도 있고, 뒤로 이동할 수도 있다. 뒤로 이동하면 엉덩방아를 찧게 된다. 연속적인 달리기 점프의 무게중심 변화도 제자리 멀리뛰기의 무게중심 변화와 다르다. 여기서는 하나하나 길게 말하지 않겠다. ALSV4에서는 기본적으로 사람이 상승 단계에서는 무게중심이 앞으로 기울고, 하강 단계에서는 뒤로 기운다고 본다.
2. 착지 시 낙하 속도에 따라 착지 애니메이션을 구분하지 않는다. 높은 곳에서 떨어지는 것과 작은 계단에서 살짝 뛰어내리는 것은 낙하 속도에 큰 차이가 있다. 우리는 캐릭터 무릎이 내려가며 완충하는 시간의 길고 짧음으로 낙하 속도의 빠르고 느림을 표현해야 한다.
3. 캐릭터 착지 시의 이동 요구를 고려하지 않는다. 위의 상태 머신을 보면, 로직은 착지 애니메이션이 거의 재생 완료될 때에만 정상적인 지면 상태 집합으로 돌아간다. 그런데 만약 착지 애니메이션이 아직 끝나기 전에 이동을 시작하면, 우리는 착지 상태 노드 안에 머무른 채 캐릭터를 이동시키게 된다. 이때 아직 착지 상태 노드 안에 있고 정상적인 지면 상태 집합으로 돌아가지 않았으므로 캐릭터의 이동 동작을 처리할 수 없다. 그래서 딱딱한 슬라이딩 현상이 나타난다. 말로 들으면 조금 복잡하고 이해하기 어려울 수 있으니, 아래 GIF를 보면 바로 알 수 있다.

어떤 세심한 독자는 이렇게 물을 것이다. “내가 3인칭 템플릿을 썼을 때는, 달리면서 점프해도 착지할 때 그렇게 뚜렷한 슬라이딩을 느끼지 못했던 것 같은데?” 이유는 언리얼 템플릿의 착지 애니메이션이 겨우 0.2초밖에 되지 않고, 착지 애니메이션과 지면 상태를 블렌드하는 시간도 0.2초이기 때문이다. 그래서 그 슬라이딩을 알아차리기 어렵다.

하지만 0.2초는 너무 빠르다. 비교적 뚜렷한 착지 동작을 보여주기에는 부족하다. 그리고 착지 애니메이션이 조금만 길어져도 슬라이딩 문제는 곧바로 튀어나온다. 그러므로 UE 템플릿의 방법처럼 잔꾀로 게으름을 피우는 것은 장기적인 해법이 아니다. 착지 이동과 착지 정지를 구분하는 것이야말로 현명한 선택이다.

2. ALSV4가 사용하는 점프

2.1 데이터 준비

1. 상태 머신은 우리가 언제 점프했는지 알아야 한다. 따라서 이를 표시할 변수가 필요하다. 템플릿 프로젝트에서는 이동 컴포넌트에 내장된 낙하 함수를 사용해 판단하는 것을 볼 수 있다. 물론 이렇게 해도 되지만, 좋은 선택은 아니다.

다음 상황을 생각해보자. 캐릭터 발밑의 바닥이 갑자기 무너졌다. 캐릭터가 물살을 이기지 못해 절벽 아래로 휩쓸려 내려갔다. 혹은 단순히 작은 계단 하나를 내려갔다…… 이런 상황에서도 마찬가지로 여기의 “Is in Air?”는 참이 된다. 하지만 이때 우리가 캐릭터에게 점프 동작을 하게 만들고 싶지는 않을 것이다. 그러므로 가능하면 구분해두는 것이 좋다. 캐릭터가 떨어지고 있는지를 판단 기준으로 삼는 것이 아니라, 캐릭터가 정말로 점프했다는 이벤트로 변수 변화를 트리거해야 한다.

1. 두 번째 변수는 낙하 속도다. 이것은 캐릭터 속도의 Z축 값에서 직접 얻어지므로, 그 양수/음수는 캐릭터가 현재 상승 중인지 하강 중인지를 표시할 수 있다. 그리고 절댓값은 일반 낙하 애니메이션과 빠른 낙하 애니메이션을 블렌드하거나, 가벼운 착지와 무거운 착지 애니메이션을 블렌드하는 데 사용할 수 있다.

1. 세 번째 변수는 캐릭터의 몸 기울기량이다.

우리는 캐릭터 자신의 좌표계 안에서의 속도를 기준으로, 그것을 X/Y축 속도 성분으로 분해한다. 이 성분은 곧 기울기 각도량을 대표한다. 이 기울기량은 지면에서 걷고 있을 때든 공중에 있을 때든 모두 사용해야 한다. 캐릭터 무게중심 변화에 따른 몸 기울기를 표현하기 위해서다. 공중 기울기량은 캐릭터가 상승 상태인지 하강 상태인지에 따라 추가로 하나의 기울기 계수를 곱하기만 하면, 점프 시작부터 낙하까지 무게중심이 앞에서 뒤로 이동하는 과정을 표현할 수 있다.

공중에서 추가로 기울기 계수를 곱해야 한다고 말했으니, FallSpeed의 양수/음수와 값을 어떻게 사용해 한 번의 점프 과정을 반영하고, 각 시점에 필요한 기울기 계수를 계산할 수 있을까? ALSV4는 이런 커브 하나를 사용했다. FallSpeed 값을 입력하기만 하면, 적절한 기울기 계수가 얼마여야 하는지 알려준다. 원리는 그림과 같다.

2.2 단점들을 하나씩 극복하기

1. 기상 시 왼발이 앞인지 오른발이 앞인지 구분하지 않는다

이건 비교적 간단하다. (하지만 예전에는 이야기한 적이 없었던 것 같다.)

언제 오른발이 앞이고, 언제 왼발이 앞인지 누가 가장 잘 알까? 답은 당연히 애니메이션 자신이다. 애니메이션은 자기가 어느 위치까지 재생되었는지 알고 있다. 따라서 우리는 두 가지 방법을 사용할 수 있다. 하나는 애니메이션 노티파이, 다른 하나는 애니메이션 커브다. 둘 다 애니메이션이 시간에 따라 변화하는 어떤 정보를 외부에 알려줄 수 있다. ALSV4는 애니메이션 커브를 사용한다. 이유는 【1】에서 자세히 설명한다.

그림처럼 ALSV4는 걷기, 달리기 등의 애니메이션 안에 Feet_Position이라는 커브를 편집해두었다. 왼발과 오른발의 앞뒤가 바뀔 때마다 그 값을 바꾼다. -1은 왼발이 앞, 1은 오른발이 앞을 뜻한다.

그렇다면 우리는 점프 상태 머신을 하나 만들고, 점프 시작 시 Feet_Position 값을 한 번 가져와서 그것이 0보다 큰지 작은지만 보면 된다. (직접 1인지 -1인지 판단하면 안 된다. 애니메이션 블렌드가 커브 값도 함께 블렌드하므로 실제 값은 ±0.x 정도가 될 수 있기 때문이다.) 그런 다음 그에 맞는 왼발 앞 점프 시작 애니메이션 또는 오른발 앞 점프 시작 애니메이션을 재생하면 된다.

2. 기상 시 캐릭터의 이동 속도에 따라 점프 시작 애니메이션을 구분하지 않는다

이건 더 간단하다. 동작 폭이 큰 빠른 달리기 점프 시작 애니메이션 하나와, 동작 폭이 작은 걷기 점프 애니메이션 하나만 준비한 뒤, 캐릭터의 실제 속도값에 따라 그것들을 블렌드하면 된다.

3. 점프 과정 중 무게중심 변화 과정이 없다

위의 2.1절에서 캐릭터 몸 기울기량을 이야기할 때, 이미 “점프 과정에 따라 동적으로 변화하는 적절한 몸 기울기량”을 어떻게 계산하는지 설명했다. 이 계산 과정을 한 문장으로 요약하면 이렇다.

캐릭터의 수평 속도를 사용해 기본 기울기량과 점프 방향을 계산하고, 캐릭터를 점프 방향(혹은 이동 방향)으로 기울이며, 캐릭터 Z축 속도가 반영하는 점프 과정을 통해 캐릭터의 전방 기울기량을 점차 후방 기울기로 바꾼다.

좋다. 아직도 잘 이해되지 않는다면 五谷延年 선배의 튜토리얼을 참고하거나 ALSV4 프로젝트를 직접 뒤져보면 된다. 여기서는 더 길게 설명하지 않겠다. 이제 계산된 몸 기울기량을 어떻게 적용하는지 이야기해보자.

ALSV4는 앞/뒤/좌/우로 기울어진 4개의 포즈를 만들고, 그것들을 로컬 스페이스 Additive 애니메이션으로 설정했다. (전신을 기울여야 하므로 메시 스페이스 Additive를 사용한 것이 아니다.) 그리고 2D 블렌드 스페이스를 만들어, 입력된 X/Y축 기울기량에 따라 대응하는 기울기 포즈를 출력하게 했다.

그렇다면 다음에 해야 할 일은 매우 분명하다. 기울기 정도 값을 이 블렌드 스페이스에 입력하고, 반환된 기울기 포즈를 Additive 형식으로 원래의 Jump 상태 머신 위에 더하면 된다. (원래 Jump 상태 머신 안에는 점프 시작과 체공 두 과정이 포함되어 있고, 두 과정 모두 몸 기울기가 필요하기 때문이다.)

4. 착지 시 낙하 속도에 따라 낙하/착지 애니메이션을 구분하지 않는다

먼저 낙하 애니메이션이다. 일반 속도 낙하와 빠른 낙하를 낙하 속도로 블렌드하면 된다. 더 말할 필요가 없다.

그다음은 착지 애니메이션이다. 이것도 마찬가지다. 가벼운 착지와 무거운 착지를 블렌드한다.

5. 캐릭터 착지 시의 이동 요구를 고려하지 않는다

앞에서 말했듯, 캐릭터는 착지하자마자 바로 이동을 시작하고 싶을 수 있다. 어떤 게임(예를 들어 세키로)에서는 캐릭터가 높은 곳에서 떨어져 착지할 때(무거운 착지), 일시적으로 캐릭터의 조작권을 빼앗고, 착지 완충 애니메이션이 끝난 뒤에야 이동하거나 다른 행동을 시작할 수 있게 한다.

이처럼 애니메이션이 끝나기 전에는 캐릭터가 움직이지 못하게 하는 것은 당연히 슬라이딩을 극복하는 방법 중 하나다. (애초에 움직일 수 없으니 슬라이딩이 어디서 오겠는가.) 하지만 무거운 착지에는 이렇게 할 수 있어도, 캐릭터가 작은 계단 하나에서 뛰어내렸을 뿐인데도 조작권을 빼앗을 수는 없다. 그렇게 하면 플레이어의 게임 경험에 심각한 부정적 영향을 줄 것이다. 그러니 이 방법으로 게으름을 피우려는 길은 막혀 있다.

이제 캐릭터가 착지할 때도 어떻게 자연스럽게 이동할 수 있게 할지 생각해보자. 이 사고방식은 사실 캐릭터가 이동하면서 사격하는 것을 어떻게 만들지와 같은 사고방식이다. 모두 이동을 주 애니메이션으로 삼고, 이동하면서 하는 “다른 일”을 추가적인 Additive 애니메이션으로 처리하는 것이다.

따라서 우리는 가벼운/무거운 착지 애니메이션을 메시 스페이스 Additive 애니메이션으로 설정할 수 있다【2】. 그런 다음 위의 4번에서 했던 것처럼 FallSpeed로 블렌드하고, 마지막으로 지면의 걷기/달리기/전력 질주를 총괄하는 상태 머신에 그것을 더하면 된다.

【1】왼발/오른발 처리방안 선택 문제에 관하여:

여기서 애니메이션 노티파이를 사용하는 것은 필자 개인적으로는 적합하지 않다고 본다. 왜냐하면 우리는 항상 왼발/오른발의 선후 문제를 처리해야 하는 것이 아니기 때문이다. 걷던 상태에서 멈출 때, 지면에서 점프할 때 같은 소수의 경우에만 왼발/오른발의 선후에 따라 애니메이션 선택을 결정할 필요가 있다.

어떤 애니메이션에만 이런 특수 처리를 해야 할까? 우리가 해야 할 것은 걷는 상태에서 점프로 전환하거나, 걷다가 갑자기 멈출 때만 왼발/오른발을 구분하는 것이다. 따라서 왼발/오른발 앞뒤 처리를 위한 커브나 노티파이를 만들어야 하는 것은 걷기, 달리기, 전력 질주, 웅크린 걷기 같은 애니메이션뿐이다.

필자가 적합하지 않다고 느끼는 데는 주로 두 가지 이유가 있다.

첫 번째 이유는 대량의 IF 판단이 비교적 큰 비용을 유발할 수 있다는 점이다. 걷기/달리기 애니메이션은 평소 매 순간 사용된다. 애니메이션 노티파이를 사용하면 많은 시간 동안 노티파이가 트리거되고, 노티파이 안에서 “지금 멈추려 하는가?”, “지금 점프하려 하는가?”를 하나하나 판단해야 한다…… 이는 CPU 분기 예측에 그다지 우호적이지 않다.

두 번째 이유이자 가장 중요한 이유는, 왼발/오른발을 구분해야 하는 상황이 늘어나는 순간(새로운 요구가 생기는 순간), 예를 들어 갑자기 캐릭터가 뒤쪽 발로 발차기하는 동작을 추가하고 싶어졌다고 하자. 그러면 우리는 또 노티파이 안에서 “지금 발차기하려 하는가?”를 판단해야 하고, 노티파이 안에서 발차기 이벤트에 대응하는 처리를 해야 한다……

이렇게 오래 가다 보면, 곧 대량의 로직이 고작 왼발/오른발 노티파이 하나 안에 밀집하게 된다. 원래는 각자의 상태 머신 안에 분산되어 처리될 수 있던 것들이 모두 이 노티파이 안에 결합되어버리는 것이다. 이후 그중 어느 하나를 수정하거나 새로운 기능을 추가하려면 전부 이 노티파이를 건드려야 한다…… 이는 개방-폐쇄 원칙을 위반한다. 여기까지 들으면 디자인 패턴을 배운 독자는 이미 혈압이 올라갔을 것이다. 그래서 이것이 필자가 애니메이션 노티파이보다 애니메이션 커브를 사용하는 것이 더 좋다고 생각하는 이유다.

【2】착지 애니메이션이 왜 로컬 스페이스 Additive가 아니라 메시 스페이스 Additive 애니메이션을 사용하는가에 관하여:

이 그림은 UE5 문서에서 온 것이다. 볼 수 있듯, 로컬 스페이스 Additive 애니메이션을 사용하면, 더해지는 애니메이션은 더해지기 전의 골격 위치에 영향을 받는다. 반면 메시 스페이스 Additive 애니메이션은 이 영향을 무시할 수 있다. 여기서 필자 개인적으로 추측하건대, ALSV4는 캐릭터가 언제나 수직으로 일어서게 만들고 싶었기 때문에 메시 스페이스 Additive 애니메이션을 사용한 것이다.

2.3 백척간두에서 한 걸음 더 나아가기

이 소절에서는 명백한 단점을 극복하려는 것이 아니라, 새로운 장점 하나를 추가하려 한다. 바로 착지 예측이다.

이 문제는 캐릭터가 착지할 때 애니메이션을 “체공 애니메이션”에서 착지 애니메이션으로 순간적으로 블렌드해야 한다는 데서 온다. 만약 애니메이션이 세심하게 설계되어, 착지 애니메이션 자체가 체공 애니메이션의 마지막 프레임에서 착지 동작으로 자연스럽게 전환되도록 만들어져 있다면, 사실 이 절은 큰 쓸모가 없다. (UE의 3인칭 템플릿이 바로 이렇게 한다. 체공 애니메이션 마지막 프레임과 착지 애니메이션 첫 프레임이 완전히 같다.)

하지만 착지 애니메이션과 체공 애니메이션의 연결이 아트의 손을 거쳐 자연스럽게 만들어져 있지 않다면, 극히 짧은 착지 과정에서 애니메이션 블렌드 시간이 너무 짧아 여러 가지 부자연스러움이 쉽게 나타난다. 이 문제를 개선하기 위해 우리는 하나의 가능성을 제안한다. “착지하기 1초 전부터 미리 착지 포즈 쪽으로 블렌드할 수는 없을까?”

그렇다. 공중에서 미리 블렌드하는 것이다. 이것은 착지 시 블렌드 시간이 너무 짧은 문제를 해결한다. “착지 전 1초”가 언제인지를 알기 위해 우리가 해야 하는 것이 바로 착지 예측이다.

그 사고방식은 대략 이렇다.

캐릭터의 현재 캡슐 위치에, 캐릭터의 현재 속도를 더해, 캐릭터의 캡슐이 다음 1초에 이동할 가능성이 있는 위치를 계산한다. 그 위치에 캡슐을 하나 그려 충돌 결과를 검사한다. 만약 그려진 캡슐과 충돌한 것이 걸을 수 있는 지면이라면, 캐릭터가 다음 1초 안에 그 위치에 착지한다는 뜻이다.

동시에 이 착지 예측은 매 프레임마다 한 번씩 계산되므로, 이전 프레임에 그린 캡슐은 막 지면에 닿았을 뿐인데, 뒤의 몇 프레임에서는 이미 땅속에 묻혀 있을 수 있다. 캡슐이 땅속에 더 많이 묻힐수록 현재 캐릭터가 지면에 더 가까워졌다는 뜻이다. 따라서 우리는 캡슐이 흙 속에 묻힌 부피의 비율을 체공 애니메이션과 착지 애니메이션 첫 프레임의 블렌드 값으로 사용할 수 있다.

캡슐 그리기

캡슐 그리기

충돌 결과로부터 “흙에 묻힌 비율”을 얻고, 그 결과를 그대로 출력 블렌드 값으로 삼아도 된다. ALSV4가 마스크와 커브 매핑을 한 번 더 추가한 것은 더 부드럽고 안전하게 만들기 위해서일 뿐이다.

계산 결과를 얻은 뒤에는, 점프 상태 머신과 착지 애니메이션 첫 프레임을 이 값으로 블렌드하면 된다.

맺음말(필자의 관례적인 잡담을 뜻함)

이 사람은 어느 정도로 게으르냐면? 글을 쓸 때마다 시작과 맺음말조차 새로 쓰기 귀찮아하는 수준이다…… 살짝만 바꿔서 또 가져다 쓰는 것이다 www

지난번 ALSV4 제자리 회전 편 업데이트로부터 이미 1개월 16일이 지났다. 매달 부지런히 글을 업데이트하던 나로서는, 최근 한 달 넘게 게으름을 피워 글을 안 올렸는데도 知乎의 팔로우와 조회수가 나를 놀라게 할 속도로 오르고 있어서(조금 더, 더 세게!) 정말 부끄러워 몸 둘 바를 모르겠다 = =. 그래서 방학이 되어 매일 크게 늘어지고만 싶었지만, 필자는 데드셀을 하거나 애니를 보며 빈둥대고 싶은 충동을 참고 이 글을 업데이트했다.

다음 글은 ALSV4의 발 IK를 업데이트할 계획이다. (지난번에도 이렇게 말하긴 했지만…… 하지만 계획은 변화보다 빠를 수 없으니까! 응! 맞다, 바로 그런 것이다!) 또한 IK를 다 이야기한 뒤에는 등반 시스템도 한번 이야기할 생각이다.

아, 여름방학이라니…… 내 인생의 마지막 여름방학이다……! 3학년 여름방학에는 인턴을 가야 하고, 4학년에는 여름방학이 없다. 눈앞의 2학년 여름방학이 바로 내 마지막 좋은 날이다…… 빈둥대고 싶지만 완전히 빈둥댈 수도 없다. ALSV4 글도 아직 다 업데이트하지 못했고, 알고리즘 문제도 풀어야 한다…… 지금의 나는 빈둥댄 상태와 빈둥대지 않은 상태의 양자 중첩 상태에 있다. 사랑하는 어머니께서 내 방문을 여는 순간, 관찰자가 생기므로 “너 또 게임하니”와 “열심히 공부하고 있구나” 두 상태 중 하나로 붕괴될 것이다.

마지막은 좋아요 구걸 시간이다! 여기까지 봤다면, 설령 이 글이 비루하고 얕다고 느껴지더라도, 필자가 글 쓰느라 고생했다는 점을 생각해 좋아요 하나만 누르고 가주면 좋겠다. 부탁이다 ≥﹏≤

(요 며칠 컴퓨터 메인보드가 타버렸다…… 새 컴퓨터가 언제 올지도 모르겠다. 새 글은 아마 좀 더 기다려야 할 것 같다.

레노버 샤오신 사지 마라……)

PS: 덧붙여 여기서 필자가 막 만든 UE 골격 애니메이션 교류방을 살짝 광고한다. 916274600 각위 대佬들의 매서운 지적을 환영합니다.

---

원문
(76 封私信 / 32 条消息) UE4 UE5 骨骼动画 高级运动系统 跳跃 - 知乎