치킨 날다

오늘은 마우스 이동으로 방향 전환 시 캐릭터가 같이 회전하지 않는 이슈.

그리고 이동 시 간단한 애니메이션 적용을 해보았습니다.

캐릭터 회전 이슈는 SpringArm의 Rotator 값을 Controller의 값을 사용하도록 하다 보니 마우스를 돌릴 때 캐릭터가 아니라 SpringArm만 회전을 하는 것이었습니다.

이 부분은 옵션을 제거해 놓은 상태입니다.

또한 이 과정에서 캐릭터를 90도 회전한 뒤 이동하면 이동 방향이 꼬이는 문제가 있었는데, 이는 Controller의 FrontVector를 사용해서 생긴 문제로 ArrowComponent의 것을 사용하는 것으로 수정했습니다.

마지막으로 Animation은 적용해 보았는데 루트모션이 비정상 동작을 하였습니다.

이것저거서 만지다가 아래 블로그를 통해 원인을 파악했습니다.

https://devjino.tistory.com/277

원인은 Animation Retarget할 때 root 항목과 옵션을 누락했기 때문이고, 튜토리얼에는 이 항목이 없다고 하네요.

결국 이를 수정하기 위해서는 Animation Retarget을 다시 해야 하는데, 이전처럼 노가다를 하나하나 할 생각은 없습니다.

그냥 Unreal Engine 5.x 버전에 호환된 애셋들을 Ctrl CV를 하여 본 프로젝트에 옮겨두고, ignore로 push가 안되게 한 뒤 본 프로젝트 안에서 Animation Retarget을 진행하고자 합니다.

내일 광복절이라 회사에 가지 않으니 오후에 시간이 되면 이 작업을 진행할 예정입니다.

추가로 시점 변환 등의 작업을 진행해보니 생각보다 고도화 해야 할 사항이 많다는 것을 깨달았습니다.

그래서 AOS 모드 개발을 무기한 연기하고, 코드 리펙토링을 거친 뒤 기능 추가를 하면서 고도화 작업을 진행 할 예정입니다.

1.1) 3인칭-1인칭 토글 기능 (주말 전까지 개발)

1.2) 이동 애니메이션 추가 (22.08.14 - cont)

1.3) 이동 함수를 Controller로 이동(1.6)과 통합)

1.4) 이동 방향에 따라 하체 애니메이션 방향 정확히 매칭되도록 보정

1.5) 울퉁불퉁하거나 언덕, 절벽에서 발이 공중에 붕 뜨지 않도록 보정

1.6) 코드 리팩토링(1.이동 기능을 Controller로 이동)

1.7) 추가 기능 구상 및 고도화

2. AOS 모드 개발(충분한 기능이 개발되기 전까지 무기한 연기)

Tab 버튼을 눌러서 FPP-TPP를 변경하는 기능을 구현했습니다.

생각보다 뭐랄까..... 별거 없이 싸보이는데 기능이 군더더기 없는? 깔끔하게 잘 나와서 놀랐습니다.

다만 이전과 비교해 카메라 위치나 방향이 뭔가 낯설고 바뀐 느낌이 들더군요.

그래서 옵션을 좀 조정해서 원래 생각하는 방식으로 복구가 되는지 확인을 해보고, 주말에 애니메이션을 간단하게 넣어볼 생각입니다.

이후 Controller로 InputComponent에 Bind 하는 기능을 분리해보려 합니다.

이유는 Controller에서 입력이 들어가면 실제 동작 함수를 Character에 있는 것들로 취사선택하는 편이 좀 더 구조적으로 좋을것 같기 때문입니다.

이 외에 근래에 직장 동료로부터 언리얼 공부를 할 수 있는 좋은 영상 자료를 추천 받았기에 어느정도 개발을 하면서 시간이 되면 결재해서 영상으로 따로 공부를 할 예정입니다.

1.1) 3인칭-1인칭 토글 기능 (주말 전까지 개발)

1.2) 이동 애니메이션 추가

1.3) 이동 함수를 Controller로 이동(NEW)

1.4) 이동 방향에 따라 하체 애니메이션 방향 정확히 매칭되도록 보정

1.5) 울퉁불퉁하거나 언덕, 절벽에서 발이 공중에 붕 뜨지 않도록 보정

1.6) 코드 리팩토링

2. AOS 모드 개발

일주일만에 잡은 것 같은데 애석하게도 오늘은 입문서를 보면서 캐릭터의 키 입력과 입력 시 이동하는 부분만 구현을 했습니다.

이 뒤에 애니메이션 부분을 연속으로 구현을 해볼까 하는데 입문서에 시점 변경 기능이 있어서 살짝 고민을 하다가 입문서를 따라 구현을 먼저 해보고자 이 정도에서 멈췄습니다.

목표는 주말이 되기 전에 조금씩 개발해서 Tab 키를 누르면 3인칭 1인칭이 바뀌는 기능을 구현해보고자 합니다.

이후 이동에 대한 애니메이션을 구현하되, 좌우 대각선에 따라 하체 애니메이션이 정확하게 나오고, 언덕진 곳에서는 발이 붕 뜨지 않는 것까지 구현을 해볼 예정입니다.

이정도까지 구현이 되면 이후에는 코드를 개선할 계획입니다.

기능이나 확장성을 고민해봐서 함수 위치 등을 조절해볼 생각입니다.

예를 들어, 현재는 Character에서 Input Bind를 했습니다.

이 방식은 각 Character 별로 Input이 다를 때 유효한 방법일 것입니다.

하지만 입문서에서는 Controller에서 Bind 하는 방법도 있었습니다.

이 방식은 어느 Character든 Input이 다르지 않거나, 모든 Character에 동일하게 적용되는 로직이 있을 때 유효할 것입니다.

이런 부분을 정리하고 나면 점프, 숙이기, 공격 모션 등 여러 기능들을 구현하고 마스터에 머지를 할 예정입니다.

마스터에 머지를 한 뒤에는 AOS 모드를 간략하게 만들어보고자 합니다.

계획을 정리하면 다음과 같습니다.

1.1) 3인칭-1인칭 토글 기능 (주말 전까지 개발)

1.2) 이동 애니메이션 추가

1.3) 이동 방향에 따라 하체 애니메이션 방향 정확히 매칭되도록 보정

1.4) 울퉁불퉁하거나 언덕, 절벽에서 발이 공중에 붕 뜨지 않도록 보정

1.5) 코드 리팩토링

2. AOS 모드 개발

정작 작업은 30일에 했는데 일지를 완전 새까맣게 잊고 있다가 31일 저녁에서야 일지를 적어봅니다.

일지 적고 일주일 정도 게임모드와 RPC 관련해서 문서를 읽었습니다.

함수 콜이 어떤 순서로 되는지는 대략적으로 눈에 넣었는데 정작 카메라를 어떻게 지정하고 어떻게 붙는지는 파악이 안되더라구요.

결국 코드를 다시 읽어야 하나 고민하고 있던게 저번주 금요일(22일)이었습니다.

23일에 운동을 할까 하다까 몸이 좀 안좋아 그냥 던지고 쉬었는데 일요일에 열이 확 오르더라구요.

그렇습니다. 코로나였습니다.

코로나 이후에는 크게 코드에 손을 못댄 것 같습니다.

일요일은 한참 열이 올라 누워 있었고 이후에는 일이 바쁘게 움직여서 문서만 깨작깨작 봤습니다.

그러다 토요일 즈음에 약을 다 먹고 정상 생활 궤도로 재진입 하기 위해 코드를 다시 보았고, 별로 좋아하지는 않지만 에라 모르겠다는 심정으로 입문서를 보고 따라 만들어봤습니다.

이 과정에서 Level에 다 만들어놓은 Mode를 지정하지 않아서 캐릭터 카메라가 제대로 동작 안한다는 것을 깨달았습니다.

Mode 지정 하니까 T자 캐릭터가 스폰이 되고 카메라도 지정한 위치에서 보이더라구요.

일단 여기까지 작업을 했습니다.

이 뒤에는 결국 Mode 구조가 문제가 아니라는 것을 알았으니 Input 작업을 시작해서 상하좌우 이동을 만들고, 그 다음 대쉬와 점프를 넣어볼 예정입니다.

여기까지 하면 그 뒤에는 애니메이션을 보면서 추가 기능을 구현하고, 상호작용 넣으면서 다채로운 캐릭터 이동을 먼저 만들어놓을 계획입니다.

작업사항부터 정리를 하자면

1. 더미 프로젝트에 있는 캐릭터, 애니메이션을 본 프로젝트에 이식
2. 예시로 RPG 캐릭터 개발을 먼저 하기 위해 관련 GameMode, GameState, PlayerController, Character, PlayerState, AnimInistance 생성 및 연결.
3. 세션 구조 공부 선행 예정

이렇게 됩니다.

우선 에셋 이식.

이게 정말 개 거지같은 작업이었습니다.

이전에 언급 했듯이 UE5의 Animation Retarget은 IK 리타겟과 IK 릭을 이용해야만 합니다.

한 프로젝트 내에서는 이 방식이 문제가 없었는데 다른 프로젝트로 애셋을 복붙해서 열어보니 경로가 바뀌어 Skeletal Mesh를 찾지 못하였습니다.

여기서 아주 큰 문제가 발생을 하는데, 외부에서 옵션을 통해 Skeletal Mesh를 새로 지정하는 방법이 없습니다.

Animation을 하나하나 열어서 대체 Skeletal Mesh를 지정해야 합니다.

그리고 저는 OpenWorldAnimSet이 있었고 이게 한 2, 300개 정도 Animation을 지원합니다.

모든 Animation을 다 합치면 도합 400개가 될 것 같네요.

이걸 3시간에 걸쳐 하나하나 열어서 대체 Skeletal Mesh를 지정하였습니다.

다시는 하고 싶지 않네요.

작업을 다 하고 혹시 다른 프로젝트의 IK 릭과 리타겟을 사용할 수 있는지 확인했으나 경로가 지원되지 않았습니다.

꼼짝없이 수기작업을 할 수밖에 없었던거죠.

개인적으로 최선은 범위를 지정해서 대체 Skeletal Mesh를 지정하는 옵션이 추가가 되는 것입니다.

하지만 그렇지 못하다면, 프로젝트에 에셋을 직접 연결해서 사용하는 것을 추천드립니다.

단, 이 방법은 제가 이전에 구상했던 GitHub로 관리하는 Repository 구조로는 대응이 안됩니다.

이 점은 기억하시기 바랍니다.

애니메이션을 연결한 뒤에 실제로 동작을 하는지 AnimInstance를 생성해서 하나의 Animation을 지정하고, Mode 등을 지정해서 재생 됨을 확인했습니다.

이 시기에 한가지 중요한 사실을 깨달았습니다.

AnimInstance 작업을 하더라도 GameMode 작업을 하지 않으면 카메라 조절이나 조작을 못한다는 점이었습니다.

그래서 GameMode쪽 공부를 먼저 선행하고자 합니다.

GameMode와 GameState가 어떻게 동작하는지.

PlayerController와 Character, PlayerState가 어떻게 동작하는지.

GameSession은 무엇인지.

이런 것들에 대한 개념을 확립해서 정리를 하고, 기본 기능을 구현한 뒤 Animation 기능 구현을 할 예정입니다.

물론 RPC를 사용해 Dedicate Server-Client 구조까지 염두를 하고자 합니다.

시간이 오래 거릴 것 같은데 이걸 해야 나중에 재작업을 하거나 관련 작업을 할 때 더 좋은 구조를 구상할 수 있을 것 같습니다.

어제 1개의 애셋을 Retarget 세팅 한것에 이어 오늘은 5개를 추가로 Retarget을 하고, 모든 애니메이션을 Export했습니다.

다만 본 프로젝트에 복사해오니까 스켈레탈과 텍스쳐를 찾지 못해서 삭제후 좀 더 확인해볼 예정입니다.

주말에는 처리하고 그 뒤에는 Animation FSM 공부를 할 차례겠군요.

이전에도 짬짬히 했는데 일지 쓰는걸 까먹고 있다가 오늘 몰아서 써봅니다.

저번에 Animation Retarget을 하겠다고 했는데 UE5는 UE4보다 더 복잡스럽네요.

지금 참고해서 보고 있는 블로그입니다.

https://devjino.tistory.com/276?category=1020908 

UE4에서는 스켈레탈 우클릭 해서 옵션 지정하고 설정해서 쭉 긁으면 되던 것에 UE5에서는 IK Rig를 만들고 이걸 Retargeter로 엮어서 옵션 설정을 하고 난 뒤에야 Export가 되네요.

이 방식이 한번 처리하면 이후에 동일 스켈레탈에 대해 애니메이션이 추가되면 이를 관리하기에는 매우 용이한 구조인 것 같습니다.

다만 그 처음 한번이 너무 복잡스럽네요.

특히 Retarget Loop를 자동으로 설정할 수 없고 하나 하나 범위와 이름을 지정해서 해야 합니다.

자동으로 해주는게 없어요.

위 블로그에서는 파츠별로 나누어서 처리를 했지만 만약 부위별로 세세하게 들어가거나 파츠가 많다면 작업량이 어마무시하게 되겠죠.

물론 전 지금 여러 에셋의 애니메이션을 하나로 묶느라 Rig와 Retargeter가 애셋 갯수만큼 생겨버려서 더 작업량도 그에 비례하게 늘어난 편입니다.

그래도 이것저것 비교해보면 별로 달가운 작업은 아니었습니다.

그래서 하나 하다가 짜증나서 다시 껐습니다.

그래도 최소한의 작업량을 파악해서 한 한시간 정도 집중하면 정리는 될 것 같습니다.

이 뒤에는 이제 애니메이션 구조를 잘 고민해야할텐데 예전에 Rocomotion과 특정 상황 모션(사다리 타기, 사망, 공격, 피격 등등)을 분리하는 구조를 추천 받았는데 성능이나 관리 측면에서 매우 좋은 구조를 알아보는데 시간을 크게 할애하고 시작해야 할 것 같습니다.

이전에도 대략 이 시점에서 멈췄는데 부디 이번에는 제 자신이 멈추지 않았으면 합니다.

개발하다 날리고 개발하다 날리다가 다시 시작을 했습니다.

목적은 예전과 비슷합니다.

게임플레이(코어 컨텐츠) 개발을 지향하고 기회가 된다면 엔진 코드 수정을 적극적으로 병행 할 예정입니다.

그러기 위해 상당시간 프로젝트 구조 잡는데 시간을 들였고, 정상 진행이 가능한 수준의 프로젝트를 생성할 수 있었습니다.

https://redchiken.tistory.com/311

다만 오늘 찾은 문제는 기존의 언리얼 엔진 에셋을 바로 사용할 수는 없더군요.

그래서 더미 프로젝트를 따로 만들어서 해당 프로젝트에 에셋을 적용했습니다.

다음 작업은 더미 프로젝트에서 적용된 여러 애니메이션 에셋들을 하나의 스켈레탈로 리타겟팅 할 예정입니다.

메쉬나 머테리얼은 최대한 줄이고 애니메이션이나 포즈는 최대한 챙겨서 파일명 정리하고 본 프로젝트에 옮겨오고자 합니다.

그 뒤에는 이전처럼 키 입력 기반으로 애니메이션 하나씩 넣고, 히트박스 포르노 급으로 콜리젼 작업을 진행해볼 예정입니다.

어제 Monatge를 상속으로 처리를 시도해보겠다고 했는데 Montage를 상속으로 처리하니까 Animation 재생 시간이 부모의 것에 고정이 되었습니다.

이를 맞추느니 그냥 새 Montage를 만드는게 좋겠다 싶어서 이전에 만들어 놓은 Montage를 다 따로 분리해놓았습니다.

이렇게 해놓으니 다시 몇가지 고민이 생겼습니다.

하나는 이동 애니메이션이 중간에 멈췄을 때 매끄럽지 못할 수 있다는 점.

다른 하나는 방향 전환 시 대처가 될지 감이 안잡힌다는 점입니다.

그래서 결국 예전 방식으로 회귀를 해야 할 것 같습니다.

상하좌우 이동 관련된 애니메이션을 만든 뒤 캐릭터 키 바인드와 카메라 조절을 넣어서 테스트 환경을 먼저 조성.

이후 IK랑 에임 오프셋 등을 고려하면서 동작을 늘려가는 방향으로 조절했습니다.

한가지 더.

프로젝트에 적용 된 애니메이션 중 Generic NPC Anim Pack은 실제 동작에 활용 가능한 것이 매우 적어서 일부 필요한 Anim Sequence만 가져다 쓰고 실질적으로 내부 구현은 하지 않을 예정입니다.

마찬가지로 Death Animation도 전체를 사용하기 보다는 필요한 것만 가져다가 3개 이상을 사용할 예정입니다.

이 외에는 겹치는 것을 제외하고는 최대한 모두 활용을 하고자 합니다.

애니메이션 작업을 하기 앞서 한가지 고민이 있었습니다.

캐릭터가 정상적으로 움직이게 하는 것을 먼저 할 것인가?

아니면 애니메이션을 먼저 만들것인가 입니다.

캐릭터를 움직이게 만드는 것은 코드를 다 까먹어서 하기 힘들지만 해놓으면 테스트가 용이했습니다.

반대로 애니메이션을 만드는 것은 땅 짚고 헤엄치는 식으로 가능하지만 마지막에 테스트를 위해 해야 하는 코드 과정이 더 길고 복잡합니다.

하지만 결국 후자를 선택했습니다.

그 이유는 2가지입니다.

첫번째로, 기본 모션을 만들고 작업해도 결국 추가 작업이 필요할 것 같다는 점.

두번째로, 제가 생각보다 의지가 약해 어려운 작업을 먼저 하다보면 안하게 된다는 것입니다.

그래서 오늘은 Animation Sequence를 Montage로 엮어보았습니다.

작업을 전부 완료한 것은 아니고, 간단한 것들부터 진행해 보았는데 생각보다 까다로웠습니다.

일단 제 기억상 몽타주를 여러개 쓰고 이걸 스위치로 가르는 것보다 Montage 하나를 공유하는 것이 더 낫다고 기억합니다.

그런데 동일한 카테고리의 Animation을 하나의 Montage로 엮다 보니 Section도 맞지 않고, 끝나는 시간도 맞지가 않았습니다.

현재는 이전에 작성한 글을 통해 몽타주를 상속 처리해서 좀 쪼개는 방법을 구상하고 있습니다.

https://redchiken.tistory.com/276

예를 들어, 걷는 Montage가 있다면 그 구조는 동일하더라도 세부적인 부분에서 실제 애니메이션이 갈라져서 다른 Child Montage를 호출할 수 있도록 하는 것입니다.

솔직히 이게 좋은 방안인지 잘 모르겠습니다.

아직 몽타주만 작업하는 단계이기도 하니까요.

그래도 지금 작성하면서 생각해보니 이 악물고 몽타주 줄이는 것보다 구조를 개선해서 다른 사람들이 알아보기 쉽게 명확히 하는 것이 미래의 나와의 협업 측면에서 더 나은 방안일 것 같습니다.

이제 이렇게 되면 남은 궁금증은 하나입니다.

Section을 쓰지 않는 동일한 카테고리의 단일 애니메이션을 어떻게 구현하느냐 입니다.

예전의 저 같으면 FSM에서 Switch로 다 때려박았을 겁니다.

하지만 몽타주에서 같은 카테고리를 공유한다고 하니 하나의 몽타주에 Slot을 나눠서 넣어서 구현하는 것이 떠오릅니다.

근데 사망 애니메이션 길이기 다르다 보니 이게 실제로 어떻게 처리될지 감이 안잡히더라구요.

일단 Unreal Forum에 질문글을 올려두긴 했습니다.

https://forums.unrealengine.com/t/questions-about-performance-of-montage/499673

미리 답을 알면 좋겠지만 그렇지 않는다면 코드 작업을 하면서 다시 한번 대격변이 일어나겠죠.

입사 전 실력으로도 좀 빠듯한 작업인데 이 파트는 그때보다 실력이 떨어져서 여러모로 힘에 부칩니다.