[카테고리:] 배틀퀸(BattleQueen)

1.9

검기가 필요하다! 프레임이 너무 빨라 트레일은 부적합하고 예쁘지도 않다. 메쉬로 만들자. 그리고 이를 위한 셰이더도 만들자.

uv를 풀러서 v에 사인을 적당히 비벼서 만들었다. flow수치를 따로 빼내어 애니메이션 할 것이다.

입컨트롤러 아래에 검기전용 컨트롤러를 만들었다.. 검기는 평면이므로 본을 만든 후, Z스케일에 드라이브시키면 될 것이다. 스케일은 0이 되면 안되니까, 드라이브 수치는 var + 0.01로 해야 한다.

완성됐다. 이제 모션에 붙여보자.

계획대로 잘 움직이는 것 같다. 이제 유니티로 넘기자.

??? 내가 뭘 잘못한 걸까…

조사해 보니 드라이버를 사용하는 트레일 메쉬의 모델스케일이 0.01로 되어 있었다. 팩터를 스케일에 매핑하고 있으므로 이것은 곧 밝기가 된다. 즉 100배 조도로 작동하고 있었다.

이제 잘 작동한다. 그런데 스샷이 무슨 개그만화처럼 찍혔어!?

1.10

며칠전에 발생했던 목덜렁현상이 재발했다. 이번엔 위치의 오프셋대신 회전값의 로테이션이 문제다. 이번에는 전처럼 본이 32개를 기준으로 오류현상이 발생하지 않고 30개쯤에서 발생한다. 메모리 문제가 맞는가…

컨트롤러를 버려보기로 한다. ARP는 머리를 컨트롤러로 제어하고 있다. 이걸 직접제어로 바꾼다.

• 아마추어 32번레이어에 있는 head.x의 회전락을 푼다. 함께 설정되어 있던 Copy Rotation도 삭제한다.
• 제어가 쉽도록 1번레이어로 옮기자.

디폼과 컨트롤러가 분리되어 있지 않은 케이스는 이미 존재한다. 손가락이다. 익스포트만 문제가 없다면, 이대로 사용해도 될 것이다.

잘 넘어오는 것 같다.

하지만 기존의 head.x는 컨트롤러에 의해 제어되고 있었기 때문에, 애니메이션이 모두 초기화되었다. 이는 fcurve를 복사해 붙여주거나, 다시 잡아주어야 한다. fcurve를 수동으로 복사해주자.

스탠딩 어택은 가까울 때와 멀리 떨어져 있을 때 모션이 다르게 나타난다. 오늘까지 이걸 처리했다. 내일은 제발 기술적 이슈가 없기를. 흑흑

1.11

오늘의 깨달음.

쿼터니온값의 부호를 바꾸면 360도 돌아간 값으로 새겨진다. 이는 캐릭터가 한바퀴를 도는 애니메이션을 제작할 때, 처음과 끝을 같은 모양으로 맞춘 애니메이션을 제작할 때 용이하다.

이제 앉아서 공격들을 만든다.

익스포트 후.. 내가 뭘 또 잘못한거지..

조사 결과, 스케일이 모두 음수값으로 익스포트되고 있었다. 이것이 블렌더의 문제인지, 아니면 유니티의 문제인지, 혹은 ARP의 문제인지 불분명하다. 이것에 대해선 내일 조사해보기로 하자.

1.12

스케일이 모두 음수값으로 익스포트 되는 것은 ARP의 문제로 밝혀졌다. 심화단계로 가니 FBX 익스포트에 소소한 버그들이 발견된다. 제작자에게 메일을 보낼까 하다가 스샷찍고 파일정리할 게 귀찮아 그냥 고쳐쓰기로 했다. 검기의 x축을 뒤집어 쓰고 싶은 것뿐이니 그냥 180도 돌리면 된다.

하지만 검기가 항시 표현되고 있는 것이 생각보다 작업을 많이 방해하는 느낌이다. 클립해서 보이지는 않으나 GPU란 놈은 계산을 모두 끝낸 후에 버리는 비효율적인 짓꺼리 또한 할 것 같으니 그냥 계산면적을 줄여주는 편이 좋겠다. 애드온 기능이 또 필요하다.

• 액션 초기화 시 본에 trail이 붙은 본의 트랜스폼을 초기화해주고 스케일을 0.01로 줄여준다. (0은 안된다.)
• 모든 액션에 같은 행동을 해야 한다.

이를 위해 모든 액션에 필수키를 추가하는 버튼을 만들었다. 이 버튼은 주요관절에 로테이트 모드를 고정하고 트레일이 붙은 본은 초기화해서 0프레임에 트랜스폼 키를 넣는다. 이 과정을 통해 키가 없는 액션의 데이터가 엉망이 되는 경우를 방지할 수 있다. 테스트 해보자.

본의 이름을 변경할 일이 있었다. 블렌더에서는 이름으로 데이터를 찾기 때문에 이름이 바뀌면 액션의 데이터 호환이 안된다. 즉, 데이터는 있는데 모션이 깨진다. 이를 위해 스크립트를 제작해야 했다.

본의 이름을 변경했을 때, 애니메이션이 깨지는 현상을 교정

이제 문제 없다. 그런데 사소한 문제가 하나 더 있다. 모션이 안예뻐…

자세를 좀 더 낮게 수정. 이 쪽이 더 마음에 든다. 내일은 기술이슈가 없기를(…)

1.13

이 게임을 만들면서 격투게임의 제자리 점프 공격과 앞으로(혹은 뒤로)점프 공격의 모션이 다르다는 걸 처음 알았다. 생각보다 굉장히 많은 공이 들어간다.

검기의 회전값이 작동하지 않는 현상이 있었다. 원인은 모르겠지만, 회전모드를 오일러로 바꿔서 한 번 돌린 후에, 다시 쿼터니온으로 바꾸면 잘 작동한다. 일단 블렌더를 업데이트 했지만 여전히 발생하는 버그. 검색해도 같은 문제의 사례가 발견되지 않는 걸로 봐서 아마도 표시는 쿼터니온으로 되어 있으나 계산은 오일러로 되고 있는 상황같아 보인다. 왜 이런 현상이 발생하는 거지…

졸지에 블렌더만 업데이트한 셈이 됐다.

아하. 4.0에선 레이어 방식이 변했다. 이제 레이어는 얼마든지 추가할 수 있고 이름도 지정할 수 있다. 좋은 개선이다.

업데이트 후 페이셜 키 중 찡그린 눈썹의 키가 작동되지 않는 현상이 있었다.

어쩐지 저게 자물쇠가 걸려 있다. 이걸 해제해주면 된다. 이것이 4.0으로 오면서 데이터가 포팅된 것인지, 아니면 그냥 단순히 원래 있던 내 실수였는지는 모르겠다. 후자라면 좋겠다.

공격 모션은 대략 완성했다. 이제 데미지 모션을 처리해야 한다.

데미지 모션을 제작하다 알아낸 사실. 모든 모션에 페이셜 키를 0프레임에 추가해주어야 한다. 기존에 짜놓았던 코드가 있어서 어렵지 않게 해결. 내일은 데미지 모션을 만들어보자.

1.4

타이밍은 대충 맞췄다. 애니메이션 심화학습단계로 진입하자. 블렌더를 사용한지는 2년이 넘었지만, 사실 맥스에서 블렌더로 넘어오기 가장 힘들었던 부분이 바로 이 애니메이션 부분이다. 바이패드와 ARP는 시스템이 매우 다르다. (처음엔 Rigify를 사용했지만, 시스템이 다르기는 마찬가지다.)

블렌더의 애니메이션 시스템 중 가장 힘들었던 점은 팔다리의 제어다. 바이패드는 FK/IK구분 없이 움직임은 무조건 IK기준으로 제어할 수 있다는 장점이 있다. 툴에 익숙해지기만 한다면 이것은 상당한 장점이 된다. 작업이 빠르다. 하지만 다른 툴로 전향하고자 한다면 이것은 도리어 약점이 된다. FK/IK 적응이 상당히 힘들다. 팔다리 움직임의 중요성이야 말할 것도 없는데, 이것이 불편하다면 블렌더가 좋게 생각되겠는가?

하지만 돌아갈 수 없다. 컴퓨터를 새로 바꾼 후에 맥스는 깔지도 않았다. 그렇게 작정하고 덤비니 …오. 바이패드보다 좋은 점도 상당히 많아 보인다. 뭐, 이제 시작이긴 하지만 역시 사람은 적응의 동물이다. 확실하다. 맥스의 시대는 갔다.

익스포트한 데이터의 목이 달랑거리는 문제가 있다. 이걸 해결해야 한다.

1.5

처음엔 머리가 달랑거리는 원인으로 제약조건이 잘못설정되어 있을 것으로 생각했다. 난 기본값을 건든 기억이 없지만, 작업을 하다보면 나도 모르는 새에 무언가를 건드리기 마련이다. 하지만 기본값은 모두 깨끗했다. 도무지 원인을 파악할 수 없어 빙챗에게 물어봤는데 역시 뾰족한 해결책을 내려주지는 않았다.

하지만 AI와의 대담(?)중 메모리 부족이 아닐까요? 하는 이야기에 실험을 해보기로 했다. 그런데 놀랍게도 그게 맞다! 머리카락 본을 모두 지우고 익스포트를 하게 되면 머리가 달랑거리는 현상은 일어나지 않았다. 그러고보니 이전에 대규모씬을 작업할 때에도 머리가 항상 한템포 늦게 따라오는 현상이 있었다. 메모리?! 캐릭터가 하나밖에 없는데 메모리라고?! 데이터가 크긴 크구나.

익스포트하자고 머리카락을 지울 수는 없는 노릇이다. 상상도 못한 정체에 약간 멘붕이 온다. 이번 문제는 주관식이다. 어떻게 할까. 좀 더 정밀한 테스트를 진행해보니 머리에 연결된 본이 32개 이상이면 딜레이 현상이 발생한다. 딱 32에서 걸리는 걸 보면 메모리 문제가 아닐 것 같다는 생각도 든다. 애드온 코드를 살펴보니 저세상 난이도이다.어..으..

물리적으로 해결해보기로 했다. 머리가 달랑거릴 여지를 주지 않도록 본의 부모를 바꾸도록 하자.

• head.x 의 부모를 c_head.x → neck.x로 변경한다.
• 그런데 이러면 머리가 컨트롤러를 안따라가니까 head.x가 컨트롤러를 따라가도록 Rotation_Copy(World)를 준다.

해결했다. 목에 완전히 Connect해버렸기 때문에 이제 목을 늘이는 처리가 안된다. 전혀 상관없지. 스키비 토일렛이라도 만들지 않는 이상은.

오늘의 깨달음. 키 사이에 얇은 줄이 그어져 있는 경우는, 프로퍼티의 값에 애니메이션이 들어가 있을 경우를 뜻한다.

앞으로 걷기. 오늘은 여기까지

1.6

앞으로 점프. 앨리스는 큰 차이가 없지만, 스피드형 캐릭터는 공중제비등으로 차이를 줄 수 있다.

이 쯤에서 한 번 익스포트해서 느낌을 보자.

1.7

어셋브라우저의 블렌드 포즈는 정말 편하다.

오늘의 깨달음.

쿼터니온과 오일러는 정해진 답이 없다. 그냥 모션마다 유리한 방식이 있으니 그에 맞춰서 키를 주자.

짠손 파파파파파파팟

강손

킥

게임에 넣어봤더니 타이밍이 영 마음에 들지 않는다. 기획상 강펀치와 킥은 캐릭터마다 어느 것이 더 강한지에 대한 근소한 차이는 있지만 기본적으로 같다고 가정하고 제작하고 있다. 때문에 딜레이가 꽤 길어도 괜찮다고 생각했지만 정작 유니티에 넣어보니 중요모션은 10프레임 이내에 끝나야 자연스럽다. 짠손은 겨우 4프레임이다!

게다가 강손은 점프강손과 이미지가 너무 겹치는 감이 있다. 다시 만들어야 할 것 같다. 하지만 오늘은 타임오버. 내일 다시 제작해보자.

1.8

앨리스의 강베기 변경. 이 동작은 검기가 없으면 조금 빈약해 보인다.

쿼터니온과 오일러가 생각보다 많은 충돌을 일으킨다. 작업을 하다보니 중요관절에 오일러를 사용하는 경우는 생각보다 드물다. 그렇다고 또 모든 관절을 쿼터니온으로 바꾸자니 일이 커진다.

오퍼레이터가 필요하다.

그래서 만든 액션 초기화. 이 버튼의 기능은 새로운 액션을 추가하고 페이크유저로 바꾼 후, 중요관절에 현재 있는 그대로의 로테이션 모드 키를 넣어준다.코드자체는 chatGPT가 짜주니까 어렵지 않았는데, 몇가지 이유로 fcurve의 group이 지정되지 않는 문제가 있어서 이 원인을 찾느라 시간이 한참 걸렸다.

결국은 이거 하나밖에 못했다. 내일은 검기를 달아보자.

12.29

타이밍을 재기 위한 러프 애니메이션 작업. 좋은 조작감을 위해서는 프레임이 생각보다도 더 적어야 한다는 결론을 얻었다.

턴동작 튀는 것은 왜 그런지 모르겠는데… 이론상 안그래야 하는데…

• JumpReady는 2프레임
• Crouch/Stand도 2프레임
• Landing은 Crouch로 캔슬되어야 한다.
• 상대방 너머로 점프했을 때 Landing -> Idle -> Turn의 상태를 거친다. Idle은 스킵되어야 한다.

실제 리소스를 적용하고 나니 점프높이가 너무 높아보여서 수정했다. 앨리스는 갑옷을 입었으니 조금 무거운 느낌의 점프를 주고 싶었던 것도 있으나 기본 점프높이가 너무 높아서 점프 시 얼굴을 가리는 현상이 마음에 들지 않았던 것이다.

이제 최고 높이에서도 얼굴을 가리지는 않는다.하지만 실제 완성본이라면 HP바가 가릴 예정.

상대방 너머로 점프했을 때 Landing -> Idle -> Turn의 상태를 거치는 문제는 Play()의 호출시기 문제였다. 여러가지 이유로 지금까지는 Play()를 LateUpdate()에서 호출하고 있었는데, 이 때문에 애니메이션이 1프레임 느리게 나와서 정보가 제대로 되었음에도 불구하고 한 프레임이 튀는 현상이 발생했던 것이다.

Landing 후 Crouch스킵은 보호프레임이 설정되어 있었다. 보호프레임은 타격이 일어나기 전에 애니메이션의 재생시간을 보장하기 위해 넣은 시스템이다. 데미지등의 강력한 외부요인이 없는 한 보호되게끔 코딩해 놓았다. 착지모션에 이걸 왜 넣어놨지…?

12.30

발차기모션을 만들던 도중 마스터의 회전이 불완전하게 움직이는 현상이 있어 이를 쿼터니온으로 변경했다. 그랬더니 각종 모션이 깨지는 현상이 발생

게다가 손의 IK-FK스위칭에서도 문제가 일어난다. 이는 키를 주지 않은 기능에 대해서는 기본값을 유지하는 블렌더 시스템의 특징때문이다. 작업에 앞서 규칙을 확실히 정하는 편이 좋겠다.

12.31

블렌더는 기본적으로 애니메이션을 위한 툴이기 때문에 모든 액션은 NLA에디터에 자동으로 삽입된다. 여기서 새로운 액션을 만들 경우, 반드시 Push Down으로 NLA에 등록을 해주어야 한다. 그렇지 않을 경우, 블렌더는 이 클립을 미사용클립으로 인지하고 가비지 컬렉터에 의해 다음 로딩 시 제거당한다. 영원히 지워진다는 이야기이다. 이를 피하려면 액션에 Fake-user를 켜주어야 한다.

저 방패모양이 fake-user. 가비지 컬렉터로부터 지킨다는 의미다. 블렌더에서 user는 데이터를 사용하는 주체를 말한다. 예를 들어 머티리얼 데이터는 모델링에서 사용된다. 3D데이터는 유기적으로 연결되어 있기 때문에, 이런 데이터 블럭들은 여기저기 쓰인다. fake-user는 말그대로 ‘쓰고 있는 주체가 있는 것처럼 간주해라.’라는 뜻이다. 그럼 가비지 컬렉터로부터 보호된다. 초보 시절엔 이 시스템을 이해못해서 하루종일 잡은 키를 날린 적도 있다. 이런 걸 보면 블렌더는 최적화에 신경을 굉장히 많이 쓰는 것을 알 수 있는데, 애니메이션은 좀 수정됐으면 좋겠다. 데이터가 큰 것도 아니면서…

오늘의 깨달음. Mark as Asset으로 등록해두면 Idle모션을 어셋으로 등록해둘 수가 있다. 이렇게 해두면 새로운 동작을 만들 때 Idle의 첫프레임을 붙여놓고 시작할 수가 있다.

충돌을 설정하기 위해 컬리전을 설치. 작업초반인데도 익스포트가 잦다.

컬리전박스 호환이 안되어 뱅가드가 생각보다 일찍 퇴장했다. 앨리스가 대신 맞기로 하자.

컬리전 세팅만 했는데 타임오버! 2023년의 마지막 밤작업은 이렇게 막을 내린다. 애가 방학이라 작업시간이 매우 쪼그라든 상태다. 병설 유치원은 방학이 2달이다! 앞으로 계속 별다른 작업은 힘들 것 같다.흑흑

1.1

새해엔 게임하느라 작업을 쉬었다. 새해 복 많이 받으세요!

1.2

타격감을 보기 위해 데미지 모션을 먼저 처리해야 할 필요가 있다. 그리고 이를 위해선 데미지 모션 리스트를 먼저 확정해야 한다. 여러가지 생각을 해보았지만 서서맞는 경우, 데미지의 강약과 머리,복부를 맞는 경우를 가정하기로 했다. 그리고 이것들의 더미 모션들을 먼저 제작한다.

오늘의 깨달음.

모션을 새로 만들 때 그냥 Fake-User로 모션을 보호하는 편이 PushDown보다 편하다. 이처럼 비슷한 모션을 만들 경우엔 더더욱 그렇다.

본격적인 애니메이션 제작에 앞서 타격을 먼저 붙여보자. 타이밍을 재는 것이 주 목적이므로 애니메이션의 퀄리티는 중요하지 않다. 예상보다 버그도 많고, 문제도 많다. 으으흐흑

충돌체크가 원활하지 않아서 한참을 헤멨다. 원인은 바로 Bounds클래스 내의 Intersect()메서드였다. 이 메서드는 박스가 충돌할 경우 True를 리턴하는 함수인데, Collider2D를 사용하는 지금은 Z의 계산을 하지 않아도 별 상관이 없는데 엉뚱하게 z를 계산하고 있었다. 아오 빡쳐!!! bounds라면 어차피 x,y2개뿐인데 z를 왜 계산해, 이놈들아…!!

Intersect()함수에서 z부분을 빼서 컬라이더용 함수를 따로 만들어야 한다.

bool IsCollision(BoxCollider2D c1, BoxCollider2D c2){

        Bounds b1 = c1.bounds;

        Bounds b2 = c2.bounds;

        return b1.min.x <= b2.max.x && b1.max.x >= b2.min.x && b1.min.y <= b2.max.y && b1.max.y >= b2.min.y;        

    }

이제 문제없다.

1.3

기본 공격모션들의 러프한 모션들을 붙여 느낌을 보자. 그렇게 생동감넘치는 동작들은 아니지만, 기본적인 타이밍을 보기엔 부족함이 없다. 가까이 있을 때와 멀리 있을 때의 모션이 다르고, 앞으로 점프할 때와 제자리 점프의 모션 또한 다르다. 기본 공격 모션은 생각보다 많다.

스테이트는 예상치의 절반정도를 추가했을 뿐인데도 이 정도. 물량이 많아지면 몇가지 문제가 발생한다. 일단 익스포트가 꽤 오래걸린다. 툴을 자유로이 오가야 하는 입장에선 이런 것들이 꽤나 성가신 문제로 발전할 수 있다. 파일을 나누어야 한다.

처음엔 블렌더 파일을 나눌 생각이었는데, 그럴 필요가 없다. ARP의 액션매니저가 이를 대신해준다! ARP는 정말 돈값 이상을 한다. 블렌더로 게임제작을 위해선 반드시 구비해야 할 애드온이다.

오늘의 깨달음. 실제 모션을 만들 땐 공격하는 부위가 살짝 앞으로 오게 만들면 좋다. 이처럼 겹치는 걸 방지하기 위함

12.28

페이셜 테스트

페이셜을 위해선 좀 더 복잡한 작업을 해야 한다. 셰이더를 작성하는 것에 추가로 애니메이션의 셰이프키와 셰이더의 프로퍼티를 연결하는 작업이 필요하다. 블렌더의 드라이버 기능에 해당하는 일이다. 언리얼은 머티리얼 커브라는 기능이 이를 대신하지만, 유니티는 아무래도 없는 것 같으니 만들어주자.

제목이 애니메이션 준비인데 정작 애니메이션은 들어가지도 못하고 있다. 그래도 가장 큰 산인 셰이더 컨버팅이 완료가 되었으니 이제 본격적으로 애니메이션을….들어가고 싶었는데 입셰이더에서 작은 문제가 발생했다.

저게 왜 저러지…?! 아무래도 clamp가 오작동하는 것 같은데.. 싶어서 관련코드를 지워보니

clamp문제가 맞다. 그럼 왜 이런 현상이…아… 버텍스 셰이더!

입의 셰이더 처리 대부분은 UV변형이다. 스케일, 회전, 이동등인데, 이펙트처럼 디테일한 변화가 필요없기 때문에 대부분 버텍스 셰이더에서 처리하고 있었다. 그 중엔 입의 UV를 경계에 맞게 짤라주는 clamp가 들어가 있었는데 이것을 버텍스 기준으로 처리하게 되면 당연히 입이 늘어나게 된다.

그 외 소소하게 입의 회전이 블렌더와 반대로 돌아가는 문제가 있어서 이것도 수정했다. 원인은 이것때문이다.

출처 : http://batmask.net/index.php/2022/09/13/1729/

오늘의 깨달음. 유료애드온인 핫리로드는 셰이더 코드는 리로드해주지 않는다. 유니티는 셰이더 리로드가 워낙 빠르니 안켜고 작업하면 되긴 하지만, C#과 셰이더코드 두개를 병행해 작업할 땐 살짝 불편하다.

마참내! 유니티에 띄운 앨리스. 이브, 그동안 고마웠어. 뱅가드는 조금만 더 수고하자.

드디어 준비가 끝났다! 이제 클립을 제작해보자.

12.24

메리크리스마스! 작업하자.

셰이더 컨버팅 중 문제가 생겼다. 앤젤링의 강도는 엔진마다 차이가 날 수는 있으나, 위치가 다른 것은 문제다. 왜 이런 현상이 일어나는지 조사해야 한다.

가장 먼저 의심된 것은 UV의 컨버팅 여부인데, 이것은 정상이었다. 컬러그리드맵을 씌워본 결과 모든 UV는 정상이다.

앤젤링의 연산에 sin함수를 사용하고 있는데, 이것이 블렌더와 다를 수 있다. 해서 살펴봤지만 이것도 정상이다.

원인을 알아냈다. v의 문제였다. 앤젤링은 뷰에 따라 uv를 offset해주는 해주는 방식을 사용하고 있는데, 엔진의 uv와 블렌더의 uv가 서로 다른 문제가 있다. 블렌더는 아래가 0, 엔진은 위가 0이다. 따라서 v를 움직이려면 부호를 바꿔주어야 정상작동한다. 이건 언리얼도 마찬가지인데, 입이나 눈처럼 uv를 오프셋해주어야 하는 부분에서 특히 까다롭다.

앤젤링의 컬러는 블렌더에선 헤어컬러를 좇게 했다가 엔진에선 커스텀으로 지정할 수 있게 하였다…가 다시 헤어컬러를 따라가도록 변경했다. 하지만 이번엔 엔젤링의 강도가 문제였다. 이를 찾기 위해 셰이더코드를 여기저기 뒤진 끝에, 이건 그냥 텍스처의 문제란 것을 발견했다.

앤젤링은 이런 바코드 텍스처(아휴 작아)를 사용하고 있는데 유니티에선 이것을 Single-Channel로 지정해 사용한다. 채널이 하나라면 자동으로 Linear컬러로 계산되고, 리니어 컬러는 감마처리를 하지 않았기 때문에 사람의 눈으로 볼 땐 좀 더 밝게 보인다. 이를 위해 블렌더에서도 sRGB와 Linear를 정의할 수 있는 프로퍼티를 제공하는데, 이것을 sRGB로 둔 것이 원인이었다.

컬러스페이스를 리니어로 바꾸면 이제 유니티와 비슷해진다.

문제는 sRGB 버전이 더 마음에 든다는 것이다! 이를 위해 포토샵에서 이미지를 어둡게 조절해 봤지만 결과가 약간 다르다.

전보다는, 좀 더 부드러운 느낌이 든다.

이제 얼굴 셰이더를 만들자. 일다나 스킨셰이더를 복사해서 넣어보았다. 아이고 무셔…

얼굴은 예외적인 셰이더 투성이다. 눈, 눈썹, 입, 얼굴 셰이더가 모두 다르고 하나하나 다 복잡하다.그 중에서 가장 쉬운 얼굴 셰이더부터 옮겨보자.

얼굴 제작 중 임시로 마스크를 벗겨주려고 했지만 작동이 되지 않는다.

URP에서 알파블렌드말고 알파테스트는 어떻게 가동시키는걸까. 이런저런 자료를 찾아봤는데 HLSL에선 2가지 방법이 가능했다.

clip(-1);                

if (a<0) discard;

그냥 셰이더 모델 바꿔주고 알파값만 지정해주면 될 줄 알았는데, 그게 아니었다. 레거시 셰이더에선 AlphaTest커맨드로 가능하다고 하지만, 내가 사용하는 것은 HLSL이기 때문에 작동하지 않았다. 이걸 알아내느라 몇 시간을 쓴걸까… clip()함수 사용법을 몰라서 한참을 뒤졌다. 0보다 크거나 같으면 출력, 작으면 폐기된다.

어쩐지 렌더타입과 큐와도 관계가 없다. 알파테스트가 아니라 오파쿠여도 작동된다. 뭐 내부가 어떻게 돌아가는 건지 하나도 모르겠어. 이런 점들이 셰이더 공부에 난이도를 더한다. 정보가 매우 파편화되어 있어 검색해도 그게 답이 아닐 때가 많다.

타임오버. 얼굴이 아직 끝난 게 아니라는 것이 문제다.

12.25

얼굴은 마무리를 했다. 눈썹이 빨갛게 나오는 문제가 있는데 이건 데이터 문제이니 나중에 손보면 될 것이다.

입셰이더를 컨버팅을 했는데 한 번에 잘 작동할 리는 없다… 타임오버이니 여기서 끊고 커밋을 해두자.

12.26

입 셰이더를 짜려고 유니티를 열었는데, 블렌더에 비해 홍조가 너무 붉게 나오는 것이 눈에 띄었다. 그러고보니 눈썹부분도 너무 붉게 나오는 것이 수상하다.

홍조는 버텍스 컬러의 R채널의 정보를 받는다. 눈으로 봐도 꽤나 차이가 난다. 왜 이런 차이가 날까? 처음엔 float와 half의 정밀도 차이인가 싶었는데, 아차! 컬러스페이스!

블렌더의 버텍스컬러의 노드를 받아오는 부분은 감마가 자동으로 계산되는 것 같다. 리니어 컬러스페이스는 인간의 눈으로 볼 때 흰색이 좀 더 부각되어 보인다. 이를 맞추기 위해선 2.2를 제곱해야 한다. 따라서 버텍스 컬러를 받아오는 이 코드는

half4 colorMask = IN.color;

이렇게 수정되어야 한다.

half4 colorMask = pow(IN.color, 2.2);

이제야 제대로 된 색이 출력된다. 참고로 다시 리니어 스페이스로 돌리는 건 0.45제곱을 하면 된다.

하지만 컬러는 어차피 버텍스 단위로 계산되니, 프래그먼트보단 버텍스에서 하는 게 조금이라도 더 좋을 것 같다. 따라서 코드를 버텍스 셰이더쪽으로 옮긴다.

OUT.color = pow(IN.color, 2.2);

하지만 이 코드는 블렌더와 완벽히 호환되지 않는다. a는 언제나 리니어 컬러 스페이스로 계산되어야 한다. 따라서

OUT.color.rgb = pow(IN.color.rgb, 2.2);

OUT.color.a = IN.color.a;

이렇게 따로 변환해주어야 한다.

이제 완전하게 변환된다. (하지만 전혀 티가 안난다….)

하지만 컴파일창에 경고가 떠있다. pow함수는 음수가 지원되지 않는다고 한다. 물론 color는 음수를 사용할 수 없지만, 에러를 막기 위해 절대값변환을 해줄 필요가 있다.

OUT.color.rgb = pow(abs(IN.color.rgb), 2.2);

이제 문제없을 것이다. (아마도?)

입셰이더를 컨버팅하다가 알게 된 충격적인 사실. 유니티의 UV.v의 원점 위치도 블레더와 같이 아래에 있다. 언리얼만 위에 있는 것인가.

입의 셰이더도 완료. 다음은 눈.

1차 구현. 곤충이 되어버렸어!

곤충눈 현상은 텍스처 설정이 Repeat이기 때문에 나타나는 현상이었다. Clamp로 바꾸면 해결된다. 코드는 죄가 없다.

눈까지 완료. 하지만 블렌더와는 다르게 유니티에선 한가지 셰이더를 더 만들어야 한다. 바로 눈썹셰이더이다.

미루어놓았던 문제는 반드시 말썽을 일으킨다. 눈썹이 그렇다. 눈썹의 외곽선을 어떻게 처리할 지 고민을 하다가 부피가 크지 않아서 미루어 놓았었는데 결국 역풍을 맞았다.

그래도 다행인 것은 블렌더의 셰이프키 시스템이 어지간해선 말썽을 부리지 않는다는 것이다.

윤곽선을 표현하기 위해 이렇게 눈썹의 토폴로지를 다르게 변경해도, 별다른 말썽을 일으키지 않는다. 조금만 수틀려도 모든 데이터를 일그러뜨리는 맥스의 모핑시스템은…아휴, 말을 말자.

하나 더 다행인 것은 얼굴데이터 이전 스크립트를 미리 만들어 놓았었다는 것이다. 이 스크립트는 얼굴데이터에 연결된 머티리얼과 셰이더에 연결된 드라이버를 원래 캐릭터의 정보로 바꿔준다. 수동으로 하자면 하루는 족히 걸릴 작업을 버튼 한번으로 끝낼 수 있다. 고마워. 과거의 나!

12.27

얼굴 노말을 위한 버텍스 그룹을 지정할 때 WeightTool을 사용하면 다른 그룹을 건든다. 애드온의 버그인 것 같아 보인다.

아이라인 화장을 위한 마스킹을 버텍스 그룹으로 지정해두었는데, 이것이 깨지는 현상이 있었다. 편집하는 그룹 외에 다른 그룹은 꼭 잠가둘 것.

얼굴의 명암이 지저분하게 나오는 현상이 있어서 이를 조사했다. 원인은 커스텀 노말 계산부분의 노말라이징.

부드러운 얼굴 셰이딩을 위해 구형 노말과 원래 노말을 섞어서 쓰고 있는데, 구형노말을 계산할 때 노말라이즈를 빼고 있었다. 이는 의도적인 것이었는데, 어차피 픽셀셰이더로 넘긴 후엔 노말라이즈 해줄테니 버텍스셰이더에서 해줄 필요 있을까? 싶었지만 이것이 잘못된 생각이었다.

원인은 일찍 찾았는데 이걸 위해서 또 얼굴 데이터를 한바탕 청소했다. 좋아. 하는 김에 회색지대에 있던 작업들을 끝내버리는 편이 어떨까.

이것 또한 미루어왔던 작업이다. 얼굴은 데이터의 복잡도로 인해 틀이 잡히기 전까진 외곽선을 그리지 않고 있었다. 턱선을 그어주는 것과 그렇지 않은 것은 분명한 차이가 있어 보인다.

윤곽선은 여러개의 셰이프키는 필요하지 않지만, 그래도 고작 얼굴 실루엣 잡아주는데 이 정도 데이터를 쓰는 건 좀 낭비같다는 생각은 든다. 하지만 초심을 유지하기로 하자. 퀄리티를 낼 수 있다면, 어떤 비효율도 감수하기로.

다시 눈썹으로 넘어가고 싶은데 타임오버. 눈썹은 최종적으로 머리카락 위에 그려져야 한다. 큐를 어찌어찌하면 된다고 들었는데… 지금은 방법을 모르겠다. 스샷은 느낌을 보기 위해 ZTest를 건너뛰어 출력한 것이다. 그 어떤 오브젝트가 가리든 출력하기 때문에 사용할 수 있는 방법은 아니다.

…자러 가려고 했는데 문득 생각이 나서 테스트. 오.. 됐다. 렌더큐는 그리는 순서를 말하는 것인데, 이걸 아무리 정렬해봤자 작동하지 않는 게 당연하지[…] 일단 헤어의 렌더큐를 2낮춘다. 그 다음 눈썹의 ZTest를 Always로 그린다. 물론 다른 오브젝트위에 출력되어야 하니 ZWrite는 켜두어야 한다.그리고 헤어보다 높은 큐를 할당하면 된다. 즉 렌더순서는 헤어 -> 눈썹 -> 기타 셰이더가 된다.

그런데.. 이거 낮춰도 되나…높이는 건 많이 봤는데 낮추는 건 못봤는데… 일단 되니까 넘어가기로 하자.

12.20

본격적인 작업에 앞서 손의 라이브러리를 정의할 필요가 있었다. 이번 작업에서는 기존에 사용하던 오토리그 프로의 Fist컨트롤러를 뺐는데, 첫번째 이유는 컨트롤러본이 많을 수록 제어할 것이 늘어나 작업에 혼선이 많아지기 때문이고, 또 다른 이유는 포즈라이브러리가 그만큼 강력하다고 생각했기 때문이다.

손이 쥔 것도 아니고, 편 것도 아닌 애매한 모양이라 이런 걸 미리 정의해두면 편하다. 이걸 왜 하냐면…

칼자루같은 걸 쥘 때, 먼저 손을 활짝 편 후에 Fist로 블렌딩해서 표현하면 좋다. 손에는 관절이 많기 때문이다. 또한 손가락만 선택하고 싶을 때 선택용 그룹으로도 사용할 수 있다.

두번째로 세팅할 건 애니메이션 시의 잔상이다.

이건 프레임이 떨어지더라도 잔상이 없는 편이 좋을 것 같은데… 처음에는 이 잔상이 디퍼드 렌더링의 고질적 문제라고 생각했으나..챗GPT에게 물어본 결과 사이클은 디퍼드가 맞는데, 이브이는 포워드라고 한다. 이 놈을 믿어야 할까…싶다가도 이것저것 옵션을 찾아본 결과.

씬의 이브이 렌더러 샘플링 옵션에서 디노이징을 끌 수 있는 옵션을 발견했다!

이 옵션을 끄면 잔상이 사라진다. 대신 애니메이션 시에 안티앨리어싱이 나오지 않는다. 하지만 그게 뭐 중요한가. 눈이 맑아진 느낌이다.

세번째 설정은 프레임레이트이다.

우연의 일치일지는 몰라도 앨리스 모델의 경우, 목표치인 30frm에 근접한 수치를 보여줬다. 그냥 이대로 작업해도 되지만, 키가 많아지면 프레임레이트가 느려질 것은 불보듯 뻔한 일이다. 그리고 이 경우, 의도했던대로 애니메이션을 제작하기 힘들어진다. 재생속도가 느려지기 때문이다.

그래서 프레임스킵과 관련된 내용을 열심히 찾아본 결과…뜻하지 않게 빙GPT가 해답을 알려주었다.

대충 해석 :

뷰포트의 애니메이션 속도를 일정하게 유지하려면 다음과 같은 절차를 따르면 됩니다.

1. 타임라인을 봅니다. 거기에 Playbak이라고 써진 드랍다운메뉴가 있습니다. 이걸 누르면 팝업메뉴가 뜹니다.
2. 메뉴에 Sync라고 써진 메뉴가 있습니다. 이걸 ‘Frame Dropping’으로 바꿉니다.

도움이 되었길 바랍니다! 다른 질문이 있다면 알려주세요.

어쩐지 절차가 구체적이다 싶어서 살펴봤더니 정말로 있다. 오오!이제부터 빙GPT를 욕하는 건 나를 욕하는 것이다.

프레임 레이트는 여기에서 바꿀 수 있다. 시험삼아 60frm을 바꿔봤더니 2배빠르게 재생된다.

이제 준비에 필요한 모든 문제는 해결한 것처럼 보인다. 본격적으로 작업을 시작해보자.

오늘의 깨달음

회전 중심 포인트를 3D커서로 맞추고, 커서를 원하는 위치에 두면 해당축을 중심으로 회전시킬 수 있다. 맥스를 쓸 당시 바이패드에 있던 이 기능이 그리웠었는데 이로서 해결됐다.

만들다 보니 좀 감이 안잡힌다. 다리 거리를 어느정도나 띄워야 할까? 속도는 적절할까? 

그… 일단 러프하게 만들어서 넘겨보자. 뭐라도 되겠지…

이제 유니티로 가보자. 이제 정식 데이터를 만들 것이므로, 프로젝트 파일을 리셋한다.

오늘의 깨달음

VS Code에서 변수선언위에 나오는 ‘xx references’의 문구들은 Code Lens라고 한다. 코드 초반엔 도움이 될 지 모르겠으나(사실 초반에도 그닥…) 덕지덕지 붙은 모양이 그렇게 깔끔하지는 않다. 이걸 없애려면 세팅(ctrl+,)에서 code lens를 검색한 후에 꺼주면 된다.

이제 깔끔해졌다.

이제 셰이더 컨버팅을 해야 한다. 유니티에서 기본 Unlit을 만들면 CG스타일로 짜주는데 URP에선 HLSL스타일을 권장한다고 한다. 아휴, 하나만 해라. 좀… 가뜩이나 배우기도 힘든 셰이더인데.

첨부터 다 짜긴 시간이 아까우므로 일단 예전에 짠 셰이더를 주섬주섬 고쳐쓰자.

다행이 잘 작동하는 것 같다.

12.22

본격적으로 셰이더 컨버팅을 하려는데… 생각해보니 난 스크립트로 노말맵을 구현해본 적이 없다. 이에 대한 자료를 찾던 중에 마둠파님 블로그에 친절하게 설명이 되어있는 것을 발견.

https://m.blog.naver.com/mnpshino/221869618181

난 이렇게 조리있게 글을 쓰진 못할 거야.. 어쨌거나 회전툴 만든다고 행렬곱으로 한 고생했던지라 감회가 새롭다. 예전에는 그냥 코드 복붙 후 되면 좋고 안되면 말고…였는데, 이제는 어느 정도 이해가 된다. 역시 굴러야 실력이 는다.

어..음… 뭔가 범프가 표시되긴 하는 것 같은데…

아… 노말맵 세팅이 안돼있었다.

솔리드 머티리얼 완료. 다리가 왜 빛나나 싶었는데, 마스킹 설정이 잘못돼 있었다. 하지만 테스트하기는 좋은 예제가 되었다.

12.23

컨버팅 중. 맷캡의 느낌이 블렌더와는 좀 다르다. 아마도 블렌더 행렬계산에 오류가 있었던 것 같다.

피부는 느낌이 비슷하다. 가장 중요한 부분이었는데, 다행스러운 일

얼굴로 갈 수록 점점 어려워진다. 오늘은 여기까지

12.19

대부분의 게임이 그렇겠지만, 대전 격투에서는 특히 더, 대기 자세는 모든 모션을 통틀어 가장 중요하다. 각종 모션이 이 동작에서 파생되고, 가장 처음 보여지는 모션임과 동시에, 캐릭터의 개성이 표현되는 부분이다. 또한 모션이 너무 깨져서도 안되고 피격 판정을 위해 어느 정도는 네모 안에 들어와야 한다. 동시에 예뻐야 한다. 처음부터 어렵다.

믿기 어렵겠지만, 이 자세를 얻기까지 3시간이 걸렸다.

문제는 계속 튀어나온다.

치마아래 엉덩이라인이 보이는 것이 뵈기 싫어서 조금 더 수정. 포즈는 일단 이대로 두고 다음 날 다시 보는 것이 좋다. 이렇게 하면 좀 더 객관적인 시각으로 작업을 대할 수 있다. 때때로 형언할 수 없을 정도로 엉망인 경우도 많기 때문에…반드시 시간을 두어야 한다.

닐리

달래

오로라

달래와 오로라에겐 공통적인 문제가 발생한다. 상의의 통이 커서 실루엣 보간을 안해도 된다고 생각했는데, 생각보다 더 예쁘지가 않다. 오로라는 가방끈을 쥘 수 없게 설계해놨는데, 자세를 잡다보니 이 쪽이 어울려서 추가해야 할 필요가 있다.

12.20

오로라의 팔꿈치쪽에 실루엣 보간용 본을 설치.

완전하다고는 할 수 없으나, 팔꿈치의 실루엣을 제법 보완해준다.

앨리스가 좀 뻘쭘해 보인다. 너무 정석적인 자세인데, 딱히 어울리는 자세도 없다는 게 문제… 동양검 잡듯이 꺾어잡기는 싫고…

12.14

오로라는 특별한 것이 없다. 로봇은 대체로 리깅이 쉬운 편이고, 오로라 본체도 주렁주렁 달린 것도 그닥 없기 때문에…라고 생각했는데 예상밖의 문제는 늘 발생한다.

오로라의 컨셉이 문제가 된다. 평소엔 로봇팔이 가방 속에 들어가 있어야 한다. 필요할 때마다 가제트 팔처럼 튀어나와야 하는데, 이를 위해 스케일 애니메이션을 할 생각이었으나… ARP의 관절 시스템이 이를 쉽게 허용해 주지 않는다. 으.

수동으로 FK/IK를 구현하기엔 방법도 모르거니와, 구현한다고 해도 인터페이스가 ARP와 달라 여러모로 불편한 점이 많다. 그렇다고 ARP를 커스텀하자니 익스포트 문제가 걸린다.

좋은 방법이 없을까…

12.15

오늘의 깨달음

• 제약조건 Track to는 구식이니 쓰지 말 것. 결과값도 안좋다. Damped Track을 써야 한다.

결국 스케일을 위해 팔의 본은 회전값을 카피하는 별도의 본을 사용하는 걸로 세팅했다. 어차피 팔 본이 살아서 넘어가기 때문이 이는 매우 비효율적이지만, ARP는 세팅 그대로 사용하는 편이 좋기 때문에 방법이 없다.

이제 엔진확인이 필요하다. 엔진을 켜니 유니티 클라우드를 사용하지 않으면 클라이언트 구동을 하지 못할 것처럼 써놨는데, 된다.

다행이다. 잘 넘어온다.실린더가 넘어오지 않는 건 커스텀본 세팅을 빠뜨렸기 때문이다.

하지만 데이터 최적화면에서 아쉬운 면이 있다. 팔 본을 최소화시켰다고 하더라도 어쨌거나 이 본들은 넘어오는 정보이고, 최종적으로 유니티에선 사용하지 않는다. 심지어 키도 잔뜩 붙어있다. 뭐 별 수 없다.

그른데 Damped Track이 오작동한다. 작동하긴 하는데 결과값이 이상하다.

데이터를 따로 만들어보니 읭…? 잘 넘어오는데?

는 정보가 제대로 넘어오지 않은 것 같다. 왜 옛날이름…

아마도 익스포트에 시간차가 있었나보다. 작업을 진행하다보면 이렇게 별 것 아닌 문제로 시간을 잡아먹을 때가 있는데, 이 오류를 찾는 과정도 작업의 일부이라고 생각한다. 하지만 그래도 역시 시간이 아깝다.흑흑

이걸로 데이터가 잘 넘어오는 걸 확인했다. 이제 미러하고, 인물작업에 들어가보자.

아직까지 딱히 어려운 점은 없다. 오늘은 타임오버.

Data Transfer를 이용하면 한 번 잡아놓은 웨이트를 계속 쓸 수 있어 정말 편하다.

12.16

힙은 늘 문제다, 하지만 이미 닐리를 작업하며 지옥을 거쳐왔기에 비교적 수월하게 작업했다.

영상을 찍는 건 window+G키로 되는데, 앞뒤로 버튼 누르는 걸 좀 짜르고 싶어서 이것저것 편집기를 찾다가 윈도우에 내장된 동영상 편집기가 있다는 사실을 알았다. 그런데 이게 더 이상 지원을 안하는지, Clipchamp란 걸 새로 받으란다. 막상 받아서 해보니 오.. 생각보다 훌륭하다. 하지만 이걸 알아보느라 작업은 거의 못하고 타임오버. 나머지는 내일 해보자.

12.17

오로라 머리카락 리깅 작업 과정. 난 블렌더를 좋아하지만, 포즈모드와 오브젝트 모드를 오가는 리깅 인터페이스는 좀 수정되어야 한다고 느낄 때가 많다. 딱히 더 편한 방법을 제시하라면 또 그건 모르겠지만…

지금까지는 단발머리가 없었다. 앨리스는 묶은머리, 닐리는 본이 너무 많아서 머리에 쓸 여분의 본이 없었고, 달래도 땋은 머리. 때문에 고민이 된다. 얘는 치마도 없기 때문에 본이 남는데, 가닥을 더 세분화할 것인가? 아니면 그냥 덩어리로 묶을것인가?

이론적으로 여유가 남으면 쓰는 게 맞긴 한데, 디테일하다고 무조건 예쁜 실루엣이 나오지는 않는다. 그림을 그릴 때도 모든 가닥을 하나하나 그리지는 않으니까.

그른데 어찌됐든 이건 망한 듯. 다시 해보자…

본이 디테일하다고 무조건 예쁜 실루엣이 나오지 않는,..는 착각이었다. 본은 다다익선이다.!

12.18

사나운 가방. 얘도 이름을 지어주면 좋겠다. 사나운 가방. 사방? 백팩이니까.. 사팩? 좋아. 사팩으로 하자.(까먹을 듯)

기계팔은 가방에 연결돼 있고 ARP시스템의 Arm에 속한다. 하지만 이것이 별도로 추가한 관절이라 익스포트 과정에서 본 생성이 잘 되는지 확인이 필요하다. 유니티를 켜자.

오굳. 뭔 마법인지 잘 넘어온다.

컨트롤러에 연결된 본은 ARP가 알아서 디폼본에 붙여준다는 사실을 확인했다.

오로라도 끄읏!

12.9

폴리곤이 많아지니 어깨부분은 그냥 잡아주는 거 쓰면 된다.

왜냐면 생각보다 꽤 잘 움직이기 때문이다. 괜히 디테일 잡는다고 고생하다가 리셋.

12.11

전날은 감기때문에 그냥 잤다 . 건강이 최우선.

옷고름에 폴리곤좀 많이 쓸걸…

닐리와 비슷한 골머리를 썩게 됐다. 이 기회에 확실히 규칙을 다잡아두지 않으면…

파이썬 for문의 continue의 용도를 알게 됐다. 사실 파이썬은 정식으로 배웠다기보단 블렌더 스크립트를 사용하며 곁다리로 배운거라 이런 기본적인 용법을 잘 모른다. break는 루프를 아예 멈춤, continue는 이후 구문을 실행하지는 않지만 루프는 유지.라는 뜻이다. 지금까지는…? 그냥 if로 밀었다.(…) 이러면 코드가 점점 뒤로 밀려서 가독성이 떨어지게 된다.

챗GPT에게 또 한 수 배웠다!

노트 : Skirt_Scaler의 스페이스는 로컬이다. 트랜스폼을 쓰지 말 것.

12.12

스커트 본의 모든 걸 자동화하려니 모든 상황에는 맞지 않는 문제가 일어난다.위처럼 허리를 약간만 숙여도 치마가 지나치게 올라가는데

실제로는 원형이 최대한 유지되는 편이 낫다. 하지만 이걸 수동으로 할 수 있을까? 끔찍하게 귀찮을텐데…

ARP기본보다도 못한 느낌…

12.13

여전히 치마에서 삽질 중이다. 좋은 방법이 떠올랐다.싶다가도 정작 해보면 적절하지 않은 시도를 반복하고 있다. 삽질 중엔 별다른 말이 없이 열심히 머리만 굴리는데, 기록을 해놓으면 좋다는 걸 알면서도 그럴 여력이 안된다. 수정이 워낙 잦기 때문이다.

결론적으로 달래의 스커트는 닐리의 그것과는 다르다. 허벅지 부분을 터놓았을 뿐인데 움직이는 방식이 다르므로 생각을 다르게 접근해야 한다. 윗부분은 닐리의 것과 같지만 아랫부분은 차라리 앨리스의 치마와 비슷하다. 팔락거리지는 않지만 그렇다고 옆다리에 의해 당겨지지도 않는다.

충분히 고민했지만 수동조작외엔 답이 없다는 결론에 이르렀다. 작업 시작할 땐 얘는 달린 게 얼마 없어 쉬울 줄 알았는데 또 다른 벽을 느끼게 해주었다. 조작이라도 최대한 쉽도록 세팅해보자.

다리를 올리면 작동하는 스케일러는 내비둔채로, 아랫쪽의 치마만 들 수 있는 컨트롤러를 새로 만들었다. 원리는 Copy Rotation의 영향값에 드라이브를 건 것이다. 즉, 다리에 스냅된다.

처음의 계획은 컨트롤러를 하나로 통제하는 것이었지만, 생각보다 잘 움직이지 않아 앞/옆/뒤의 컨트롤러를 분리했다. 그 전에도 캐릭터 전용 컨트롤러를 만들 예정은 있었지만, 그게 달래는 아닐거라고 생각했다. 디자인이 별 게 없었으니까…

사람손을 많이 거치긴 하지만, 어쨌거나 이제 수동이라도 치마 실루엣을 제대로 보존할 수 있게 되었다.

활도 완성. 화살이 좀 짧길래 늘렸는데 그래도 짧아보인다.

치마만 해결되면 나머지는 쉽다. 달래 리깅 완료

포즈를 잡을 때 회전툴이 작동하지 않는 버그가 있었다. 리깅을 하다보니 액션데이터에 쓸데없는 값이 무수히 많아 발생하는 문제라고 추측된다. 액션을 지우고 리셋해주면 정상작동하긴 하나, 추후 데이터가 커지면 또 어떤 문제가 발생할 지 모른다.일단은 메모

12.8

닐리의 리깅만 보름째 이어가고 있다. 이 과정은 내게 많은 삽질을 시켰고, 많은 깨달음을 주었고, 마침내 작업이 마무리될 즈음, 보이지 않던 것들이 보이기 시작한다. 코트의 본은 당연히 어깨에 가까운 트위스트 본의 자식으로 둔다면 돌아가지 않는데, 이걸 왜 자동화불가능하다고 생각했을까? 또한 그렇게 마음에 안들던 소매의 웨이팅은 단순한 스무싱으로 깔끔하게 해결이 된다. 인내는 썼지만 열매는 역시 달았다.

개발인생 최고의 난이도였다. 이제 이게 유니티에서 잘 돌아가기만을 빌어보자.

본이 워낙 많아 뚫는 건 어쩔 수 없지…

이렇게 말하니 끝난 것 같은데, 사실 아직 안끝났다.흐흐흫응ㄱ

12.9

드라이브 이전과정에서 오래된 드라이버를 붙이는 현상이 있었다. 또한 존재하지 않는 채널을 복사하려다가 오류를 뱉는 현상도 발견되었다. 이는 테스트 과정에서 중복되거나 유효하지 않은 드라이버를 설정한 것으로, 애드온의 코드는 죄가 없다. 두 경우 모두 드라이버창을 열어서 채널을 삭제하면 해결된다. 기록차원에서 적어두자.

드라이브가 너무 민감하게 반응하다보니 다리를 살짝만 굽혀도 팬티가 보이는 현상이 있어서 이를 둔화시켰다.

이제 해결된 것으로 보인다. 너무 자주 보여도 좋지 않아.

정말로 끝이다! 달래로 넘어가보자