[📚정보] Unreal Engine: Motion Matching, UAF

[pluto(mayor1980)]

Motion Blending

모션 블렌딩은 데이터 기반 애니메이션의 가장 고전적이고 기본적인 해결책입니다. 이름 그대로, 두 개 이상의 애니메이션 클립을 '혼합(Blend)'하여 그 사이의 중간 포즈를 만들어내는 기술입니다.

1. 정확한 작동 방식

애니메이션은 결국 '시간에 따른 뼈(Bone)의 트랜스폼(위치, 회전, 스케일) 값'입니다.

모션 블렌딩은 두 애니메이션 클립(A, B)의 '동일한 뼈'에 대해 '가중 평균(Weighted Average)'을 계산합니다.

- 예시: "걷기(Walk)" 클립과 "달리기(Run)" 클립을 50%씩 블렌딩한다면,

    -  최종 어깨 회전 = (걷기 어깨 회전 * 0.5) + (달리기 어깨 회전 * 0.5)

    -  최종 다리 위치 = (걷기 다리 위치 * 0.5) + (달리기 다리 위치 * 0.5)

    -  이 계산을 모든 뼈에 대해 매 프레임 수행합니다.

2. 언리얼 엔진에서의 구현

언리얼에서 모션 블렌딩은 애니메이션 블루프린트(AnimBP)의 심장과도 같습니다.

- 블렌드 스페이스 (Blend Space):

    가장 대표적인 구현체입니다. 2D 그리드(격자)에 여러 애니메이션을 배치하고, 두 개의 입력 값(예: 속도와 방향)에 따라 주변 애니메이션들을 실시간으로 블렌딩합니다.

    - Y축에 속도 (0 = Idle, 200 = Walk, 600 = Run)

    - X축에 방향 (-180 = 뒤, -90 = 왼, 0 = 앞, 90 = 오)

    - 플레이어가 '대각선 앞(방향 45)으로 천천히 뛸(속도 400)' 때, 블렌드 스페이스는 "Walk_Fwd", "Run_Fwd", "Walk_Right", "Run_Right" 4개의 애니메이션을 적절한 비율로 섞어 "대각선 앞 조깅"이라는, 존재하지 않던 애니메이션을 실시간으로 생성합니다.

- 기타 블렌드 노드: Blend Poses by bool, Blend Poses by int 등 상태 변경 시(예: IsFalling? true로 변경) 지정된 시간(예: 0.2초) 동안 부드럽게 한 포즈에서 다른 포즈로 블렌딩합니다.

3. 모션 블렌딩의 한계점

블렌딩은 간단하고 강력하지만, 두 가지 고질적인 문제가 있습니다.

1.  발 미끄러짐 (Foot Sliding): "달리기"와 "멈추기"처럼 발의 속도나 위치가 전혀 다른 두 애니메이션을 섞으면, 발이 땅에 고정되지 못하고 바닥을 스케이트처럼 미끄러지는 현상이 발생합니다.

2.  '흐리멍덩한' 움직임 (Mushy/Generic Poses): 블렌딩은 'A와 B의 중간'을 만들 뿐, '새로운 C'를 만들지 못합니다. "A 공격"과 "B 공격"을 섞으면 강력한 "C 공격"이 나오는 게 아니라, 이도 저도 아닌 힘 빠진 '흐리멍덩한' 동작이 나옵니다.

3.  '상태 기계 지옥' (State Machine Hell): 애니메이터가 모든 전환 규칙을 수동으로 정의해야 합니다. (Idle -> Walk, Walk -> Run, Run -> Stop, Run -> Jump, Idle -> Jump...). 애니메이션이 수백 개가 되면 이 '상태 기계(State Machine)'는 누구도 관리할 수 없는 스파게티 괴물이 됩니다.

Motion Matching

1. 모션 매칭의 해결 방안

모션 매칭은 모션 블렌딩의 '상태 기계 지옥'과 '발 미끄러짐' 문제를 정면으로 돌파하기 위해 고안된, 훨씬 진보된 데이터 기반 기술입니다.

핵심 아이디어:

"블렌딩(평균값)을 하지 말자. 상태 기계도 만들지 말자. 대신, 방대한 모션 데이터베이스를 매 프레임 초고속으로 검색하자. 그리고 지금 내 캐릭터의 '현재 포즈'와 플레이어가 '미래에 가고자 하는 방향' 이 두 가지 조건에 가장 잘 '일치(Match)'하는 '실제(Real)' 애니메이션 프레임을 찾아서, 그 지점부터 즉시 재생하자."

이 방식은 애니메이터가 수동으로 '전환(Transition)' 규칙을 만드는 대신, 시스템이 '검색(Search)'을 통해 최적의 전환을 스스로 찾아내게 만듭니다.

2. 정확한 작동 원리

모션 매칭은 크게 (1)데이터 준비(Bake) 단계와 (2)런타임(Search) 단계로 나뉩니다.

(a) 데이터 준비 (Bake Time - '데이터베이스' 구축)

1.  모션 데이터 준비: "Idle_to_Run", "Run_Stop"처럼 잘게 자른 클립이 아니라, 배우가 몇 분 동안 자유롭게 뛰고, 멈추고, 돌고, 걷는 등의 길고 연속적인(Continuous) 모션 데이터를 대량으로 준비합니다. (예: 30분 분량의 달리기/걷기/방향전환 모션)

2,  '특징 벡터 (Feature Vector)' 추출: 데이터베이스의 *모든* 프레임(수백만 개)에 대해 일종의 '인덱스(Index)' 또는 '꼬리표'를 만듭니다. 이 꼬리표가 바로 '특징 벡터'이며, 현재 프레임의 '상태'를 요약합니다.

3.  특징 벡터 구성: 이 벡터에는 "현재 포즈"와 "미래 궤적" 정보가 모두 포함됩니다.

    - 현재 포즈 (Current Pose):

        - 양쪽 발의 루트(골반) 기준 상대 위치 및 속도

        - 양쪽 손의 루트 기준 상대 위치 및 속도 (선택 사항)

        - 루트(골반)의 속도 (Velocity) 및 각속도 (Angular Velocity)

    - 미래 궤적 (Future Trajectory):

        - "이 프레임부터 애니메이션을 계속 재생한다면, 0.5초 뒤, 1.0초 뒤, 1.5초 뒤에 캐릭터의 루트가 어디에 있을 것인가?"에 대한 2D (X, Y) 좌표 및 방향.

이제 데이터베이스의 모든 프레임은 (현재 발 위치, 현재 손 속도, ..., 1.5초 뒤 미래 위치)라는 고유한 '특징 벡터' 꼬리표를 갖게 되며, 이는 K-d tree 같은 자료구조로 인덱싱되어 초고속 검색이 가능하도록 준비됩니다.

(a) 런타임 (Real-Time - '검색과 선택')

매 프레임마다 다음 과정이 실시간으로 반복됩니다.

1)  요청 생성 (Player Input):

    - 플레이어가 컨트롤러 스틱을 '왼쪽 45도'로 '최대'로 기울입니다.

    - 시스템은 이 입력을 바탕으로 "플레이어가 원하는 미래 궤적 (Desired Trajectory)"을 생성합니다. (예: "앞으로 1초 뒤 5미터, 왼쪽 45도 방향")

2)  현재 상태 생성 (Current Character):

    - 캐릭터의 '현재 포즈 특징 벡터'를 계산합니다. (현재 발 위치, 속도 등)

3)  Chooser를 통한 DB 선택 (Database Selection):

    - 캐릭터가 할 수 있는 모든 동작(걷기, 달리기, 전투, 수영, 등반...)을 단 하나의 거대한 데이터베이스에 넣고 검색하는 것은 매우 비효율적입니다.

    - 'Chooser(선택자)'는 현재 캐릭터의 '상태 태그(Tag)'나 '게임플레이 이벤트'에 따라 검색할 데이터베이스 자체를 동적으로 선택하는 상위 시스템입니다.

   - 작동 예시:

        - 플레이어가 그냥 이동 중 -> 'Locomotion_DB'를 검색하라.

        - 플레이어가 "전투 자세" 버튼을 누름 -> 'Combat_Locomotion_DB' (무기를 들고 옆걸음질 치는 모션이 포함된 DB)를 검색하라.

        - 플레이어가 "회피" 버튼을 누름 -> 'Dodge_DB' (회피 모션만 모아둔 DB)를 검색하라.

    - 이 'Chooser' 단계 덕분에, 시스템은 '전투 자세'에서 '회피'를 검색하는 등의 엉뚱한 검색을 하지 않고, 현재 상황에 맞는 가장 적절한 모션 풀(Pool) 안에서만 검색을 수행하여 효율과 정확성을 높입니다.

4)  검색 및 비용 계산 (Search & Cost Function):

    - Chooser에 의해 선택된 DB(예: Locomotion_DB) 안에서, 시스템이 수십만 개의 프레임 꼬리표(특징 벡터)를 초고속으로 검색하며 "가장 저렴한(Best)" 프레임을 찾습니다.

    - 비용(Cost) =

         A  (현재 캐릭터의 발 위치 - DB 프레임의 발 위치)

         + B (현재 캐릭터의 속도 - DB 프레임의 속도)

         + C (플레이어가 원하는 미래 궤적 - DB 프레임의 미래 궤적)

    - 여기서 A, B, C는 가중치입니다. '미래 궤적(C)'에 가장 높은 가중치를 두어 플레이어의 입력(가고 싶은 방향)에 가장 잘 반응하도록 설정합니다.

5)  최적 프레임으로 '점프' (Jump):

    - 이 '비용'이 가장 낮은(가장 일치하는) 프레임을 데이터베이스에서 찾습니다.

    - 예: "Run_and_Turn" 클립의 1245 프레임이 가장 저렴하다고 판단됨.

    - 시스템은 즉시 현재 재생 중인 애니메이션을 버리고, "Run_and_Turn" 클립의 1245 프레임부터 재생을 시작합니다.

6)  스티칭 및 블렌딩 (Stitching & Blending):

    - 아무리 '비용이 낮은' 프레임을 찾았다고 해도, 현재 프레임(A)과 새로 찾은 프레임(B)이 100% 동일할 수는 없습니다.

    - 이 '점프'를 하는 순간, 미세한 포즈의 차이로 인해 캐릭터가 뚝 끊기는 '팝(Pop)' 현상이 발생할 수 있습니다.

    - '스티칭(Stitching)'은 이 '팝' 현상을 숨기기 위해, 점프가 일어나는 그 순간에 매우 짧은 시간(예: 0.1초 ~ 0.2초) 동안 '관성 기반 블렌드(Inertial Blend)'를 수행하는 것을 의미합니다.

    - 이전 애니메이션(A)의 관성(속도, 각속도)을 새로운 애니메이션(B)으로 부드럽게 넘겨주는 것입니다.

    - 중요: 모션 매칭은 이미 비용 계산을 통해 '가장 비슷한' 포즈를 찾았기 때문에, 이 블렌딩은 모션 블렌딩의 '흐리멍덩한' 블렌드와 달리 거의 눈에 띄지 않으면서 두 클립을 매끄럽게 '꿰매줍니다(Stitch)'.

3. 언리얼 엔진에서의 구현

언리얼 5는 '모션 매칭(Motion Matching)' 플러그인을 정식으로 지원하며, 이는 Lyra 샘플 프로젝트에서 핵심적으로 사용됩니다.

- Motion Matching Database 애셋에 모션 데이터를 베이크(Bake) 합니다.

- Chooser Table 애셋을 만들어 "전투 중", "이동 중" 같은 게임 플레이 태그(Tag)에 따라 어떤 DB를 사용할지 정의합니다.

- 애니메이션 블루프린트에서 거대한 State Machine 대신, 이 Motion Matching 노드와 Chooser 노드를 연결하여 훨씬 단순하고 반응성이 뛰어난 로직을 구현합니다.

4. 모션 매칭의 한계점

a)  데이터 의존성 (Data Hungry): 모션 매칭은 '발견'할 뿐, '창조'하지 못합니다. 만약 DB에 "2.5미터 점프" 모션이 없다면, 캐릭터는 절대 2.5미터를 뛸 수 없습니다. (2.3m나 2.7m 모션을 찾아 재생할 뿐)

b)  정확한 상호작용의 한계: "정확히 1.2미터 높이의 담벼락"을 넘거나, "정확히 내 앞 2.3미터 지점의 적"을 칼로 찌르는 것은 불가능합니다. DB에 모든 거리와 모든 높이의 모션을 넣을 수는 없기 때문입니다.

Motion Warping

1. 모션 워핑의 해결 방안

모션 워핑(Motion Warping)은 '일반적인' 모션 클립 하나를 가져와서, '시간과 공간을 왜곡(Warp)'시켜 '특정 목표 지점'에 정확하게 맞추는 기술입니다.

핵심 아이디어:

"애니메이션 클립 자체는 그대로 두되, 애니메이션의 루트 모션(Root Motion) 속도와 재생 시간(Play Rate)을 동적으로 조절하여, 애니메이션의 '핵심 부분(예: 손 짚기, 발 착지)'이 내가 원하는 목표 지점(Target)에 정확히 도달하도록 만들자."

2. 루트 모션 워핑 (Root Motion Warping / Space Warping)

"애니메이션의 '속도(Play Rate)'는 그대로 둔 채, '이동 거리(Root Motion)'만 늘리거나 줄여서 정확한 '위치'에 도달하게 만드는 기술"입니다.

이것이 '모션 워핑'이라고 할 때 가장 일반적으로 사용되는 방식입니다.

(a) 자주 쓰이는 케이스 (목표: 위치 동기화)

- 볼팅 (Vaulting) / 담벼락 넘기: 1.0m 폭의 담벼락이든 1.2m 폭의 담벼락이든, *단 하나의* 담벼락 넘기 애니메이션으로 정확히 손을 짚고 정확히 반대편에 착지해야 할 때.

- 절벽/선반 잡기 (Ledge Grabbing): 점프 높이가 살짝 모자라거나 넘칠 때, 손을 절벽 끝에 정확히 '붙여주며' 매달리는 동작.

- 근접 전투 (Finishing Moves, Takedowns): 내 캐릭터와 적 캐릭터가 2.0m 떨어져 있든 2.5m 떨어져 있든, "마무리 일격" 버튼을 누르면 부드럽게 거리를 조절하며 달려가 정확한 위치에서 찌르기 모션이 실행되어야 할 때.

(b) 정확한 작동 방식

1)  목표 지점 설정 (Warp Target):

    - 게임 로직(예: 레이 캐스트)이 넘어가야 할 담벼락의 시작과 끝 위치를 감지하여 '워프 타겟'으로 설정합니다.

2)  동기화 지점 설정 (Sync Point):

    - 애니메이터가 '담벼락 넘기' 애니메이션 몽타주(Montage) 내부에 '동기화 지점(Notify)'을 미리 심어둡니다.

    - 예: Warp_Start (손을 짚기 직전), Warp_Land (착지하는 프레임).

3)  워핑 (Warping) 실행:

    - 플레이어가 담벼락 앞에서 '넘기' 버튼을 누릅니다.

    - 모션 워핑 컴포넌트가 "현재 내 위치"와 "목표 지점(Warp_Start)" 사이의 실제 거리를 계산합니다.

    - 이 '실제 거리'와 애니메이션에 저장된 '원본 루트 모션 거리'를 비교합니다.

4)  결과:

    - Case 1: 목표가 원본보다 더 멀 때 (예: 원본 2.0m vs 실제 2.2m)

        - 시스템은 애니메이션의 루트 모션 스케일을 1.1배로 늘립니다. (2.2 / 2.0 = 1.1)

        - 캐릭터는 애니메이션 재생 시간(예: 1초) 동안 *더 빠른 속도로* 움직여 2.2m를 이동합니다.

        - 애니메이션 자체의 '재생 속도(Play Rate)'는 1.0x로 유지됩니다. 손을 짚는 동작은 정상 속도지만, 그 동작을 수행하는 몸의 이동(루트 모션)만 빨라집니다.

    - Case 2: 목표가 원본보다 더 가까울 때 (예: 원본 2.0m vs 실제 1.8m)

        - 시스템은 애니메이션의 루트 모션 스케일을 0.9배로 줄입니다. (1.8 / 2.0 = 0.9)

        - 캐릭터는 같은 1초 동안 더 느린 속도로 움직여 1.8m만 이동합니다.

        - 마찬가지로, 애니메이션의 '재생 속도'는 1.0x입니다.

이처럼 공간(Space)을 왜곡시켜, 애니메이션 클립의 '동작'은 유지하되 '이동 거리'만 목표에 정확히 맞춥니다.

3. 타임 워핑 (Time Warping)

"애니메이션의 '이동 거리(Root Motion)'는 무시하고, '재생 속도(Play Rate)' 자체를 빠르게 또는 느리게 조절하여, 특정 프레임이 정확한 '순간'에 재생되도록 맞추는 기술"입니다.

이 방식은 '위치'가 아니라 '타이밍'이 중요할 때 사용됩니다.

(a) 자주 쓰이는 케이스 (목표: 시간 동기화)

- 패링 / 카운터 공격 (Counter):

    - 적의 공격이 0.4초 뒤에 나에게 닿을 예정입니다.

    - 내 '패링' 애니메이션의 '방어 성공' 프레임은 0.5초(30프레임)에 있습니다.

    - 이대로라면 0.1초 늦게 방어해서 공격을 맞게 됩니다.

    - 타임 워핑이 작동하여, '패링' 애니메이션의 재생 속도를 1.25배로 높입니다. (0.5 / 0.4 = 1.25)

    - 그 결과, 내 '방어 성공' 프레임이 정확히 0.4초 뒤에 재생되어 적의 공격을 완벽하게 막아냅니다.

- 잡기 (Grabs): 적에게 잡기 기술을 시도할 때, 적이 살짝 회피하는 모션(0.6초)을 재생했습니다. 내 잡기 애니메이션의 '손이 닿는' 프레임(0.5초)을 적의 회피가 끝나는 0.6초에 정확히 맞추기 위해, 내 애니메이션 속도를 0.83배로 *느리게* 워핑하여 타이밍을 맞출 수 있습니다.

- 협동 상호작용 (Co-op Interaction): 두 플레이어가 동시에 버튼을 누르거나 악수하는 애니메이션을 재생할 때, 두 사람의 애니메이션 시작 시간이 달라도 '손이 맞닿는' 프레임을 동일한 순간에 재생되도록 재생 속도를 조절합니다.

(b) 정확한 작동 방식

1)  목표 시간 설정 (Warp Target Time): 게임 로직이 '이벤트가 발생해야 하는 정확한 시간' (예: 0.4초 뒤)을 계산합니다.

2)  동기화 지점 설정 (Sync Point): 애니메이터가 몽타주에 '핵심 이벤트 프레임' (예: 패링 성공 프레임)을 마킹합니다. 이 프레임의 원본 시간(예: 0.5초)을 시스템이 알고 있습니다.

3)  워핑 (Warping) 실행: 시스템이 '목표 시간'(0.4초)과 '원본 시간'(0.5초)의 차이를 계산합니다.

4)  결과: 애니메이션 전체의 재생 속도(Play Rate)를 '원본 시간 / 목표 시간' (0.5 / 0.4 = 1.25배)로 변경하여 몽타주를 재생합니다.

4. 언리얼 엔진에서의 구현

- 캐릭터 블루프린트에 Motion Warping Component를 추가합니다.

- 애니메이션 몽타주(Montage)에  Add Motion Warp Window 노티파이를 추가하고, Warp Target Name (예: "VaultTarget")을 지정합니다.

- 루트 모션 워핑 (Space):

    - 캐릭터 BP에서 담벼락 위치를 계산한 뒤, AddOrUpdateWarpTargetFromLocation 노드를 호출하여 "VaultTarget"이라는 이름으로 해당 위치 좌표를 등록합니다.

    - 이후 몽타주를 재생하면, 컴포넌트가 알아서 해당 노티파이 구간에서 등록된 "VaultTarget" 위치로 루트 모션을 왜곡합니다.

- 타임 워핑 (Time):

    - AddOrUpdateWarpTargetFromLocation 대신, AddOrUpdateWarpTargetFromProvider 등을 사용하고 특정 타이밍 계산 로직을 바인딩하여 구현할 수 있습니다. (다소 더 복잡한 설정이 필요)

Unreal Animation Framework (UAF)

1. 기존 기술(워핑, 매칭)의 한계점

모션 매칭과 모션 워핑은 한 캐릭터가 환경이나 목표 지점과 상호작용(담벼락 넘기, 적에게 접근하기)하는 데는 탁월했습니다. 하지만 움직이는 다른 캐릭터와 픽셀 단위로 정확하게 상호작용하는 것은 거의 불가능했습니다.

- 문제 (Takedown / 잡기 기술):

    1.  시작 위치 문제: 플레이어가 적 뒤에서 '잡기'를 시도합니다. 모션 워핑을 사용해 플레이어가 적의 등 뒤 특정 좌표까지는 접근할 수 있습니다.

    2.  동기화 문제: 하지만 플레이어가 잡는 순간, 적 또한 '잡히는' 애니메이션을 정확히 같은 타이밍에 재생해야 합니다.

    3.  '분리' 문제: 가장 심각한 문제입니다. 플레이어는 '잡기' 몽타주(루트 모션 포함)를, 적은 '잡히는' 몽타주(루트 모션 포함)를 각자 재생합니다. 두 애니메이션은 원래 하나의 세트로 제작되었지만, 미세한 오차나 물리 충돌, 지형의 작은 단차로 인해 두 캐릭터가 분리되거나(Drift Apart), 한 명이 땅에 묻히거나, 손이 어깨를 뚫는(Clipping) 현상이 발생합니다.

- 핵심 한계: 두 개(이상)의 독립적인 스켈레탈 메시 액터가 애니메이션이 재생되는 내내 완벽하게 동기화된 상태를 유지할 방법이 없었습니다.

2. UAF의 해결 방안

UAF는 이 문제를 해결하기 위해 "상호작용이 시작되면, 두 캐릭터를 일시적으로 하나의 유닛(Unit)처럼 묶어버리자"라는 아이디어를 제시합니다.

이는 단일 노드가 아니라, 모션 워핑, 컨트롤 릭(IK), 동적 부착(Attachment) 기술을 유기적으로 결합한 '구현 방식의 약속(Framework)'입니다.

핵심은 상호작용에 참여하는 캐릭터들에게 '역할(Role)'을 부여하는 것입니다.

- 주도자 (Lead): 상호작용을 시작하고 전체 움직임을 이끄는 캐릭터 (예: 잡기를 시도하는 플레이어)

- 추종자 (Follower): 상호작용에 반응하는 캐릭터 (예: 잡히는 적)

3. 정확한 작동 방식

"플레이어(주도자)가 적(추종자)을 뒤에서 잡아 넘어뜨린다"는 상호작용은 UAF에서 다음과 같은 4단계로 작동합니다.

a) 접근 (Approach) - (모션 워핑)

- 플레이어가 '잡기' 버튼을 누릅니다.

- 시스템은 적의 위치를 Warp Target으로 설정합니다.

- 플레이어는 모션 워핑(Motion Warping)을 사용해 '잡기 준비' 애니메이션을 재생하며 적의 등 뒤로 정확하게 접근합니다. (여기까지는 이전 단계와 동일)

b) 체결 (Engage) - (동적 부착 및 역할 할당)

- 플레이어의 모션이 적에게 닿는 '동기화 지점(Sync Point)'에 도달합니다.

- UAF의 핵심입니다:

    1.  역할 할당: 플레이어는 주도자(Lead), 적은 추종자(Follower) 역할을 부여받습니다.

    2.  동적 부착 (Dynamic Attachment): 추종자(적)를 주도자(플레이어)의 특정 본(Bone)이나 소켓에 일시적으로 부착(Attach)시킵니다.

    3.  루트 모션 제어권 이양:

        - 주도자(플레이어)는 '잡기' 애니메이션 몽타주를 재생합니다. 이 몽타주에는 두 캐릭터가 함께 넘어지는 전체 루트 모션(Root Motion)이 포함되어 있습니다.

        - 추종자(적)는 '잡히는' 애니메이션 몽타주를 재생합니다. 단, 이 몽타주의 루트 모션은 0이거나 완전히 무시됩니다.

- 결과: 이제 적은 자신의 루트 모션으로 움직이는 것이 아니라, 플레이어에게 '부착'된 상태로 플레이어의 루트 모션을 그대로 따라가게 됩니다. 두 캐릭터는 물리적으로 분리될 수 없는 하나의 애니메이션 유닛이 됩니다.

c) 포즈 보정 (Pose Correction) - (IK / 컨트롤 릭)

- 이제 두 캐릭터는 찰싹 붙어서 함께 움직이지만, 사소한 문제가 남아있습니다. 적이 플레이어보다 키가 크거나 작으면 어떻게 될까요?

- 플레이어의 '잡는 손'은 허공을 짚거나, 적의 어깨를 파고들(Clipping) 것입니다.

- 작동 방식:

    1.  주도자(플레이어)의 애니메이션 블루프린트에서, 컨트롤 릭(Control Rig)이나 IK 노드가 실시간으로 작동합니다.

    2.  플레이어의 왼손 컨트롤러가 추종자(적)의 어깨 소켓 위치를 실시간으로 추적(Targeting)하도록 설정합니다.

    3.  적의 키가 크면 플레이어의 손이 IK에 의해 원본 애니메이션보다 더 위로 올라가 어깨를 짚고, 키가 작으면 손이 더 내려옵니다.

- 결과: 두 캐릭터가 함께 움직일 뿐만 아니라, 실시간 IK 보정을 통해 서로 다른 체형이나 미세한 위치 차이에도 불구하고 손과 몸이 항상 정확하게 맞닿은 상태를 유지합니다. (이를 애니메이션 워핑(Animation Warping) 또는 포즈 워핑이라고도 부릅니다.)

d) 해제 (Disengage)

- '잡기' 애니메이션 몽타주가 끝나는 지점에 도달합니다.

- 추종자(적)와 주도자(플레이어) 간의 동적 부착(Attachment)을 해제합니다.

- 두 캐릭터는 UAF 상태를 벗어나, 다시 각자의 일반적인 애니메이션 로직(예: 모션 매칭)으로 돌아가 '일어나는' 애니메이션 등을 재생합니다.

4. 요약

UAF는 모션 워핑으로 상호작용을 시작하고, 동적 부착과 루트 모션 제어권 이양(주도자/추종자)으로 두 캐릭터를 하나로 묶어 동기화 문제를 해결하며, 실시간 IK/컨트롤 릭으로 포즈를 보정하여 클리핑 문제를 해결하는, 다수 캐릭터 상호작용을 위한 완벽한 '종합 프레임워크'입니다.

참고문헌

https://youtu.be/tNw9lD2PW3U?si=c_tW3xK05liafnZX

https://youtu.be/FLDXtAV7qsw?si=TMJccKy4R-8lWbjY

https://youtu.be/MIhnv29csSQ?si=Se4TcCh9M6mTadKA

https://youtu.be/kO6pz8ADgcU?si=D3miaEjIakrHTGcA

https://youtu.be/v4slYkeuJmg?si=0Qfwmysc-bfathPm

도움이 되셨다면 개발 중인 게임 프로젝트의 유투브 채널 구독 부탁드립니다..

https://www.youtube.com/@goatzawal

goatzawal

개발일지 및 언리얼 튜토리얼 위주로 올릴 예정입니다.

[아침빵(lobster7304)]

[아침빵(lobster7304)]

UAF는 ㄹㅇ 혁신이네

[pluto(mayor1980)]

@아침빵 발표 영상 봐도 큰거 왔다는 식으로 말하더라고요ㅋㅋ

[Indie 1(218.209)]

좋은 글 감사 근데 패링말이야 보통 소울라이크에서 정확한 프레임 구간을 정하는게 일반적이지않음? 패링 프레임을 조작하기도하나? - dc App

[pluto(mayor1980)]

패링이 성공하는 시간 구간 도중 누르면 적의 공격이 닿는 순간에 맞춰 패링이 되는 상황을 말하는 것 같아요. 다크소울은 워낙 패링이 타이밍도 짧고 쿨타임이 길어 체감이 안되는 것 같은데, 소울라이크에서 약간 벗어난 세키로, 고오쓰, 스블같은 경우는 패링 성공 구간이 더 넓은 것 같고요. 정확한건 저도 구현해보면서 알아가야겠네요

[211214(tomatoss)]

[pluto(mayor1980)]

[무장농부(weight5377)]

캬 정보추

[pluto(mayor1980)]

[익명(220.84)]

와 개추 - dc App

[pluto(mayor1980)]