클로버 클럽

3.4

도레미의 배경이다. 카지노 역시 생각보다 자료가 많지 않기 때문에 선택의 폭이 좁지만, 에이콘에 나름대로 어울리는 어셋이 있었다. 다행스러운 일이다.

가운데 홀에서 싸우도록 하고 싶기 때문에 인테리어 공사를 좀 해야 한다.

블렌더로 가져와 불필요한 것들을 지워주고 재배치.

그리고 라이팅.

사이드뷰로 놓으니 도박시설이 눈에 잘 띄지 않아서 아쉽다. 바닥 반사는 어차피 표현안될테고… 간접광이나 잘 표현됐으면 좋겠다. 이제 로폴화해보자.

3.5

로폴화 중 타임오버

3.6

로폴화 후 적용. 스팟라이트가 캐릭터는 덮고 싶고, UI는 덮고 싶지 않아서 요리조리 머리를 굴린 결과 아.. 유니티엔 큐가 있었지! 싶어서 적용했더니 잘 된다. 큐는 요래저래 쓸모가 많다.

실내 흡연이 허용되는 시기

3.7

레벨컬러를 채워놓고 완료!

담배연기 가득한 어두컴컴한 도박장, 추후 뒤쪽에 구경꾼들을 그려넣어야 한다. (언제가 될 지는 모르겠지만, 이게 참 큰일이다.)

이로서 목표했던 배경제작도 모두 끝났다. 이제 배경을 만들며 튀어나온 버그들을 잡아보자.

설원

벨의 배경이다. 헌데 눈은 표현이 꽤 어려운지 아니면 수요가 적은지, ACON에서는 자료를 찾기 힘들거나 찾아도 쓸만하지 않은 것들이었다. 킷배시3D의 상황도 마찬가지다.

자연물은 블렌더마켓이 좀 더 쓸만한 게 많다.

https://blendermarket.com/products/winter-trees-and-bushes-collection

https://blendermarket.com/products/low-poly-zone-of-snow-rock-pack-a-2020

https://blendermarket.com/products/quick-snow?search_id=37447826

https://blendermarket.com/products/quick-landscape

https://blendermarket.com/products/blendsnow

최종적으로 구입한 것들은 다음과 같다.

마침 겨울할인 중이다. 오굳

최근엔 회사에서도 어셋을 활용한 작업을 하고 있는데, 이 작업을 하다보면 배경은 확실히 제로베이스에서 작업하는 것이 비효율적이라는 것을 알게 된다. 게다가 타인의 작업물을 살펴보다 보면 배우는 것이 참 많다.

물론 어셋을 늘어놓는다고 씬이 되는 것이 아니기 때문에 프로젝트에 맞게 이리저리 손보아야 한다.

어셋을 가져와서 조명을 세팅하고 렌더.
와. 놀라운 퀄리티다. 그냥 바로 써도 되겠는데…?! 별달리 수정할 게 없어 보인다.

2000원주고 산 눈밭도 잘 작동한다. 싼 맛에 사긴 했는데, 기대이상이다.

3.1

오브젝트를 배치하다 보니 뒷부분이 좀 허전했다. 원래는 AI를 돌리려 했었지만, 그보단 처음 눈여겨 봐두었던 터레인을 미리 사두는 게 어떨가 싶어 구매했다.

https://blendermarket.com/products/quick-landscape

애드온의 용량이 20기가나 한다. 전에 샀던 눈 머티리얼도 그렇지만 이 터레인도 Displace를 사용한다. 하이폴 렌더에서는 이런 작업방식이 표준인가? 어쨌거나 원경을 표현하는데는 제 격이다.

오….원경은 뒷판에 조금 보이는 것이 아까울 정도로 멋드러지게 잘 뽑혔다.

바닥 굽고, 배치끝. 이제 유니티 타임

펄~펄~ 눈이 옵니다~

오늘의 깨달음. 빌보드는 인스턴싱이 되지 않는다?! 코파일럿의 이야기이기 때문에 완전히 신용할 수는 없지만, 카메라를 향하는 것 자체가 행렬재계산 과정이 들어가기 때문에 인스턴싱이 불가능할 것 같기는 하다. 따라서 인스턴싱을 하려면 Mesh를 사용해야 한다. 눈 같은 경우 굳이 카메라를 따라가지 않아도 되기 때문에 이 경우엔 Plane메쉬를 임포트해서 사용할 수 있다.

그런데 언리얼에선 GPU 인스턴싱이 되던데.. 그건 뭐지…?

설원 배경 제작 완료. 유튜브 알고리즘은 대체 어떤 구조이길래 어떻게 섬네일을 저렇게 극적인 장면으로 잘도 뽑아내는지…

AI는 테스트용으로 쓰고 있는 단순 막고 치기인데, 오로라에게 연타기술이 있다보니 하마터면 질뻔(…)

이제 마일스톤 2는 도레미의 카지노 배경만을 남겨두고 있다. 다음으로 넘어가자.

배틀퀸 팬아트 from Discord

Lugra님께서 그려주신 닐리. Idle모션에 자신의 개성을 더한 그림같네요.

Flateri님께서 보내주신 닐리(+납작해지는 닐리?)

아직 작업 중이라는 GuGumny님의 그림. 납작해진 상대는 그리신 분의 자작 캐릭터일까요?!

Universal Observer님께서 보내주신 그림들이예요! 통통한 오로라군요!

전에 7호를 그려주신 MaruTheMaruhog님의 그림. 캐릭터 선택 모션같은 느낌입니다.

대저택

2.20

프리오리의 배경이다. 로판 열풍 때문에 대저택은 어셋이 많다. 인테리어가 필요한 것은 아니므로, 외관만 있는 걸로 찾아보자.

게임뷰의 시점이 낮으므로 대 저택 전경이 모두 들어오는 편이 좋겠다. 세번째걸로 선택.

스케치 작업 중. 어셋에 생각보다 프랍이 많지가 않다. 있는 걸로 잘 꾸려보자.

2.21

식생을 준비하자. 테마는 가을

2.23

주인이 죽고 모두 떠난 흉흉한 대저택이므로, 관리가 안된 정원이어야 한다. 정원사의 손길을 벗어난 회양목은 무성히 키가 커져있을테고, 바닥에는 잡초가 즐비할 것이다. 그런데 관리가 잘 된 정원보다 이런 자연스러운 정원이 더 예뻐 보인다.

좀 더 을씨년스럽게 보이기 위해 듬성듬성 키가 작은 묘목들을 추가. 땅을 다듬으니 한결 더 초췌해 보인다. 렌더가 후져보이는 것은 EEVEE이기 때문이다.(위의 스샷은 Cycle)

2.24

원경을 AI돌려서 채워넣고, 나머지 배경을 최종 데이터로 베이킹 중… 타임오버.

2.25

뭔가 횅-하다.원근도 별로 없는데 길을 너무 넓게 만든 것 같기도 하다. 거의 끝났지만, 아직 일부 디테일이 조금 남아있다.

2.26

어셋으로 받은 풀이 사용하는 내내 에러를 내거나, PSD용량이 너무 커지는 버그가 있었다. 세이브 에러가 나지 않았다면 몰랐을 것이다. 용량이 크면 저장이 되어도 유니티에서 실시간으로 갱신되지 않아 작업이 불편하다.

회사 지인이 해결책을 찾아주어 공유

https://bbirukim.tistory.com/entry/%ED%8F%AC%ED%86%A0%EC%83%B5-PSD-JPG-PNG-%EC%9A%A9%EB%9F%89-%EB%BB%A5%ED%8A%80%EA%B8%B0-%EB%B2%84%EA%B7%B8-%ED%95%B4%EA%B2%B0%EB%B0%A9%EB%B2%95

포스트 프로세스는 현재 메인렌더러 피처에 넣어서 레벨별로 켜고 끈다. 볼륨이 스테이지에 귀속되지 않고 메인렌더러 피처에 기생하고 있는데, 별로 좋은 방법같지는 않다… 언리얼에는 그냥 볼륨을 추가해주면 되는데 유니티에서는 등록에 일련의 과정이 필요한 모양이다. 당장이야 스테이지가 몇 개 안되니 이렇게 쓰더라도 추후 개발할 때는 자세히 알아보는 편이 좋겠다.

어쨌거나 완료! 다음은 벨의 배경이다.

도서관

2.13

도서관은 오로라의 배경이다. 돌핀팬츠 하나만을 보고 거의 아무 생각 없이 만든 캐릭터인데(심지어 처음엔 용을 타고 다녔다.) 이제는 설정을 붙일 때가 됐다.

배틀퀸은 배틀스톤을 소유한 자를 일컫는 말이고, 정식 절차를 거쳐 계승될 수 있다. 하지만 부정 승계를 받은 현재의 배틀퀸이 자신을 위해 이 힘을 사용했고, 그 결과 차원이 갈라지며 차원 관리자의 두통을 유발시켰다. 오로라는 이 난리를 조사하기 위해 파견된 조사관인데, 거의 온종일 도서관에서 지내야만 하는 그녀에게 바깥나들이는 신나는 것이었다. 오로라의 임무는 차원의 균열이 생기는 원인을 찾을 것. 때문에 이야기는 차원의 균열이 생긴 도서관에서 시작된다…라는 긴 이야기.

일단 도서관에서 어셋을 사고, 임시배치, 균열부분은 예전에 연습삼아 만들어둔 카페를 사용할 예정이다.

에이콘에서 요렇게 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분 넘게 원인을 찾지 못했는데, 멀쩡한 컨디션으로 차분히 원인을 찾으면 문제는 의외로 쉽게 해결된다. 휴식이 필요한 이유랄까.

스테이지에 따라 조명, 돌, 먼지, 얼음등의 색은 모두 다르다. 캐릭터가 그 장소에 있다는 느낌을 주기 위해 환경 정보엔 이런 것들이 포함된다.

도서관도 완료! 이제 프리오리의 대저택으로 넘어가자.

나루터 #2

2.9

어제 밤새도록 UV를 폈었는데, 패킹하는 과정에서 크기를 잘못 재는 바람에 작업이 허사가 됐다. 잘 보이는 부분에 조금이라도 더 큰 면적을 할당해 주기 위해 카메라에 잘 보이는 부분과 그렇지 않은 부분을 나눴었는데 이것이 UV가 패킹되며 뒤섞여버린 탓이다.

허무한 기분으로 재작업을 해야 하는 상황이라, 너무나 귀찮은 나머지 그냥 SmartUV로 대충펴는 방법을 시도해봤는데, 생각보다 효과가 괜찮다! 물론 이 방법은 수작업을 해주는 것보다는 최적화에 좋지 않은 방법이지만, 잔돈은 아껴봐야 잔돈이다. 아무래도 빈곤한 사양아래서 개발하던 오래된 절약습관이 여전히 몸에 남아있는 게 아닐까 싶었다.

이제 바닥을 그려야 하는데, 에이콘에서조차 마땅한 바닥 텍스처를 찾지 못했다. 괜찮아보이는 게 있었는데 클립스튜디오 전용으로 제공되어 쓸 수가 없었다. 그래도 그리기가 싫어서 호환되는 걸로 하나 구입한게 있었는데

…사진이다. 어쩐지 2천원밖에 안하드라.

그래서 이것도 AI를 돌려보기로 하자. 문제는 Depth컨트롤넷이 필요하다는 것이다. 안쓰고 싶었는데…으…설치법이야 마음먹고 검색하면 금방 나온다.

블렌더의 미스트패스가 곧 뎁스이다. 이전 프로젝트에서 이를 이용해 배경을 작업했었기 때문에 사용법은 알고 있다. 세팅이 귀찮아서 미뤘지만, 이젠 해야 할 것 같다.

컨트롤넷은 정상적으로 깔렸건만…

아닌데..이거 아닌데… 일단 자고 내일 다시 도전해보자.

2.10

결국 컨트롤넷은 필요가 없었다. 스테이블 디퓨전도 작업에 자유도를 줄 때 최고의 결과물을 뽑아낸다. 어쩐지 실제 사람과 닮아있다.

이제 블렌더에서 해야 할 일은 끝났다. 유니티로 넘어가자.

처음에 적용하면 원래 엉망진창이다. 오늘은 여기까지. 내일 다듬어보자.

2.11

배는 물에 떠서 조금씩 움직여야 한다. 그런데 너무 신나게 움직인다.(…)

물 반사 코드를 바꿨다. 이미 비오는 배경에서 물웅덩이를 표현하기 위해 만들었던 코드였지만 어쩐지 정확하지 않아서 대충 마무리했던 코드였다. 문제는 반사벡터였다. 역시 챗GPT는 답을 알고 있다.

2.12

옅은 물안개를 추가. 오늘은 늦잠을 잤기 때문에 이걸 만드니 타임오버. 흑흑

2.13

캐릭터의 색감을 조절하고, 날아다니는 버드나무 씨앗을 추가하고, 최종 조정을 통해 나루터 배경 완료. 벨이 나왔는데 노딱 안받았어! 오!

이제 오로라의 스테이지로 넘어가자.

나루터

달래의 배경은 조선이기 때문에, 한옥이 필요하다. 하지만 킷배시3D에는 한옥이 없다. 그런데 마침 국가유산 디지털 서비스에서 한옥을 제공해준다.

https://digital.khs.go.kr/heritage/heriTage.do

그런데 여기서 다운받기는 매우 번거롭다. 이는 유니티 어셋스토어에서도 받을 수 있다.

https://assetstore.unity.com/publishers/86877

퀄리티는 좋다. 하지만 첫구상을 할 때 벽처럼 서있는 집이 꽤 답답하게 느껴졌기 때문에 구상을 변경하기로 했다.

달래의 배경을 무엇으로 하던 버드나무가 있는 풍경이면 좋겠다고 생각했다. 버드나무는 강가에 많으므로 배가 한 척 떠있는 간단한 나루터라면 좋겠다. 직접 모델링하기는 귀찮다. 배를 구해야 한다.

다시 Acon의 도움이 필요하다. 여기서 물건 참 많이 산다.

어… 창작자명이 좀 익숙하다…싶어서 살펴봤더니, 예전에 웹툰 그릴 때 샀던 배경작업자다.

이걸 사용했던 만화는 이거다.

https://ix.tistory.com/804

당시는 블렌더가 아니라, 3DS MAX를 썼었다. 이제 맥스는 불편해서 못쓴다.

어쨌거나 이건 Sketchup파일이니, 스케치업도 깔아야 한다.이를 FBX로 바꿔서 … 아휴.. 업계표준이 빨리 블렌더로 바뀌면 좋겠다.

익스포트 과정에 문제가 생겼다. 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를 돌려 비슷한 분위기의 바위를 얼마든지 뽑아낼 수 있다.

하지만 이를 편집하려면… 역시 고전적인 기술이 필요하다. 드로잉, 스탬프, 컬러조절…같은 기본기들.

돌과 풀은 배치했고… 스테이블 켠 김에 원경을 깔아보자.

오. 완전히 원한 이미지는 아니지만, 이것도 괜찮아 보인다. 귀신 나올 것 같고 좋아.

데미지 애니메이션의 추가제작

1.31

연휴끝! 작업을 이어보자. 잡기 애니메이션은 각 캐릭터에게 매칭되는 애니메이션을 지녀야 한다. 앨리스를 예로 들면, 앨리스가 닐리에게 잡힐 경우, 오로라에게 잡힐 경우, 도레미에게 잡힐 경우…등등의 모든 상황에 대응되는 애니메이션이 필요하다. 캐릭터 추가가 힘든 이유이다.

이 작업은 기본적으로 애니메이션 복붙이긴 한데, 애니메이션 키의 회전모드와 신장, 세컨더리 애니메이션등이 모두 달라 각 캐릭터에 딱 맞게 달라붙지는 않는다. 때문에 그냥 단순 노가다 작업의 연속이다. AI는 뭐하니, 이런 거 안해주고.

달래까지 완료.

2.1

키가 작아서 손 많이 가는 오로라. 애니메이션 복붙으로는 오로라의 키가 다른캐릭터와 호환되지 않는다.

그래서 이런 조절을 해주어야 한다. 아휴..손 마이 간다.

Flatten의 캡처방식이 조명을 다소 왜곡하는 현상이 있었다. 때문에 이와 관련된 로직을 변경. 이제 배경에 맞는 색감으로 잘 적용된다.

닐리의 Flatten모션이 좀 이상하다. 난 분명 모자를 뒤로 젖혔는데

실제로는… 적용이 안되고 있다. 이유가 뭘까…

원인 불명… 별로 중요한 문제는 아니지만 알고는 싶다..뭐지?! 뭐지?!

조사결과

yield return null;

이건 안되고

yield return new WaitForSeconds(Time.deltaTime);

이건 된다.

..?! 두개 같은 거 아녔어?

어쨌거나 오로라도 완료.

2.2

프리오리는 커다란 무기때문에 꽤 성가시다.

프리오리도 완료

벨도 납작

도레미까지 완료. 뒤로 갈수록 Caught스테이트는 완성된 경우가 많아서 일이 수월하다.

이제 추가 데미지 애니메이션까지 모두 끝났다!

다음은 배경을 추가해 보자.

버그 픽스

1.21

캐릭터를 추가하며 코딩을 완전히 손떼고 있던 건 아니다. 그럼에도 몇몇 코드는 생소하다. 그나마 스킬을 추가하며 계속 봐왔던 코드가 도움이 될 것이다. 시작해 보자.

동시잡기상황은 많이 발생하진 않지만, 0.26테스트 때 종종 발견됐다. 때문에 이 처리는 대충 처리했었는데, 그마저도 버그가 있었다. 이걸 처리하고 있노라니 또 새로운 버그가 발견돼서 함께 수정했다.

1.22

숲 배경에서 승리 보석이 잘 안보인다는 이야기가 있어서 윤곽선을 추가

이제 액션버튼을 누르면 미러전이 아니어도 2P컬러를 선택할 수 있다.

시작할 땐 38개. 이제 29개가 남았다. 물론 이슈하나의 크기가 제각각이긴 하지만서도…

1.23

타임오버.

1.24

수정하면서 버그가 늘고 있다..!

1.26

선택화면에서 3D캐릭터를 보여주기 위해서는 미리 로딩을 해놓아야 한다. 최고 13캐릭터가 한 번에 메모리에 올라가야 하는데, 테스트해본 바로는 캐릭터 하나에 약 0.5초의 로딩시간이 필요하다. 하지만 같은 캐릭터를 로딩할 경우엔 거의 시간이 소모되지 않는다. 텍스처를 줄이면 좀 나을까? 흐음… 다음에 테스트해보자.

버그는 다 잡았다. 연휴가 끝난 후엔 모든 캐릭터간 잡기 호환이 되도록 노가다 작업을 할 시간이다.