[💬] [7mb] 개발 기록

[아(115.21)]

그냥 일기같은거.

카메라의 기준에 따른 타일 부분 생성.

구형 프로토타입

프로파일러를 보면 가시밭길이다.

비효율적인 호출 제거하고 책임을 분리하여 쓰레드의 일종인 타이머한테 일을 넘겨서 따로 처리함.

저 타일들이 스프라이트가 아니라 3d 메쉬고

새로운 위치로 이동할때 기존의 버텍스들을 대기열에 담고

추가된 새로운 타일을 위해 다시 재활용 하는 방식임.

문제는 유니티가 버텍스 65000개 이상 생성을 막아놨고

(SetVertices 메서드나 vertices프로퍼티가 65000개 이상의 벡터3배열을 받으면 예외처리가 발생함.)

어쩔수 없이 구현하게됨, 물론 결국 언젠가는 해야했을건데 그날이 빨리 찾아왔다.

얼핏 그냥 보기에는 정점을 별로 안쓸거같지만

인접한 타일과 연결되도록 구현하려고 생각해낸게

타일을 아래와 같이 4분할을하는거고

[0][1]

[2][3]

(사진의 빨간 네모 처진 저만큼의 영역이 한 타일임)

그리하여 같은 타입의 타일이 인접한 8방향을 검사하여

0~3번의 쿼드의 메쉬 uv좌표를 이동시킴

예를들어 x0,y0자리 타일 기준으로 x0,y1에도 자신과 같은 타일이있으면

x0,y0타일은 0번과 1번의 uv만 수정하는 방식임.

해당 텍스처는 각 방향에 맞는 타일의 그려져있음.

이과정에서 한 쿼드당 4개의 정점이 필요하고 또다시 한 타일에 4개의 쿼드가 필요하게됨

그럼 타일이 조금만 많아져도 한순간에 버텍스 허용치를 초과하게 될것이고

예외처리가 발생해서 메쉬가 날아가버리는 잠재적 문제가 있었을거임.

그리고 사실 지형이 위의 짤처럼 입체적인게 아닌 아래와같은 유사한 평면구조였음

이런형식이였는데 하다보니까 "분위기를 위해 빛도 넣어보고 유니티 기능좀 써볼까?" 해서

빛을 넣어봤더니 가로로 줄이가서 안되겠다 싶어

위처럼 입체적으로 구현하게 됨.

근대 그후 반복 테스트 과정에서 캐릭터가 어느정도 이상 움직이면 메쉬가 사라져버리는것이다.

이건 뭔 개같은 현상이냐 하면서 좆나 두뇌 풀가동하고 고민하기 시작했음

아무리 생각해봐도 유니티가 최적화를 위해서 오브젝트가

메인 카메라 일정범위 이상 넘어가면 숨기는거 같았는데

이건 내 통제 밖인것같아서 정말 걱정이 많았다.

그럼 트랜스폼 이동 시키면서 하면 될거같았지만

그러기엔 트랜스폼 위치값도 검사해야되고

의도한 대로 구현한 코드에 다른 뭔가를 주렁주렁 달아놓는건

정말 나중에가서 복병이 나올지도 모르고 코드도 더러워지고

통제력도 약해진다는 생각에 검색해보기로 했고

이걸 뭐라고 검색해야할지 몰라서 그냥 뻘검색하다가

뽀록으로 연관있어 보이는 내용을 찾았고 그게

메쉬의 바운드라는것이었다.

그냥 렌더링에 포함시키겠음에 대한 여부를 결정하는 범위를 지정하는거같았고

그러고보니 UnityEngine.Mesh자체에도 RecalculateBounds라는 메서드를 본거같았다.

처음 저걸 발견했을때는 정말 좆같았는데 그에 비해 간단하게 해결되서 다행임.

그후 또 개 좆같은 버그가 나오는거임

그전에는 걍 캐릭터를 위로만 자주 올라갔었는데

어쩌다가 시작하자마자 방향키 아래를 누르고 내려가면서 발견한건데

아래짤처럼 분명 지붕이 반투명인데 캐릭터가 가려지는 알수없는 버그가 나옴.

처음에는 정말 별거 아닌줄 알고 메터리얼의 셰이더를 막 이것저것 바꿔보고 해봤는데도

해결안되서 반복적으로 플레이해보면서 한가지 특이사항이 보였는데

y축 0이상부터는 저 버그가 안났고 그 이하부터는 저렇게 가려지는거임.

정말 그간 있었던 버그들과는 일관성도 없고

코드에서도 문제될게 전혀없어서 좆나 삽질 여행이 또 시작됨.

다른사람도 그럴지는 모르겠지만 보통 본인 삽질특징이

본인이 코딩한것과 단 하나라도 관련없는 버그가 터지면

정말 별에별것을 의심하게 되고 좆나 관련없는거를 건드리게됨.

이때가 정말 제일 병신짓 빈도가 높아질때임.

그리하여 존나 관련없어보여도 혹시나해서 하는 마음에 z-fighting을 의심해봄

일단 셰이더를 둘러보기시작했고 그과정에서

뜬금없이 셰이더 코드 열어봤는데 빡머갈이고 엔비디아 셰이더 레퍼런스가 좆방대해서 까무러침.

어찌저찌 익셈플 코드 긁어오고 해봐도 문제는 여전히 해결안되고

검색해봐도 굉장히 비슷한 질문글 단 하나가 있긴한데 답글도 없었다.

그래서 그냥 좀 그때부터 생각없이 또다시 반복 플레이를 하면서 문제점을 찾아내기 시작했는데

정말 참 운이 좋게도 새로운 특이사항이 보였는데

저게 항상 가려져있는게 아니라 해당 타일의 반정도 내려오면

캐릭터가 나타났다가 또다시 반을 더지나면 가려지는거였다.

그에 관한 연관성을 찾다보니 지형 메쉬가 갱신될때와 타이밍이 일치하는 거임.

그러나 이게 왜? 하면서 또다시 두뇌 풀가동을 시작함.

그러다가 왠지 이걸거같다 해서 건드린게 메쉬 바운드고

RecalculateBounds라는 유니티 메서드는

메쉬의 범위만큼만 딱 정해서 바운드를 생성하는거라 생각하고

일부러 넉넉하게 넓게 바운드를 할당해봤는데

첨에 안되서 바운드 센터도 음수 위치에 맞춰 바꿔보니까

이게 뭐람, 엄청 잘되는거임.

아무튼 저거 문제 해결할동안에는

해결하고도 "이게 왜 연관성이 있는거지" 하고 막상 의문이 드는데

지금 글쓰면서 생각하지만 아마 카메라가 좆나 가까워서 그런거같기도 하더라.

참고로 유니티의 RecalculateBounds는 좀 느리니까

직접 갖고 있는 일종의 bounds정보가 있으며 계산이 간단하다면

되도록 그걸 할당하는것이 좋다.

[도적코볼트(w9716www)]

정보글 개추

[aigoia(jongsu114)]

꽤 독특하네 ㅎㅎ 3D툴로 2D를 이런식으로 만들수가 있구나...

[율냥이(alszmtm)]

어쩌다 이런방법을 선택하게 된거임?

[ㄴ율냥(115.21)]

유니티 입문당시 예제 게임 튜토리얼에서 소개해주는 지형 메쉬를 코드로 생성하는 방법을 배우면서 그게 발단이됐고 3d모델을 이용해서 연결형 벽을 구현하는중에 모델링 할게 너무많아서 생각해낸개 개당 4개를 분리하여 별도 교체하는 방식이었고 두 방법이 혼합된게 지금의 저 방법임, 결국 알고있는 정석이 없다보니 경험적으로 익숙한 방법을 택한게된거야