[📜일지] 복셀 빛 마무리, 최적화

[익명(183.96)]

사실 마무리라기엔 아직 문제가 하나가 더 남음

계단이나 반블록은 버텍스에 색 입히는걸 따로 처리해줘야 함.

현재 일반블록은 버텍스마다, 주변 블록의 빛의 평균값을 넣어주고 있음. 자연스럽게 보이라고.

반블록의 경우에는, 

중간에 있는 버텍스에 색을 입힐 때 그 점의 위 아래 버텍스의 빛값을 다시한번 평균을 내서 적용시키면 될 것 같음.

계단도 마찬가지로 처리하면 될 듯.

이게 마인크래프트의 빛,그림자

내 추측이지만, 마인크래프트는 게임 시간, 태양의 방향에 따라, 한쪽면의 빛값을 보정해주는 것 같은 느낌이 듬.

그리고 내가 구현한 거

모서리 그림자

빛 데이터가 [32,32,32]에 저장되어 있음

블록의 윗면을 그릴 때, 메쉬에 버텍스를 추가하면서, 해당 버텍스의 빛 값을 넣어야 함.

윗면을 그릴 때는 버텍스의 빛값에 해당 버텍스를 공유하는 위에있는 4블럭의 평균값을 넣어주면 되고,

오른쪽 면을 그릴때는 버텍스의 빛값에 해당 버텍스를 공유하는 오른쪽에 있는 4블럭의 평균값을 넣어주면 됨

블록에는 항상 최저의 빛값이 들어가기 때문에, 

빛값을 구할 때 사용하는 4블럭에 블록이 포함될 때, 아무리 밝은 빛이 있어도 평균값을 내기 때문에 그림자가 생기는 효과가 생김.

그래서 이렇게 모서리에 그림자가 생겨남

오늘은 최적화를 해옴.

우선 태양빛은 아랫 방향으로 내려올 때 빛의 감소가 일어나지 않음.

그리고 불투명한 블록에 의해 막히면, 그 밑으로는 태양이 내려오지 못함.

빛 데이터는 내 청크 16,16,16 그리고 모든 방향으로 8칸만큼 확장시켜서 주변청크에서의 빛을 반영할 수 있도록 함.

빛 데이터를 초기화 해줄 때 

기존에는 체크할 맨 윗 블록을 태양으로 설정하고, 아래로 쭉 내려가며 불투명한 블록이 나올때까지 빛값 16을 넣어주고, 각각 업데이트큐에 담아줬음.

불투명한 블록을 찾으면 거기부터는 빛의 최솟값을 넣어주면서 바닥까지 내려갔음.

이 과정에서 불투명한 블록인지(또는 빛 블록인지) 체크하는게 하나도 안무거운 알고리즘인데, 굉장히 많이 반복되다보니 성능을 엄청 잡아먹었음.

그래서 청크의 데이터에 빛을 내는 블록은 따로 데이터를 가지고 있도록 수정해줬음.

그리고 해당 청크의 모든 x,z 좌표에 존재하는 가장 높은 불투명한 블록에 대한 데이터를 가지고 있도록 해줬음.

이렇게 하면 빛 데이터를 초기화 할 때, 순회하면서 각 블록이 어떤 블록인지 전혀 알 필요가 없게됨.

가장 높이있는 불투명한 블록까지 빛 값 16을 쭉 넣어주고, 그 블록 밑부터는 전부 최솟값으로 설정하면 됨.

그 다음, 빛을 내는 블록을 순회하면서 횃불같은걸 데이터에 적용시켜주면 준비는 끝.

빛의 전파는 엄청 단순함

업데이트 큐가 빌 때까지 반복

하나씩 꺼내서 주변 6블록과의 밝기를 비교함. 주변 블록이 밝기가 더 낮으면, 그 블록의 밝기를 나보다 조금 낮게 수정해주고, 그 블록을 업데이트 큐에 넣어줌

이게 끝

근데 이것만으로는 부족함.

아까 첫 불투명한 블록을 만날때까지 계속 16으로 세팅해주고, 업데이트 큐에 모든 블록을 넣어줬잖아

이렇게 되면 불필요한 계산이 엄청 많아서 성능을 또 많이 잡아먹음.

완전 텅텅 빈 공간이면 업데이트 큐에 쓸데없이 30000개가 넘는 값이 들어가버림

근데 만약 이렇게 업데이트 큐에 넣어주지 않는다면, 혹은 가장 아래에 있는 몇개의 블록만 업데이트에 넣어주면 빛의 전파에 문제가 생김.

빨간 블록에서만 업데이트를 발동시키는데, 위쪽 방향이 나와 밝기가 같기 때문에, 위쪽방향의 블록에 업데이트를 전파할 수가 없음

결과적으로 초록색 블록에는 주변 블록에서 업데이트가 발생하지 않았기 때문에, 밝기가 기본값인 0이 되버림.

그래서 이걸 어떻게 해결했냐면

아까 가장 높이 있는 불투명한 블록에 대한 정보를 항상 가지고 있게 했잖아

현재 체크하는 블록이 (x,y,z)이고, 태양이 쬐는 블록일 때,

전후좌우 4방향의 (x,z)좌표의 가장 높이 있는 불투명한 블록의 높이값과, 현재 체크하는 중인 블록의 y값을 비교해서

체크중인 블록의 y값이 더 크면, 내 옆은 태양이 쬐는 텅텅 비어있는 공간인게 확실하기 때문에 업데이트를 발동할 이유가 없음.

반면에 더 작다면, 내 옆은 100% 확률로 밝기가 0이거나 블록이기 때문에 업데이트를 발동하면 됨.

다시말해 만약 절벽이 존재할 때, 그 절벽과 맞닿은 태양이 쬐는 빈 블록들만 업데이트 큐에 넣어주면 되기 때문에 

순회 한번에 비교연산 4개만 추가해서 필요없는 연산을 엄청나게 걸러줄 수 있음.

옆이 어떤블록인지 확인하지 않는 이유는, 그게 생각보다 성능을 많이 잡아먹기 때문. 

내 블록을 가져오는 함수에서는 좌표를 -16~32까지 받아서 만약 옆청크의 블록이라면 옆청크의 블록을 반환해주거든

아까도 말했듯이 빛 배열은 내 청크 16,16,16 그리고 모든 방향으로 8칸씩 확장시켰기 때문에 옆 청크의 블록에 접근이 가능해야 함.

필수적인 기능인데, 그냥 내 청크 안의 블록을 받아오는것보다는 무거움.

아무리 미리 배열에 값을 구해두고 그 배열을 이용해서 빠르게 처리한다고 한들,

청크 하나당 32768회 돌아야 하고, 한번에 289개의 청크가 업데이트 되니, 거의 천만 회 돌아야 함.

그래서 빛 데이터를 초기 세팅해줄 때 해당 위치에 어떤 블록이 있는지 한번도 체크해주지 않고 세팅을 완료할수 있도록 한거임

이제 렉 진짜 하나도 안걸림 완전 신남 ㅋㅋ

다만 지금 내가 병렬로 청크를 처리해서 최적화 관련해서 엄청 고생했을 뿐임.

직렬로 처리를 한다면 최적화문제는 없을 것 같음.

어떻게 어떻게 옆청크의 이미 계산한 데이터들을 이용해서 지금처럼 주변청크를 포함한 32x32x32배열이 아닌 18x18x18배열에서 계산이 끝날지도 모름.

이러면 계산량이 8배 가까이 줄어들 듯.

단점이라면 하나의 청크에서 빛을 여러번 계산해야 하는 경우가 생기겠지. 주변 청크 6개가 각각 로드될때마다 계속 빛을 수정해야 하니깐.

근데 또 직렬로 옆 청크의 데이터를 이용하는 방식은 헷갈림

안해봐서 모르겠는데, 개념적으로 쉬운건 그냥 주변 청크 블록정보를 받아와서 독립적으로 32x32x32배열에서 처리하는게 이해하기 쉬운듯

a와 b가 인접 청크일 때

a와 b의 빛을 계산하려면

a를 계산하고

a의 빛정보가 반영된 b를 계산하고

a의 빛정보에 b의 계산된 빛정보를 반영해야 함.

다행인 점은 빛정보 반영은 빛정보 초기 계산보다 훨씬 가볍다는 점

이 경우에 메쉬 생성은, 모든 청크의 빛계산이 완료된 이후에 해야겠지.

완료될때까지 반복해서 빛 정보가 수정되니깐 매번 반복해서 메쉬를 생성 할 수는 없잖아.

마인크래프트류 게임제작에서 최종보스급이였던 것 같음

[익명(211.198)]

짱이다

[익명(ksg502)]

오.. - dc App

[위스플(wlsh0310)]

꾸준히 이렇게하는게 진짜 멋져 - dc App

[위스플(wlsh0310)]

[익명(183.96)]

ㄳㄳ

[김메가(scw973108)]