[📜일지] 바이옴 시스템 완성, 블록 크기 제한

[익명(ppukku999)]

어제 생각했던 아이디어 구현결과

어제 생각했던 방법대로 했는데, 결과가 안좋았음. 여러 바이옴이 겹치는 구간에서 더러워짐.

각 버텍스에 머테리얼1, 머테리얼2와 lerp값을 줘서 정의해줬는데, 이렇게는 안되겠더라.

그래서 어떻게 했냐면

바이옴이 A,B,C,D,E가 있을 때, 각 꼭짓점에 바이옴 A,B,C,D,E가 포함된 비율을 독립적으로 구해서 더해줌.

자세히 설명하자면, 노이즈 함수가 두개가 있고 하나는 바이옴 A,B를 결정하고 나머지 하나는 C,D,E를 결정해주고, 각 노이즈 함수는 월드 전체를 커버해야 함.

노이즈 함수별로 독립적으로 할당하고 싶은 바이옴들 할당해주면됨. 노이즈1에서 A,B 결정하고 노이즈2에서 B,C결정해도 문제 없음.

좌표 (x,y)에 대해서 A,B,C,D,E의 비율을 저장하는 변수에 노이즈 함수에서 구한 A의 비율, B의 비율을 더하고, C,D,E의 비율도 더해줌

여기서 핵심인게, A가 0~ 0.5고 B가 0.5~1.0이면 0~0.4정도에서 A 100 B 0 을 더해주고, 0.4 ~ 0.6은 적당히 계산해서 A B 혼합을 더해주고,

0.6 ~ 1.0이면 A 0 B 100을 더해줘야 함. 그러면 바이옴 값이 좌표의 변화에 따라 서서히 변화함.

이제 두 노이즈에서 나온 값으로 바이옴의 값들을 전부 더해줬으면, 여기서 색을 구해야 함.

쉽게 가자면 그냥 바이옴별로 색을 할당해주고, 비율대로 조합해주면 됨. 

난 바이옴별로 윗면, 옆면의 색을 다르게 할당해줘서 버텍스의 노말을 이용해서 살짝 더 복잡하게 계산해줌.

엄청 부드러움.

참고로 반복되는 지형임. 한쪽으로 쭉 가면 이전에 있던 공간이 나올 예정

이제 부드럽게 바이옴 사이에서 색이 바뀌는데 기존의 알고리즘에 문제가 생겼음.

기존에는 쉐이더 내부에서 색을 판별해서 문제가 없었는데, 이제 색을 cpu에서 정하고 쉐이더로 넘겨주게되니깐, 

정육면체를 설치하는 등 각 삼각형에 대한 노말의 재계산이 필요하게 되면, 이전에 구해둔 바이옴 색이 더이상 유효하지 않게 됨. 

아까 말했듯이 노말에 따라 이게 윗면인지, 옆면인지 구분해서 색을 조합해주거든. 노말이 바뀌면 색도 바뀜.

그래서 필요에 따라 노말을 바꿔서 다시 계산해주도록 만들었는데, 다행히 별 문제는 없는 듯.

그동안 속 썩이던 버그도 발견함.

메인스레드에서 돈다고 아무 생각없이 두 코루틴 사이에서 하나의 메모리를 이용하고 있었음. 

메쉬를 메인스레드 바깥에서 해제해줄 수 없기 때문에, 난 스레드 내에서는 큐에 넣어주고, 스레드가 다 돌면 메인스레드에서 큐에 쌓인 메쉬들을 해제해줌.

근데 이때 큐에 쌓인 메쉬를 처리해주는 코루틴이 두 종류가 있는데 이 두개가 같은 tmp변수를 이용하다보니 한쪽에서 작업중인데 반대쪽에서 초기화를 시켜버림.

스레드 쓸때는 이런거 철저하게 관리하는데 등잔밑이 어둡다고 코루틴에서 이러고 있는거는 상상도 못했음.

오늘 가장 고생한건 따로 있는데, 진짜 엄청 고생했는데 결과가 마음에 안들어서 폐기했음.

진짜 스트레스받다가 죽을거같아서 그냥 원래대로 되돌림. 해결이 안되더라. 지금 쓰러질거같아.

실제 게임 내에서는 큰 구는 설치/제거를 못하게 만들 생각임.

더럽고 설치후 곤란해진다는게 이유가 제일 크고, 게임플레이중 짜증만 나는 요소일 것 같음. 

완벽하게 도형이 계산되면 무난하겠는데, 알고리즘 특성상 메쉬가 이쁘지 않게 생성될때가 꽤 많음. 근데 이게 너무 커지니깐 너무 더러워짐.

반면에 작은 구들은 맘에 듬. 뭔가 귀여움.

이게 딱 감당 가능한 최대 사이즈인듯. 반지름 : 1미터