[📜일지] 언리얼 복셀 멀티스레딩

[익명(ppukku999)]

유니티에서 만들었봤던 경험이 있어서 망정이지, 아니였으면 진짜 죽어나갔을것 같음.

멀티스레딩으로 초고속 이동 (1배속)

핵심은 이렇게 빠르게 로딩된다가 아니라, 최종적인 복잡한 구조로 만들었는데 오류가 안난다는 점

당연히 위아래 방향으로도 무한함.

지난번에 유니티로 이런 시스템을 만들고나서 한참 후에 후회되는 부분들,

아 이런식으로 만들었으면 더 좋았을텐데, 이런 부분들을 적용해봤음.

별것 아닌것같아보여도 멀티스레딩을 병렬로 처리하느라 진짜 고생 많이했음.

지난번에는 모든걸 병렬로 처리했는데,

이번에는 청크로더, 청크데이터로더, 지역로더 이 3개의 스레드만 존재하고, 이 3개는 병렬로 돌아가되, 각각은 직렬로 처리하도록 했음.

왜 직렬이냐면, 그래야 나중에 편해지고, 성능이 좋아진다는걸(특히 빛계산이 들어간다면) 경험했기때문에.

어떻게 했냐면, 플레이어가 이동해서 청크/청크데이터/지역 중 뭐가 됐던 업데이트가 필요할 때, 

예를들어 9개의 청크가 로드되어야 한다면, 9개를 리스트에 넣어주고, 다시 리스트를 스레드 큐에 넣어줌.

스레드 매니저는 큐를 체크하면서 현재 스레드가 돌고있지 않고, 큐에 리스트가 존재한다면, 스레드를 생성해서 큐의 리스트 하나를 전달해줌.

그러면 스레드에서 리스트 안의 9개의 일을 처리하고 다시 매니저가 스레드를 할당해주고 반복하면서 직렬로 처리함.

왜 이렇게 해야했냐면, 스레드에 작업을 할당해주는걸 메인스레드에서 하기 때문에, 

만약 한번의 작업에 청크 하나씩만 넘겨주게된다면, 1프레임에 작업 1개밖에 처리하지 못함.

그래서 한번의 작업에 청크를 여러개를 넘겨줘서 그런 문제를 해결해줌.

이게 저번에 유니티로 만들면서 계속 이렇게 하면 직렬로 잘 처리되지 않을까? 하고 고민했었던 구조임.

데이터는 Region, Chunk, ChunkData 3개가 있는데

c++ 클래스 자체는 무조건 플레이어 주변에 정확히 로드되어있고, 그 안의 데이터를 스레드에서 로드하는 구조로 만들었음.

문제는 로드와 언로드였음.

유니티에서는 일단 풀링을 사용하고있기도 했고, 가비지콜렉터 덕분에 삭제 타이밍을 안잡아도 됐었는데,

여기서는 청크 데이터와 지역데이터 등은 순수 c++클래스라 삭제 타이밍을 잡아야 했음.

더 큰 문제는 데이터들이 큐에 담겨서 차례로 천천히 생성되는 반면, 삭제는 그 즉시 처리가 가능하기 때문에,

자기 자신의 데이터를 로드하는 도중에 자기 자신을 다른 스레드에서 삭제하는 경우가 생김.

그리고 청크에서 데이터 생성중에 자신과 연결된 청크데이터에 접근을 하는데 그 둘은 처리되는 스레드가 다르기 때문에, 삭제가 곤란했음.

c#에서는 그냥 모든 참조가 사라질때 삭제되서 다른 스레드에서 이용중에 삭제할 가능성이 없지만,

c++에서는 삭제타이밍을 잘못잡으면, 다른 스레드에서 이걸 이용중이기때문에 무조건 크래시가 뜸.

병렬처리라서 진짜 머리가 아팠는데, 일단 해결 한 것 같음.

일단 당연하게도 삭제처리를 큐에 넣고 천천히 처리함.

자기자신이 로드되지 않았다면 삭제를 미룸.

스레드에서 작업을 할당해줄때, 유효한 작업인지 판단을 함.

유효한 작업이라면, 여기와 연결된 다른데이터를 삭제하지 못하도록 막아둠.

스레드의 작업이 종료됬으면 이제 막아둔걸 풀어줌.

진짜 애매한데, 삭제는 메인스레드에서만 하고, 스레드 매니저 역시 메인스레드에서 돌아가기 때문에, 

유효한 작업이다 == 나와, 나랑 연관된 데이터는 현재 존재하는 데이터이며, 삭제큐에 들어있지 않다 -> 연관데이터 삭제 금지 -> 스레드에서 데이터 로드 -> 삭제 허용

이런 식으로 돌아갈 수 있을것 같음.

데이터가 로드 된 이후에는 연결된 다른 데이터에 접근할 일이 없기 때문에, 삭제되던 어떻게되던 아무 상관 없음.

그 3개의 데이터를 병렬로 처리하는 이유는, 로드 타이밍을 분리시켜뒀음.

분리시키는 이유는 생각해둔 절차적 생성 방식이 1차 생성/2차 생성/3차 생성으로 구분되어있기 때문에기도 하고, 이러면 일반적으로 더 빠르기 때문이기도 함.

청크 데이터를 로드하는 시점에는 연관 지역데이터는 이미 로드되어있을거고,

청크를 로드하는 시점에는 청크데이터가 이미 로드되어 있을거임.

물론 엄청 빠르게 이동하면 이런 이점이 희미해지겠지만, 

그래도 일반적인 경우에는 이동할때 청크가 나타나는데 걸리는 시간에 청크 데이터, 지역데이터가 로드되는 시간이 포함되지 않음.

그리고 자세한 절차적 생성을 할 예정이기 때문에 데이터 로드시간이 상당히 길것으로 예상됨. 그래서 더더욱 이런 방식으로 처리하고 싶었음.

사실 아직 불확실함 

어떤 문제가 남아있을지 걱정이 되네.

제발 오류 안났으면

아무튼 기본 베이스는 거의 완성한것 같음.

데이터 생성 함수같이 나중에 작업해야 하는 함수는 비어있는 상태로 전부 적용되어있어서 나중에 알고리즘만 짜면 됨.

이제 언리얼에 어느정도 적응한 것 같음

오랜만에 하루종일 해서 뿌듯하다

다음목표는 오늘한거 마무리하고, 수동으로 텍스쳐 아틀라스 만들기랑, LOD 시스템

멀리있을수록 여러 블록을 하나의 큰 블록으로 표현해서 시야거리를 거의 무한하게 늘릴 수 있도록.

[김메가(scw973108)]

[익명(218.234)]

니가 일짱해라

[익명(116.47)]

점점 진화하누 ㄷㄷ 추천박는다

[익명(124.50)]

유니티에서 모든 Monobehavior 오브젝트는 메인스레드에서만 접근가능한 걸로 알고 있는데, 언리얼에서도 UObject에 대해 그런 제한이 있음?

[익명(ppukku999)]

스레드에서 메쉬 생성하다가 크래시뜸. 유니티처럼 아예 막는건 아닌데 정확히 어떤 구조로 이루어져있는지 모르는 상태에서 수정을 가하면 위험할듯. 읽기는 가능한것 같음

[HD(developerhd)]

[익명(118.235)]

참 잘했어요

[코사크(sharsets)]