2.28

닐리의 잡기에 들어가기 전에 중요한 사실을 하나 깨달았다. 지금까지는 잡기 세트를 만들 때 캐릭터의 방향을 반대로 놓고 만들었는데, 링크로 가져온 캐릭터는 게임오브젝트처럼 스케일을 반전시켜도 애니메이션이 깨지지 않는다! 그러므로 캐릭터의 방향을 맞춰서 애니메이션을 만들면 좀 더 나은 품질의 애니메이션을 제작할 수 있다.

하지만 이걸 하려면 기존의 애니메이션을 모두 반전시켜야 한다. 조금 귀찮다… 그래도 해 보자.

반전은 키가 있는 프레임을 돌며 ctrl+c -> ctrl+shift+v를 누르면 된다. 이 때 새로운 키가 생기는 걸 원치 않으니 Replace로 조절해준다.

물론 코드를 조금 수정해주어야 한다. 성공이다! 이제 매우 깔끔하게 일어난다.

닐리는 처음엔 예상에 없었던 선생님 이미지가 나왔으니 강손 잡기는 궁디팡팡! 잡은 후에 여러번 때리는 형태로서, 상대가 버튼을 마구 누르면 좀 빠르게 벗어날 수 있다. 달심의 꿀밤때리기나 브랑카의 깨물기 형태의 잡기다. 이를 위해서 잡기는 기본, Loop, End. 총 3가지로 세분화되어야 한다.

코드는 나중의 일이다. 일단 애니메이션을 만들자.

그동안 때렸으니 이제 좀 맞자. 앨리스.

둘 다 무기는 다 어디 갔나…싶지만, 뭣이 중헌디?! 애니메이션 제작 도중 로브에 컬러가 튀는 건 … 왜 그럴까… 내일 심층분석을 해봐야겠다. 오늘은 여기까지.

2.29

닐리의 로브가 튀는 현상은 본이 엉켜있었던 것이 원인으로 파악됐다. 일단은 다행스러운 일.

오늘의 깨달음. 루프 애니메이션을 도입부와 이어지게 만들고 별도의 파일로 분리해낼 때엔 키를 복붙하기보단 액션전체를 카피한 후 중간키를 삭제하는 편이 낫다. 0프레임에는 트랜스폼 이외의 키들이 생각보다 많이 설정되어 있기 때문이다.(회전모드나 제약조건의 영향력 등)

엔드 모션은 테스트가 좀 필요해서 넣어보려니 문제가 많다. 스테이트 매니저를 공용으로 옮기고, 발생했던 버그를 잡고, 그 외에도 한참 리팩토링… 마음이 급해도 코드는 최대한 차근차근 진행해야 나중에 일이 적다.

오늘의 깨달음 2. FSM을 처음 시작할 때 LateUpdate()가 왜 있는지 알게 됐고, 스테이트 처리를 하면서 Awake()가 왜 있는지도 알게 됐다. Start()에서 마땅히 있어야 할 정보가 없을 때, 그리고 그 순서가 ‘얘 다음’이라고 장담할 수 없을 때 미리 만들어둘 확실한 절차가 필요한 것이다.

코드작업을 마무리하지 못했다. 현재는 잡기 관련 코드를 FSM에서 처리하고 있는데, 이걸 게임매니저로 옮겨야 한다. 오늘은 여기까지.

3.1

잡기 코드를 게임매니저로 옮겼다가 다시 개별캐릭터로 가져왔다. 상대방의 FSM을 조작하는 건 월권이라 생각해서 게임매니저로 옮기려고 했던 건데 괜한 삽질이었다. 달리 생각하면 애초에 잡기 자체가 상대방을 조작하는 것인지라 이 쪽에서 처리하는 게 맞는 것 같기도 하고…결국은 눈물의 롤백. 시간만 날렸다.

어쨌거나 코드는 완성됐다. 남은 것은 상대가 발버둥을 치면 좀 더 일찍 잡기가 풀려야 하는 것인데, 2P입력을 아직 안만들었다(…) 뭐, 중요한 것은 아니니 나중에 실제 데미지 처리 하면서 함께 풀도록 하자.

이제 애니메이션 디테일작업에 들어가야 하지만 타임오버. 오늘은 여기까지.

3.2

익스포트한 데이터는 완벽하지 않다. 이는 게임 엔진이 제약조건 기반으로 움직이는 것이 아니라 베이킹된 키에 의해 움직이기 때문이다.(다리가 땅에 붙지 않고 덜덜 떨리는 것을 볼 수 있다.)

이에 대해 프로젝트에 블렌더를 사용하고 있는 지인과 이야기를 했었는데, 키프레임 압축률에 의해 애니메이션이 깨지고 있다는 결론을 얻었다! 처음엔 ARP의 익스포트 문제일거라 생각했는데 내보낸 FBX를 블렌더로 임포트해본 결과, 데이터는 아무런 문제가 없었다. 이럴 수가! 유니티의 최적화 문제였다니.

키프레임 리덕션을 하고 회전 오차를 기본값인 0.5에서 0.1로 줄여주었더니

발이 정상적으로 땅에 붙어 작동한다. 이것이 최적화에 얼마나 악영향을 끼칠 지는 모르겠지만, 적어도 문제를 해결할 방법을 찾았다는 점이 고무적이다.

문제 2번. 잡기를 한 캐릭터를 반대편으로 던져보낼 경우 캐릭터가 반전된다. 이 경우 무기를 쥔 손이 반전되기 때문에 임시로 차일드를 왼손에서 오른손으로 변경해줄 필요가 있다. 제약 조건 중에 Child Of를 양손에 걸고 Influence에 키를 주면 될 것이다. 그런데 이것이… 안된다. 차일드 오브가 2개 이상될 경우 프레임 지연현상이 일어난다.

테스트 결과, 이것이 렌더링을 할 때는 문제가 없다. 제약 조건이 여러 개일 경우, 실시간 뷰포트의 연산을 줄이기 위해 이런 선택을 한 것으로 보인다. 이것이 실시간 익스포트를 할 경우 문제가 된다. 이건 일전에 목이 달랑거리는 현상과 비슷한 문제로 보이는데, 결국 메모리의 문제로 결론이 났었고

단순한 구조로 테스트를 해본 결과는 정상인 것으로 보아, 그 가설에 더욱 힘이 실리는 분위기이다. 그렇다면 이건 답이 없다…별 수 없이 그냥 매프레임 노가다를 해주는 수밖엔. 데이터가 너무 무거운 모양이다.

하지만 삽질은 결국 도움이 되는 무언가를 남긴다. 이 오차를 해결할 수 없을까?싶어 옵션을 뒤지던 중에 애니메이션 오토키프레이밍에서 ‘Only Insert Needed’란 옵션을 발견했다. 이 옵션은 트랜스폼 3대장에 모두 키를 주지 않고 움직인 트랜스폼에 대해서만 키를 준다. 이동과 회전값의 키 이격은 매우 흔하게 발생하므로 이 옵션은 상당히 유용하다. 소득은 있었다!

발 잡기(→K). 윙가르디움 레비오사!

아.쓰다보니 Only Insert Needed가 별로 안편하다[…] 왜 기본값이 꺼져있는지 이해하게 되었다.

닐리의 잡기도 완료!