애드온의 용량이 20기가나 한다. 전에 샀던 눈 머티리얼도 그렇지만 이 터레인도 Displace를 사용한다. 하이폴 렌더에서는 이런 작업방식이 표준인가? 어쨌거나 원경을 표현하는데는 제 격이다.
오….원경은 뒷판에 조금 보이는 것이 아까울 정도로 멋드러지게 잘 뽑혔다.
바닥 굽고, 배치끝. 이제 유니티 타임
펄~펄~ 눈이 옵니다~
오늘의 깨달음. 빌보드는 인스턴싱이 되지 않는다?! 코파일럿의 이야기이기 때문에 완전히 신용할 수는 없지만, 카메라를 향하는 것 자체가 행렬재계산 과정이 들어가기 때문에 인스턴싱이 불가능할 것 같기는 하다. 따라서 인스턴싱을 하려면 Mesh를 사용해야 한다. 눈 같은 경우 굳이 카메라를 따라가지 않아도 되기 때문에 이 경우엔 Plane메쉬를 임포트해서 사용할 수 있다.
그런데 언리얼에선 GPU 인스턴싱이 되던데.. 그건 뭐지…?
설원 배경 제작 완료. 유튜브 알고리즘은 대체 어떤 구조이길래 어떻게 섬네일을 저렇게 극적인 장면으로 잘도 뽑아내는지…
AI는 테스트용으로 쓰고 있는 단순 막고 치기인데, 오로라에게 연타기술이 있다보니 하마터면 질뻔(…)
포스트 프로세스는 현재 메인렌더러 피처에 넣어서 레벨별로 켜고 끈다. 볼륨이 스테이지에 귀속되지 않고 메인렌더러 피처에 기생하고 있는데, 별로 좋은 방법같지는 않다… 언리얼에는 그냥 볼륨을 추가해주면 되는데 유니티에서는 등록에 일련의 과정이 필요한 모양이다. 당장이야 스테이지가 몇 개 안되니 이렇게 쓰더라도 추후 개발할 때는 자세히 알아보는 편이 좋겠다.
도서관은 오로라의 배경이다. 돌핀팬츠 하나만을 보고 거의 아무 생각 없이 만든 캐릭터인데(심지어 처음엔 용을 타고 다녔다.) 이제는 설정을 붙일 때가 됐다.
배틀퀸은 배틀스톤을 소유한 자를 일컫는 말이고, 정식 절차를 거쳐 계승될 수 있다. 하지만 부정 승계를 받은 현재의 배틀퀸이 자신을 위해 이 힘을 사용했고, 그 결과 차원이 갈라지며 차원 관리자의 두통을 유발시켰다. 오로라는 이 난리를 조사하기 위해 파견된 조사관인데, 거의 온종일 도서관에서 지내야만 하는 그녀에게 바깥나들이는 신나는 것이었다. 오로라의 임무는 차원의 균열이 생기는 원인을 찾을 것. 때문에 이야기는 차원의 균열이 생긴 도서관에서 시작된다…라는 긴 이야기.
일단 도서관에서 어셋을 사고, 임시배치, 균열부분은 예전에 연습삼아 만들어둔 카페를 사용할 예정이다.
에이콘에서 요렇게 3개의 후보중에 맨 아래모델을 선택. 가격때문이라기보단 FBX로 제공되는 것이 마음에 들었다.
이제 도서관 부분을 배치.
균열 부분은 예전에 스타벅스 신논현점을 참고해서 만들었던 습작을 사용할 예정이다. 이걸 쓰게 될 줄은!
2.14
UV작업 중
2.15
UV작업이 끝날 때 즈음 알게 된 사실.
뒷면은 지워주는 편이 좋다. 이는 실시간 렌더의 최적화 프로세스에서 뒷면이 없으면 그림자가 제대로 처리되지 않을 것이라는 염려로 인해 남겨두려 했던 것인데, 베이킹할 땐 알아서 빛 차단을 해준다. 여기엔 3가지 이점이 있는데, 폴리곤의 절약, UV의 절약, 작업시간의 절약. 무조건 지워주도록 하자.
이제 라이팅을 하고,.. 구워준다.
카페도 라이팅을 하고…
이렇게 베이킹이 죄다 까맣게 나올 땐
숨겨둔 오브젝트가 렌더링되고 있거나
타겟이나 원본 중 하나가 면이 뒤집혀있거나(주로 원본)
설정에서 기술하였듯 차원에 균열이 생기며 다른 차원의 모습이 섞이는 모양새.
빨간 단면을 셰이더처리할 예정이므로 유니티로 넘어가보자.
아..으….. 생각보다 해상도가 많이 깨진다. 별 수 없다. 정리를 하는 수밖엔…
2.16
메쉬 리토폴로지 + UV정리 중…
UV팩하기 전에 잘 나올것과 그렇지 않은 것들을 구분해 둔다. 텍스처를 기준으로 위쪽은 정비율, 왼쪽은 0.5비율, 아랫쪽은 그냥 폴리곤만 있는 수준의 것들이다. 심이 너무 쪼개지는 것도 미미하긴 하지만 어쨌거나 퍼포먼스에 영향이 있기 때문에, 가급적이면 덩어리를 합쳐주며 작업을 한다.
베이킹할 때 원본 메쉬를 그대로 굽는 것이 머티리얼 구조와 충돌을 일으킨다. 결국은 베이킹 원본과 리토폴로지 메시를 구분하는 편이 좋다. 이런 오브젝트 관리가 늘 골칫거리였는데 이번 기회에 확실히 정해두도록 하자. 더구나 이번 스테이지는 서로 다른 2개의 배경이 섞이는 일이라 더 어렵게 느껴진다.
이제 컷아웃용 메쉬를 베이킹해보자.
베이킹할 때 UV가 너무 작으면 검은 색으로 칠해버린다는 사실을 알아냈다. 이 현상이 좀 의문스러운데, 어쨌거나 아무리 안쓰는 면이라도 너무 작게 펴주면 안된다는 교훈을 얻었다. 또한 하이폴리 메쉬를 모두 배치한 후엔 아무리 작은 사항이라도 변경하지 않는 편이 좋다.
2.17
테이블 위에 쌓여있는 책들은 플랜이다. 이는 기존에 제작한 맵에서도 비슷하게 적용되었고, 폴리곤을 하나라도 아껴야 하는 예전 개발방식에선 매우 효율적으로 여겨져 왔다. 하지만 지금 와서는 조금 의문이 생긴다. 여기엔 512×512텍스처를 한장 썼는데, 셰이더가 다르므로 당연히 드로우콜이 하나 더 들어간다. 그런데 여기에 사용된 폴리곤을 계산해보니 12,000개 정도밖에는 안된다. 요즘 컴퓨터 사양뿐 아니라 모바일 사양을 고려하더라도 스태틱메쉬의 12,000개는 그렇게 큰 숫자는 아니다.
셰이더교체비용(드로우콜) + 512×512텍스처
12,000개의 폴리곤, 메인 텍스처의 품질 저하
지금 와서 수정하긴 좀 늦었지만, 한 번 쯤 생각해볼 문제다.
폴리곤을 모두 정리하고, UV또한 정리했다. 12만개 정도 되던 폴리곤은 24,000개 정도로 줄었고 UV의 최적화를 통해 해상도도 더 올라갔다. 그리고 데이터가 깨끗하다는 것은 마음의 안정을 준다는 측면에서도 긍정적인 것 같긴 하다. 시간이 문제지.
덕분에 뒷면은 텅텅 비었다.
유니티 적용결과. 확실히 깔끔하다.
차원의 단면은 어디서 본 것 같은 효과로 셰이더를 새로 만들어준다.
그라디언트 조금 깔아서 저 쪽 세상의 대기를 표현해준다. 생각보다 손 많이 간다. 창문엔 뭘 깔지..
2.18
위협적인 붉은 무언가, 그리고 AI가 그린 도서관 나머지 부분.
난 AI를 그렇게 즐겨쓰는 편은 아니다. 왜냐면 재밌는 건 다 지가 하고 재미없는 일거리만 내게 던져주기 때문이다. 하지만 이렇게 재미없는 부분을 맡기는 데 사용하기엔 정말 좋다.
다음 스텝은 뒤 쪽을 좀 더 정신없게 만들어 줄 날아다니는 책. 책은 보기와는 다르게 이음새 부분의 리깅이 제법 어려운 물건이다.
팔랑팔랑. 내일은 이걸 게임에 붙여보자.
2.19
붙이는 거야 금방하지. 싶었는데 하이고… 쉬운게 없다. 참말로
2.20
어제의 스샷에서도 볼 수 있듯, 책의 스케일이 다른 현상이 있어 살펴보니 0번책만 오브젝트 트랜스폼이 적용되어 있었다. 어제 타임오버를 앞두고 허둥지둥 찾다가 20분 넘게 원인을 찾지 못했는데, 멀쩡한 컨디션으로 차분히 원인을 찾으면 문제는 의외로 쉽게 해결된다. 휴식이 필요한 이유랄까.
스테이지에 따라 조명, 돌, 먼지, 얼음등의 색은 모두 다르다. 캐릭터가 그 장소에 있다는 느낌을 주기 위해 환경 정보엔 이런 것들이 포함된다.
어제 밤새도록 UV를 폈었는데, 패킹하는 과정에서 크기를 잘못 재는 바람에 작업이 허사가 됐다. 잘 보이는 부분에 조금이라도 더 큰 면적을 할당해 주기 위해 카메라에 잘 보이는 부분과 그렇지 않은 부분을 나눴었는데 이것이 UV가 패킹되며 뒤섞여버린 탓이다.
허무한 기분으로 재작업을 해야 하는 상황이라, 너무나 귀찮은 나머지 그냥 SmartUV로 대충펴는 방법을 시도해봤는데, 생각보다 효과가 괜찮다! 물론 이 방법은 수작업을 해주는 것보다는 최적화에 좋지 않은 방법이지만, 잔돈은 아껴봐야 잔돈이다. 아무래도 빈곤한 사양아래서 개발하던 오래된 절약습관이 여전히 몸에 남아있는 게 아닐까 싶었다.
이제 바닥을 그려야 하는데, 에이콘에서조차 마땅한 바닥 텍스처를 찾지 못했다. 괜찮아보이는 게 있었는데 클립스튜디오 전용으로 제공되어 쓸 수가 없었다. 그래도 그리기가 싫어서 호환되는 걸로 하나 구입한게 있었는데
…사진이다. 어쩐지 2천원밖에 안하드라.
그래서 이것도 AI를 돌려보기로 하자. 문제는 Depth컨트롤넷이 필요하다는 것이다. 안쓰고 싶었는데…으…설치법이야 마음먹고 검색하면 금방 나온다.
블렌더의 미스트패스가 곧 뎁스이다. 이전 프로젝트에서 이를 이용해 배경을 작업했었기 때문에 사용법은 알고 있다. 세팅이 귀찮아서 미뤘지만, 이젠 해야 할 것 같다.
컨트롤넷은 정상적으로 깔렸건만…
아닌데..이거 아닌데… 일단 자고 내일 다시 도전해보자.
2.10
결국 컨트롤넷은 필요가 없었다. 스테이블 디퓨전도 작업에 자유도를 줄 때 최고의 결과물을 뽑아낸다. 어쩐지 실제 사람과 닮아있다.
이제 블렌더에서 해야 할 일은 끝났다. 유니티로 넘어가자.
처음에 적용하면 원래 엉망진창이다. 오늘은 여기까지. 내일 다듬어보자.
2.11
배는 물에 떠서 조금씩 움직여야 한다. 그런데 너무 신나게 움직인다.(…)
물 반사 코드를 바꿨다. 이미 비오는 배경에서 물웅덩이를 표현하기 위해 만들었던 코드였지만 어쩐지 정확하지 않아서 대충 마무리했던 코드였다. 문제는 반사벡터였다. 역시 챗GPT는 답을 알고 있다.
2.12
옅은 물안개를 추가. 오늘은 늦잠을 잤기 때문에 이걸 만드니 타임오버. 흑흑
2.13
캐릭터의 색감을 조절하고, 날아다니는 버드나무 씨앗을 추가하고, 최종 조정을 통해 나루터 배경 완료. 벨이 나왔는데 노딱 안받았어! 오!
익스포트 과정에 문제가 생겼다. Sketchup에서 뽑아낸 FBX는 블렌더에서 읽어들이지 못한다. FBX는 ASCII와 Binary의 2가지 종류가 있는데, 스케치업은 ASCII를 사용하는 모양이다. COLLADA를 쓰자.
덕분에 알게 된 사실이 하나 있는데, 익스포트 속도는 COLLADA파일이 속도가 더 빠른 것 같다.
…그런데 임포트 상태가 안좋다.
FBX Converter를 써보자
..는 매핑이 안넘어온다. 환장
그나마 OBJ가 가장 깔끔하게 넘어오는 것 같다. 버텍스도 잘 합쳐져 있고.
스케일은 1:1000
이 모델이 그런 것인지, 제작 자체가 크게 된 것인지는 알 수 없다. 어쨌거나 데이터를 활용할 수 있기만 하면 된다.
배 한척 쓰려고 씬 전체를 산 것이 좀 낭비같아 보이긴 하지만, 그걸 모델링하려면 몇시간이 걸린다. 이렇게 많은 삽질을 했어도 어쨌거나 구입이 싸다.
오랫만에 하려니 모든 게 새롭구나. 허허(…)
생각보다 스크롤이 짧다. 정말로 배 한척을 넣으니 끝나버렸다.
오른쪽은 버드나무로 채울 것이다. 이건 애니메이션을 해야 해서 꼼짝없이 그려야 한다.
2.6
버드나무는 크기가 꽤 크기 때문에 줄기까지 그릴 필요는 없겠다.
나무를 그리는 방법은 별 게 없다. 나뭇잎을 몇가지 그리고 이걸 복사해붙인다.
버드나무는 된 것 같고, 이제 풀을 심어보자. 버드나무야 파는 곳이 없어서 직접 그렸지만, 풀은 이야기가 다르다. 구매해서 쓰자.
요걸 쓸 것이다.
퀄리티가 엄청 좋다. 하지만 게임과의 색감을 통일하기 위해 톤을 조금 눌러주어야 한다.
톤을 맞춘 모습. 왼쪽 2개는 Plant셰이더, 오른쪽의 2개와 버드나무는 일반 cutout으로 묶은 후 본 애니메이션을 할 것이다.
2.7
이걸 잘 오린 후에
본을 심고 애니메이션을 하자.
2.8
이걸 애니메이션하고 나니 움직임이 생각보다 단순해서 그냥 기존의 Plant를 사용하는 게 나을 것 같다는 생각이 들었다. 스킨드 메쉬는 최적화면에서 불리한 점이 많다. 데이터 자체도 무겁지만, 인스턴싱도 안된다. 테스트가 좀 필요하다. 유니티를 켜자
에이…비슷해보인다. 그럼 굳이 본을 심어서까지 제어할 필요가 없을 것 같다. 처음에 본 베이스로 작업을 하려고 했던 이유는 줄기가 흐느적거리는 기계적인 움직임(식물의 줄기는 생각보다 뻣뻣하다!)이 싫어서였는데, 어차피 이미지 자체가 한 덩어리로 되어 있는 이상 큰 의미는 없어 보인다.
식물의 움직임 강도는 버텍스 컬러로 제어되기 때문에 배치 전 반드시 확인해야 한다. 그렇지 않으면 아주 귀찮아진다.
2.9
바위를 어떻게 표현할까 꽤 많은 고민을 했다. 2D? 3D? 나루터는 안개가 자욱한 형태로 구상하고 있기 때문에, 조명이 강하지는 않을 것이다. 그렇다면 명암이 덜 표현되는 2D가 나을까? 아니면 스크롤에 따른 형태가 확실하게 보장되는 3D가 나을까? 이 선택은 머티리얼의 선택으로 이어지고 결국 텍스처를 어디에 귀속시키는가? 에 대한 문제로 이어진다. 만약 3D로 할 것이라면 텍스처를 베이킹할 때 프로젝션을 할 것인지, 본체를 직접 사용할 것인지, 또한 메쉬의 UV를 어디서 짜를지, 뒷면이 보이지 않으므로 바위마다 뒷면최적화를 해줄 것인지, 만약 그렇다면 메쉬의 모양이 적합하지 않으므로 리메쉬를 해줄 것인지…등등에 대한 문제로 이어진다. 2D라면 바닥에 드리워지는 그림자를 어떻게 처리할 것인지, 주변 사물과의 정확한 그림자 관계를 위해 프로젝션을 할 것인지, 그냥 그려 복붙을 할 것인지등에 대한 문제가 남는다.
결국 이 프로세스는 추후에 만들 배경의 제작 프로세스에 영향을 끼친다. 기존의 작업들은 손가는대로 만들어서 제작방식이 모두 달랐으므로 이를 정립해줄 필요가 있었다. 무엇보다 중요한 것은 작업이 쉬워야 한다.
이제 선을 긋자. 고민 끝에 정립한 방법은 아주 입체적인 오브젝트 외엔 3D를 최소화하는 것이다.
Plant – 식물. 그 중에서도 움직임이 필요한 경우.
잡풀들, 약하게 휘날리는 깃발
Opaque – 알파가 필요없는 오브젝트와 터레인.
3D로 된 오브젝트, 바닥
Cutout – 알파가 필요한 오브젝트.
프로젝션 오브젝트, 바위, 그 외 움직이지 않는 오브젝트들, 혹은 Skinned메쉬
Unlit – 포그가 적용되지 않는 원경
Plant는 제작이 끝났다. 바위는 Cutout에 해당된다. 즉, 그려서 표현할 것이다. 나루터 맵은 이 Cutout에 들어갈 내용이 바위밖에 없어서 다소 애매한 면이 있지만, 어쨌거나 다른 맵에서 범용적으로 사용할 수 있는 규칙을 정립하는 것이 중요하다. 나무는 향후 SkinnedMesh를 사용할 것이므로 인스턴싱의 도움을 받지 못해 사실 Plant를 사용하든 Cutout을 사용하든 상관이 없다. 엄밀히 말하면 계산이 적은 Cutout이 좋다. 하지만 그래봐야 Unlit을 사용하는 시점에서 이미 아껴봐야 잔돈이다. 이럴 경우엔 최적화를 일부 포기하고 작업의 편의를 높이는 것이 좋다.
바위는 처음부터 다 그리기엔 귀찮다. 일단 AI를 돌려 질감을 뽑고
이를 가져와서 짤라 리터칭한다.
소스가 모자라면 i2i를 돌려 비슷한 분위기의 바위를 얼마든지 뽑아낼 수 있다.
하지만 이를 편집하려면… 역시 고전적인 기술이 필요하다. 드로잉, 스탬프, 컬러조절…같은 기본기들.
연휴끝! 작업을 이어보자. 잡기 애니메이션은 각 캐릭터에게 매칭되는 애니메이션을 지녀야 한다. 앨리스를 예로 들면, 앨리스가 닐리에게 잡힐 경우, 오로라에게 잡힐 경우, 도레미에게 잡힐 경우…등등의 모든 상황에 대응되는 애니메이션이 필요하다. 캐릭터 추가가 힘든 이유이다.
이 작업은 기본적으로 애니메이션 복붙이긴 한데, 애니메이션 키의 회전모드와 신장, 세컨더리 애니메이션등이 모두 달라 각 캐릭터에 딱 맞게 달라붙지는 않는다. 때문에 그냥 단순 노가다 작업의 연속이다. AI는 뭐하니, 이런 거 안해주고.
달래까지 완료.
2.1
키가 작아서 손 많이 가는 오로라. 애니메이션 복붙으로는 오로라의 키가 다른캐릭터와 호환되지 않는다.
그래서 이런 조절을 해주어야 한다. 아휴..손 마이 간다.
Flatten의 캡처방식이 조명을 다소 왜곡하는 현상이 있었다. 때문에 이와 관련된 로직을 변경. 이제 배경에 맞는 색감으로 잘 적용된다.
캐릭터를 추가하며 코딩을 완전히 손떼고 있던 건 아니다. 그럼에도 몇몇 코드는 생소하다. 그나마 스킬을 추가하며 계속 봐왔던 코드가 도움이 될 것이다. 시작해 보자.
동시잡기상황은 많이 발생하진 않지만, 0.26테스트 때 종종 발견됐다. 때문에 이 처리는 대충 처리했었는데, 그마저도 버그가 있었다. 이걸 처리하고 있노라니 또 새로운 버그가 발견돼서 함께 수정했다.
1.22
숲 배경에서 승리 보석이 잘 안보인다는 이야기가 있어서 윤곽선을 추가
이제 액션버튼을 누르면 미러전이 아니어도 2P컬러를 선택할 수 있다.
시작할 땐 38개. 이제 29개가 남았다. 물론 이슈하나의 크기가 제각각이긴 하지만서도…
1.23
타임오버.
1.24
수정하면서 버그가 늘고 있다..!
1.26
선택화면에서 3D캐릭터를 보여주기 위해서는 미리 로딩을 해놓아야 한다. 최고 13캐릭터가 한 번에 메모리에 올라가야 하는데, 테스트해본 바로는 캐릭터 하나에 약 0.5초의 로딩시간이 필요하다. 하지만 같은 캐릭터를 로딩할 경우엔 거의 시간이 소모되지 않는다. 텍스처를 줄이면 좀 나을까? 흐음… 다음에 테스트해보자.
버그는 다 잡았다. 연휴가 끝난 후엔 모든 캐릭터간 잡기 호환이 되도록 노가다 작업을 할 시간이다.