5.28

유니티의 셰이더는 프로퍼티의 이름이 변하면 정보가 초기화된다. 때문에 애써 맞춰놓은 색상정보가 날아가기 쉽다. 원론적으로 이야기하자면 프로퍼티의 이름이 변하면 안되지만, 개발하며 어디 그게 쉬운 일인가. 이름으로 판독하는 처리가 얼마나 많은데.

때문에 나중에 닥쳐올 불행을 미리 대비하는 마음으로 레벨데이터 매니저를 새로 만들었다. 씬의 번호에 따라 미리 세팅된 조명과 먼지의 색정보등을 넣어주는 방식이다.

하지만 작업을 하고 나니 문제가 또 있는데, 셰이더가 늘어난다…! 별로 바람직하지가 않다. 프로퍼티로 구분하면 안될 것 같고, 파티클이름으로 구분해야 할 것 같다. 그럼 파티클을 만들 때마다 이름에 신경써야 하잖아…싶었는데 별수가 없다. 다시 되돌리자.

많은 고민 끝에 배경과의 호환을 위해 파티클의 게임오브젝트에 이름을 예약어로 사용하기로 했다. dust, stratum, soil, crack의 이름은 예약어로 사용된다. 리소스의 이름엔 항상 앞에 대문자를 붙이는 규칙이 있으니, 원칙적으로는 충돌하지 않는다. 그 외 HDR로 지정된 컬러프로퍼티엔 리니어변환을 해주어야 한다. 그런데 이게 정확하지가 않다… 이에 대해 조금 조사를 했는데 최종 화면에 나오는 컬러를 구하는 법은 톤매핑까지 거치며 매우 복잡해지는 것 같다. 뭐 그렇게 중요한 것은 아니고 비슷하게는 나오니, 넘어가기로 하자.

이제 스테이지별로 이펙트가 다른 색깔로 표현된다.

머티리얼을 정리하고, 발도장 이펙트도 완료…했는데 너무 후져서 사거리 좀 늘려야 할 듯

5.29

아휴. 안끝나…

어류겐할 때 검기 모양이 동그란게 안어울려서 셰이더 로직을 수정하자.

하고 싶은 걸 해봤는데 별로 안예쁘다…되돌리자.

요 기술엔 둥그런 먼지를 추가.

공중에서 Slam데미지를 맞을 경우의 처리가 되어있지 않아서 처리했다.

데미지 모션이 정말 많다. 포스트는 이펙트 작업인데, RnD작업이 훨씬 더 많아.

5.30

이래저래 삽질이 많았던 작업프로세스는 점차 분명해져간다. 모든 문제는 결국 어떤 방향으로든 해결되기 마련이다. 그렇다면 이 쯤에서 효율성에 대해 한 번 더 고민을 해보자.

지금은 이펙트를 Left/Right를 분리해 만들고 있다. 파티클시스템은 단순히 스케일-1로 해결되지 않는 경우가 많기 때문이다. 이거… 정말 안될까?

스케일을 좌우반전했을 때, 문제가 되는 부분은 파티클이미터가 기울어져 있는 경우이다. 이것은 트랜스폼이 아니고 이미터의 정보이기 때문이다. 그럼 트랜스폼을 기울이면 될 것 아닌가?

…는 전혀 엉뚱한 값이 튀어나온다. 안되나 보다.

위치는 반전이 된다. 그렇다면 기울어져 있는 이미터의 각도만 바꿔주면 되는 것 아닐까?

이미지를 바꿔보니 문제가 하나 더 있다. 이미지는 Flip되어야 한다. 일단 여기까지 적용가능 여부를 확인해보자.

오? 일단 요기까지는 작동한다. 시운전 끝났으니까 실전에 적용해보자.

2시간 가까이 시도했…지만, 실패했다. 고려할 게 너무 많다. 그렇다고 조건을 줄이면 이펙트 제작에 제약이 많아진다. 이거 정말 안되네. 에이…

오늘의 깨달음. 프로퍼티의 HDR은 단순히 숫자를 1이상 쓸 수 있도록 해주는 것이 아니다. Color프로퍼티를 좀 일원화시켜보고자 이를 적용해봤는데, 그냥 컬러는 톤매핑을 거치지 않은 러프한 색을 내보낸다.

방어 이펙트도 작업완료. 맞은 후엔 배우는 것이 있다.

5.31

일단 이렇게 앨리스의 이펙트를 완료. 파란색 머리는 2P가 헛갈려서 바꿔놓은 것이다.

이펙트 시스템을 구축하며 헤집어 놓은 코드들 때문에 버그가 많이 쌓였다. 이를 한 번 정리하고 가는 편이 좋아보인다.