viewimage.php?id=2abcdd23dad63db0&no=24b0d769e1d32ca73cec87fa11d0283141b58444220b0c04398dc02aecd206e5c64d6aecc3f7ea34713d699136314b63b0486bc0678fe6de3b0cbae7e36e744b991dc4

횃불 박으면

viewimage.php?id=2abcdd23dad63db0&no=24b0d769e1d32ca73cec87fa11d0283141b58444220b0c04398dc02aecd206e5c64d6aecc3f7ea34713d699136314b63b0486bc0678fe6db6c04e5e8e161234bde3581


viewimage.php?id=2abcdd23dad63db0&no=24b0d769e1d32ca73cec87fa11d0283141b58444220b0c04398dc02aecd206e5c64d6aecc3f7ea34713d699136314b63b0486bc0678fe6d43d0ee4bcb43b274b87a18f


viewimage.php?id=2abcdd23dad63db0&no=24b0d769e1d32ca73cec87fa11d0283141b58444220b0c04398dc02aecd206e5c64d6aecc3f7ea34713d699136314b63b0486bc0678fe68a6e0aeabbe73d274b4ebe15


viewimage.php?id=2abcdd23dad63db0&no=24b0d769e1d32ca73cec87fa11d0283141b58444220b0c04398dc02aecd206e5c64d6aecc3f7ea34713d699136314b63b0486bc0678fe6d93c5eecbbe76c284bbfd440


viewimage.php?id=2abcdd23dad63db0&no=24b0d769e1d32ca73cec87fa11d0283141b58444220b0c04398dc02aecd206e5c64d6aecc3f7ea34713d699136314b63b0486bc0678fe6883e5becedb13c774be259b4



viewimage.php?id=2abcdd23dad63db0&no=24b0d769e1d32ca73cec87fa11d0283141b58444220b0c04398dc02aecd206e5c64d6aecc3f7ea3435683cf83036486548d2108f5e7b8a3a73476b36680f20



아직도 최적화 관련해서 갈 길이 먼 것 같음. 진짜 하루종일 파고들어서 


딥 프로파일링

27회 3800ms -> 24회 750ms

1회 137ms에서 1회 31ms까지 줄여놨음



viewimage.php?id=2abcdd23dad63db0&no=24b0d769e1d32ca73cec87fa11d0283141b58444220b0c04398dc02aecd206e5c64d6aecc3f7ea34713d699136314b63b0486bc0678fe6dd690ae8ebe46a214b0d8ab9


viewimage.php?id=2abcdd23dad63db0&no=24b0d769e1d32ca73cec87fa11d0283141b58444220b0c04398dc02aecd206e5c64d6aecc3f7ea34713d699136314b63b0486bc0678fe6d8670ee5bae56a204b980b64


청크마다 빛 데이터를[16,16,16]로 저장시키고 옆 청크에서 그 정보를 참조 할 수 있게 하고 싶었는데,

청크 업데이트가 병렬로 처리되서 그렇게 하면 안되거나 의미가 없음. 진짜 과거의 나에게 격렬하게 따지고 싶음.


아무튼 핵심은 옆 청크에서의 빛이 내 청크까지 전달되는건데, 옆 청크의 계산된 데이터 같은건 없음.


일단 내 게임의 구조상, 청크 메쉬를 로드중 빛을 계산할 때는, 옆 청크의 메쉬가 없더라도, 옆 청크의 정보는 반드시 존재하고 있음.

빛은 최대 8칸 퍼져나갈 수 있음. 나중에 좀 더 늘릴수도 있고.


내 청크가 16,16,16 크기일 때, 상하좌우전후로 8칸씩 늘려서 32,32,32 의 빛 정보 배열을 만들어줬음.

태양빛을 제외하면, 빛은 최대 8칸 퍼지기 때문에, 이 밖에 있는 모든 물체는 내 청크의 빛에 영향을 끼치지 못함.


다시 말해, 이렇게 하면 옆 청크에서 정보를 읽기만 할거니깐, 청크 로딩이 병렬로 처리되어도 문제가 없음.




빛 전파 알고리즘 개념은 간단함.


초기에 빛 블록을 큐에 넣어주고 주변을 체크해서 어두우면, 주변 블록의 빛 값을 조정 후, 그 블록들을 다시 큐에 넣어줌.

큐가 빌때까지 반복하면 됨.



문제는 최적화.

최소 수천만회 이상 돌아가는 핵심 부분들이 있음.

평소라면 에이 뭐 이 쯤이야 하는것조차 수천만회 돌아가면 성능에 어마어마한 영향을 끼침.


가장 핵심적인 역할을 했던게 뭐냐면

3차원배열->1차원배열

청크 로드시 주변 26청크의 참조를 생성하고, 로드가 완료되면 참조를 해제해주기.




솔직히 아직도 크게 잘못되어있음. 원래 이렇게 렉걸릴 부분이 아닌데..




가장 최근

viewimage.php?id=2abcdd23dad63db0&no=24b0d769e1d32ca73cec87fa11d0283141b58444220b0c04398dc02aecd206e5c64d6aecc3f7ea34713d69fc5a324c62d670482fcb5560fdd90db909f9fa0b97ccd33b6b


여기. (x,y,z)의 위치의 블록이 투명한 지 알아보는 부분에서 총 시간의 50%를 잡아먹음. GetBlockID

그리고 저 호출 대부분은 초기 빛 배열에 값을 세팅 해줄 때 일어남.

맨 위부터 블록을 마주할 때까지 내려오는데, 그동안 매 블록마다 호출됨.


빛 계산이 무거운건 아닌것 같음



뭔가 번뜩이는 아이디어가 필요함.

빛 배열을 저장/로드하는건 지금 신경쓰고 싶지 않은게,

저장해봤자, 새로운 청크가 로드될때 여기는 정보가 없어서 새로 로드 해야함.

그리고 새로운 청크가 로드될때가 렉이 걸리는 시점임.



i,k,j 는 각각 -16 ~ 31 사이의 값이고, 

이 함수는 현재 청크와 그 옆청크까지의 어떤 블록이던 반환해주는 함수임.

옆 청크에 대한 참조는 이미 배열에 가지고 있고, 

i,k,j값을 통해 목표 청크와 목표 위치를 구해서 블록 ID를 가져옴.


 int GetBlockID(int i, int k, int j)

    {

        Chunk cnk = chunk;

        int x = 0, y = 0, z = 0;

        

        if (i < 0)

        {

            x--;

            i = 16 + i;

        }

        else if (i >= 16)

        {

            x++;

            i = i - 16;

        }

        if (k < 0)

        {

            y--;

            k = 16 + k;

        }

        else if (k >= 16)

        {

            y++;

            k = k - 16;

        }

        if (j < 0)

        {

            z--;

            j = 16 + j;

        }

        else if (j >= 16)

        {

            z++;

            j = j - 16;

        }       


        int ind = (x + 1) * 3 * 3 + (y + 1) * 3 + (z + 1);


        return cnk.GetNearChunk(ind).GetBlock(i, k, j).ID;

    }




와 나 글 쓰다가 엄청난 아이디어가 떠올랐어

사실 3시간동안 머리 정리하면서 쓰고 있었거든 ㅋㅋ


청크의 데이터를 로드함과 동시에, 각 (x,z)좌표마다 가장 높이있는 불투명한 블록을 2차원 배열에 로드해주는거야 (파일에 저장/로드가 아님!)

추가로 전체 순회할 필요도 없이, 지형을 노이즈 함수로 로드하는 도중에 확인하고, 마지막으로 변화블록 리스트를 순회해주면 끝


이 정보를 이용하면 빛을 세팅할 때 맨 위부터 내려오면서 계속 이 블록이 불투명한지 체크할 필요가 없겠지

첫번째 불투명한 블록이 어딘지 한번에 알 수 있으니깐 70만번 가까이 호출되는 함수를 0번으로 100% 줄일 수 있을 듯.



힘들어..