[주석번역] SmartGI: Global Illumination with Space Voxelization on Mobile:: Moving Mobile Graphics | 시그라프 2024 시리즈.

역자의 말. 2023년 리얼타임 렌더링 세션 내용도 대부분 주석번역을 하면서 "아~ 그렇구나" 하고 배울 것들과 더욱 더 깊이 탐색 해 봐야할 것들에 대한 리스트업을 했던 것이 벌써 1년이 지났습니다. 이번 소개글은 텐센트에서 발표 한 내용으로 모바일 하드웨어에서의 글로벌 일루미네이션 처리 방안에 대한 것이구요. 혹여 기억이 나실지 모르겠습니다만... AMD 랩에서 진행했던 브릭셀라이저와 단어가 많이 겹치는 부분이 있네요. 

AMD 브릭셀라이저에 대한 기사도 한번 살펴보세요.

[요약번역]GDC 2023 - Real-time Sparse Distance Fields for Games 파트-1 개요

 

[요약번역]GDC 2023 - Real-time Sparse Distance Fields for Games 파트-2 알고리즘

아무튼 부러운 부분입니다. 게임기업 내부에 코어 알엔디 부서가 있고 시그라프에서 발표 할 만큼 다양한 인재풀을 갖추고 있다는 점이 말이죠. 한국은 글로벌 시장에서 크게 성공을 이루지 못하고서는 년 알엔디 비율이 매우 낮은 것으로 보입니다. 중국은 원천기술쪽으로 눈을 돌리는 반면 한국은 여전히 제가공을 벗어나지 않는 것을 보면 오랫동안 산업이 이러한 형태로 발전 됬기 때문인 영향도 있어 보입니다. 그나마 클로스 시뮬레이션 쪽은 세계 최정상인 것은 고무적이지만 말이죠.

무빙 모바일 그래픽스 2024 텐센트의 GI 솔루션에 대한 간략한 내용과 AMD 의 브릭셀라이저를 비교하면서 읽어 보는 것도 재밌을것 같습니다.

---

 

Moving Mobile Graphics - SIGGRAPH 2024

제시 바커(Jesse Barker)가 모더레이터가 되어 다시 돌아오게 되어 기쁩니다. 올해 우리는 물리적 기반의 음영, 전역 조명 및 올해 처음으로 신경 그래픽 기술이 어떻게 모바일에 적용될 수 있는지 살펴봅니다. 또한 그래픽 스택의 현대화와 이를 통해 얻을 수 있는 이점에 대해 논의할 것입니다.

타이틀 : SmartGI: Global Illumination with Space Voxelization on Mobile

저자 : Shun Cao (Tencent)

오리지널 버전 PDF : https://community.arm.com/cfs-file/__key/communityserver-blogs-components-weblogfiles/00-00-00-20-66/siggraph_5F00_mmg_5F00_2024_5F00_SmartGI0722.pdf

안녕하세요, 여러분. 저는 텐센트 게임즈의 슌입니다. 오늘은 기존의 복셀화 방식과 차별화된 모바일 친화적인 글로벌 일루미네이션 솔루션에 대해 이야기하고자 합니다.

기술적인 세부 사항을 살펴보기 전에 왜 이렇게 해야 하는지, 무대 뒤에서 어떤 일이 있었는지 돌아보는 것이 도움이 될 수 있습니다.

 

우리 모두 알다시피 오프라인 베이킹 솔루션은 모바일 게임 엔진에서 매우 인기가 있습 니다. 우리는 처음에 베이킹이 필요 없고 다양한 고급 조명 효과를 구현할 수 있는 실시간 GI 솔루션을 제공하여 오늘날의 모바일 디바이스에서 완전히 역동적인 게임 장면 을 만들 수 있도록 하는 것이 목표였습니다.

 

우리는 콘솔과 PC에서 많은 실시간 글로벌 일루미네이션 솔루션이 빛을 발하는 것을 보았습니다. 우리 이러한 솔루션의 장단점을 면밀히 연구하고 자체 솔루션을 개발하 면서 많은 것을 배웠습니다. 예를 들어 복셀 기반, 다이나믹 프로브 기반, 서펠(Surfel:EA Sport) 기반 솔 루션은 모두 라이팅 캐시를 통해 씬을 단순화하여 표현하고, 이를 통해 표현된 라이팅 데이터를 빠르게 샘플링할 수 있게 해줍니다.
하지만 이러한 모든 옵션은 시각 효과에 내재적인 제한이 있거나 모바일 디바이스의 렌더링 성능에 심각한 문제를 야기합니다. 예를 들어 클립맵에 기반한 복셀화는 음영 지점이 멀리 있는 경우 복셀 정밀도가 충분 하지 않아 빛샘 현상이 발생할 수 있습니다. 동적 프로브 기반 솔루션은 빛샘이나 다크 스팟과 같은 문제를 해결하기 위해 동적 생성 및 오프셋 계산을 위한 정밀한 레이트레이싱이 필요합니다.
G버퍼를 기반으로 하는 서펠 솔루션은 카메라가 장면에 처음 진입할 때 장면 표현이 부족하다는 문제가 있습니다. 루멘은 이러한 문제를 모두 해결하지는 못할 뿐만 아니라, 성능이 매우 까다로운 SDF와 메시카드에 크게 의존합니다.

 

모든 분석 결과, 모바일 GI를 구현할 때 GPU 대역폭, 메모리 사용량, 모바일 하드웨어 성능, 전력 소비량 등의 요소가 중요하다고 판단했습니다. 모바일과 데스크톱 GPU 대 역폭 용량 간에는 여전히 상당한 격차가 존재하며, 이는 성능과 전력 소비에 중요한 영 향을 미칩니다. 메모리 사용량도 매우 중요한데, 과도한 메모리 사용량은 쉽게 충돌로 이어질 수 있습니다. 현재 하이엔드 모바일 GPU가 레이트레이싱을 지원하지만, 시장의 많은 디바이스가 이에 뒤처져 있습니다. 전력 소비가 높다는 것은 배터리 소모와 과열 이 훨씬 일찍 발생한다는 것을 의미하며, 이로 인해 GPU의 성능이 저하됩니다.

 

상당한 양의 학습과 고군분투 끝에 마침내 새로운 복셀 기반 알고리즘을 개발하게 되었 습니다. 이 알고리즘은 효율적인 스파스 옥트리와 캐시 친화적인 클립맵을 기반으로 다단계 복셀 기반 장면 표현을 달성하기 위해 구축되었습니다. 또한 레이트레이싱 워크로 드를 최소화하기 위해 루멘에 있는 스크린 프로브도 빼놓지 않았습니다. 또한 더 적은 수의 광선으로 조명을 더욱 단순화하기 위해 스크린 프로브 리프로젝션 기술을 도입하 여 이를 개선했습니다.

 

이제 가장 흥미로운 구현 세부 사항을 살펴 보겠습니다.

 

다음은 세 가지 주요 부분으로 구성된 솔루션의 전체 아키텍처 다이어그램입니다: Bricklizer , 파이널개더, 라이팅 컴포지션입니다. Bricklizer는 계층적 복셀화를 달성하 기 위한 우리의 접근 방식입니다.
FinalGather는 스크린 프로브를 기반으로 조명을 수집하고 스크린 프로브의 광원 정보에서 각 픽셀 셰이딩에 대한 조명을 보간하는 프로 세스입니다.
최종 조명 구성 프로세스는 직접 조명과 간접 조명을 오버레이하는 비교적 간단한 과정입니다.

 

먼저 Bricklizer 의 전반적인 프로세스를 살펴봅시다. CPU 측에서는 가시 범위를 기반 으로 브릭이라고 하는 후보 블록을 생성합니다.
이러한 후보 브릭은 후보 대기열에 배 치되고, 특정 우선순위에 따라 매 프레임마다 정해진 수의 브릭이 복셀화됩니다. 복셀 화 후에는 복셀의 특정 방향에 구멍을 메우고 두 복셀 사이의 유효하지 않은 면을 제거 하는 등 복셀화를 수정하고 최적화하는 프로세스가 있습니다. 브릭 복셀화가 완료되면 직접 광원을 샘플링하고 다른 복셀의 빛을 현재 복셀에 반사하는 등 조명 주입을 수행 합니다. 마지막으로 HDDA 알고리즘을 사용하여 화면 프로브의 광도를 계산할 수 있습 니다.

 

CPU의 핵심 데이터 구조는 다음과 같습니다. 초기화 중에 두 개의 얼로케이터가 주어 진 텍스처 크기인 BrickMappingAtlas와 BrickVisFacesAtlas에 따라 초기화되고, Bias를 기본 요소로 묶어 배열이 만들어집니다.
브릭의 몇 가지 중요한 파라미터는 다음과 같 습니다:
아틀라스 바이어스: BrickAllocator에서 얻은 바이어스로, 브릭매핑아틀라스에 매핑하 는 데 사용됩니다.
PageList: VisFacesAtlas에서 여러 브릭의 PageBias를 배열 형태로 유지합니다. b할당됨: 공간이 할당되었는지 여부를 나타내며 캡처가 완료되었는지 여부를 구분하 는 데에도 사용됩니다.
bRemove: 브릭은 스마트 포인터의 형태로 세 가지 목록으로 존재합니다. 브릭을 삭제 해야 하는 경우 이 플래그를 1로 설정한 다음 브릭테이블에서 삭제합니다.
나머지 두 리 스트는 처리하기 전에 이 플래그를 확인합니다.
PrimitiveList에는 벽돌과 교차하는 모 든 프리미티브가 포함됩니다.

 

GPU의 리소스 구성 구조는 다음과 같습니다. 표시된 3D 씬의 경우 BrickTexture는 각 브릭의 실제 저장 위치를 BrickMappingAtlas에 값으로 저장합니다. 기본 구성은 각 브 릭이 4x4x4m의 범위, 총 512x512x128m의 범위를 커버하는 것입니다.
BrickMappingAtlas는 데이터를 복셀 단위로 저장하며, 각 복셀은 32비트로 구성된 다 음 레벨에 대한 매핑 포인터를 저장합니다. 26비트는 X축과 Y축 오프셋을 나타내는 데 사용되며, 6비트는 각 면의 유무를 나타냅니다.
각 복셀 면의 실제 저장 캐리어는 BrickVisFacesAtlas라는 2D 아틀라스로, 모든 유효한 면(인접한 복셀이 비어 있거나 반 투명한 경우)을 밀도 있게 저장합니다.
각 브릭의 마지막 페이지에만 페이지 내 조각을 포함할 수 있으므로 공간 활용도가 매우 높습니다. 다음 두 개의 3D 텍스처는 HDDA 트 레이싱을 위한 보조 구조입니다.
그 중 BrickGroupTexture는 4x4x4 브릭을 컴포지션 단위로 사용하며, 각 그리드에는 브릭의 유무를 나타내는 데 사용되는 64비트 비트마 스크가 저장되어 있습니다. 마찬가지로 BrickBitMask는 BitMask를 사용하여 해당 복 셀의 유무를 나타냅니다.

 

씬 진입 또는 BrickReset으로 인한 전체 업데이트 외에 카메라 이동으로 인한 브릭 추가 와 메시 삭제, 추가, 이동 등 메시 변경으로 인한 업데이트 등 두 가지 변경 사항만 브릭 업데이트로 이어질 수 있습니다.
전체 업데이트와 카메라 이동 업데이트는 바운딩박스 를 기반으로 한 업데이트에 기인할 수 있으며, 바운딩박스의 경계가 브릭 경계와 일치 하도록 정규화해야 합니다.
그런 다음 내부의 각 브릭포에 대해 브릭테이블을 사용하여 해당 브릭이 존재하는지 확인합니다.
존재하지 않는다면 BrickPosSet에 추가합니다.
그런 다음 메시의 업데이트된 바운딩 박스를 가져와서 확장하여 그 경계를 브릭 경계와 정렬한 다음 브릭포스를 반복합니다.
이미 존재하는 경우 지우고 다시 생성해야 합니다 . 존재하지 않는 경우 후속 처리를 위해 BrickPosSet에 추가합니다.
업데이트를 기다리는 모든 브릭을 BrickPosSet에 추가한 다음 멀티스레딩을 사용하여 업데이트된 바운딩 박스와 교차하는 메시만 유지하면서 처음에 메시를 컬링합니다. 그런 다음 멀티스레딩 을 사용하여 모든 브릭과 프리미티브를 트래버스합니다. 트래버스 후 각 브릭은 자체 메시 목록을 가지게 되며, 메시와 교차하지 않는 브릭은 삭제할 수 있습니다. 나머지는 후보 브릭에 추가됩니다. 위의 단계에서 이 프레임에서 삭제해야 하는 브릭은 처리를 위해 더티 브릭에도 추가됩니다.

 

브릭을 업데이트한 후에는 현재 프레임에서 업데이트할 후보 브릭에서 k개의 브릭을 선택해야 합니다. 선택 전략은 카메라와의 거리 또는 뷰 프러스텀 내 거리와 같은 요소 에 따라 달라질 수 있습니다. 아래 그림과 같이 뷰 프러스텀 내의 브릭을 우선적으로 업 데이트한 다음 카메라에 더 가까운 브릭을 업데이트해야 합니다. 선택 후에는 두 얼로 케이터에 남은 브릭과 페이지가 있는지 확인하는 것이 중요합니다. 충분하지 않으면 재활용 프로세스 또는 메모리 확장 로직이 트리거됩니다.
재활용 프로세스는 업데이트 범 위 밖에 있는 모든 브릭의 공간을 회수합니다. 메모리 확장은 BrickMappingAtlas 또는 BrickVisFacesAtlas의 크기를 두 배로 늘리며, 원본 아틀라스 데이터를 해당 위치로 이 동하려면 추가 패스가 필요합니다.

 

복셀화 프로세스는 현재 상당한 최적화 잠재력을 가지고 있으며 시간이 가장 많이 소 요되는 부분이기도 합니다. 현재 전략에서는 각 브릭이 메시 목록을 기반으로 해당 메 시DrawCommand를 생성합니다. 그런 다음 각 브릭은 세 방향으로 복셀화되고, 그 결 과는 후속 처리를 위해 현재 프레임에 생성된 임시 3D 텍스처에 임시로 기록됩니다. 복셀화할 때는 멀티뷰와 세 방향 복셀화를 동시에 결합하여 DrawCall 및 기타 작업을 줄이는 것이 좋습니다.

 

각 브릭은 6~8페이지로 미리 할당되며, 각 페이지는 8x8픽셀을 차지합니다. 브릭내 복 셀에 대한 모든 유효한 면의 압축 및 할당은 여기에서 처리됩니다. 각 복셀의 면에 대한 특정 바이어스는 이 페이지 내에서 엄격하게 배열되어 마지막 페이지에만 사용되지 않 은 공간이 있을 수 있습니다. 8페이지가 부족하면 CPU에 피드백을 보내 추가 페이지를 요청합니다. 큰 단위의 페이지를 할당에 사용하는 목적은 효율적인 페이지 재활용을 촉 진하기 위한 것입니다.

 

조명 계산은 처리를 위해 직접 조명과 간접 조명의 두 부분으로 나눌 수 있습니다. 각 프레임에 대한 직접 조명을 계산하기 전에 후보 목록에서 직접 조명 계산을 수행할 k 개의 브릭을 선택합니다. 선택은 뷰 프러스텀 내 위치 또는 카메라와의 거리와 같은 정 렬 요소를 기반으로 할 수 있습니다.

 

직접 조명 계산에 앞서 하드웨어 활용도를 극대화하기 위해 브릭 내의 모든 유효한 면 을 VisBuffer로 압축합니다.
아래 다이어그램에서 볼 수 있듯이 위쪽 절반은 압축로직 을 나타냅니다. 브릭매핑아틀라스는 복셀에 해당하는 각 면의 저장 정보를 이미 저장하 고 있으므로 이 값을 직접 검색할 수 있습니다. 복셀이 존재하고 유효한 면이 3개인 경 우, 얼로케이터에 연속된 세 개의 공간을 요청하고 VisFacesAtlas에 있는 이러한 유효한 면의 인덱스 값을 버퍼에 기록합니다. 얼로케이터를 기반으로 스레드 그룹 수를 결정할 수 있으며, 각 스레드는 하나의 유효한 복셀페이스를 처리합니다. 기본 머티리얼 프로퍼티는 브릭아틀라스에서 가져 옵니다. ShadowMap이 유효하면 직접 샘플을 가져올 수 있지만, 그렇지 않은 경우 별 도의 ShadowRay를 캐스팅하여 점이 그림자에 있는지 확인해야 합니다. 그 후 일반 가중치, 광원 유형 및 재료 정보와 같은 요소를 기반으로 직접 조명을 계 산합니다. 마지막으로 결과가 LightingAtlas에 기록됩니다.

 

멀티 바운스: 간접광 계산 프로세스는 직접광과 유사합니다. 먼저 현재 프레임에서 광원 업데이트가 필요한 브릭을 k 개 식별합니다. 그런 다음 이러한 브릭의 유효 면 인덱스를 버퍼에 압 축하여 후속 GPU 스레드 그룹 및 스레드 할당을 용이하게 합니다. 각 유효 면에 대해 반 구 방향으로 n개의 광선이 방출되고 수집된 결과에 가중치를 부여하고 평균을 내서 조도를 계산하여 저장합니다.

 

"브릭그룹 비트마스크"와 "브릭 비트마스크"를 활용하면 HDDA 알고리즘을 구현하여 빠른 레이캐스팅과 교차점 감지를 가능하게 할 수 있습니다. 구체적인 처리 로직은 다음과 같습니다: 시작점 오프셋: 시작점에서 광선이 시작될 때, 시작점은 자기 교차를 피하기 위해 광 선 방향을 따라 복셀 표면으로 바깥쪽으로 변환되어 트레이싱을 수행해야 합니다.
브릭그룹 추적: 시작점의 위치에 따라 해당 BrickGroup을 찾습니다. 그룹이 존재하면 해당 64비트 비트마스크가 검색됩니다.

 

기본 구성 변수는 다음과 같습니다. 기본 복셀 크기는 0.5m이고, 하나의 브릭에 8x8x8 복셀이 있으므로 하나의 브릭이 4m의 범위를 커버하고, 하나의 브릭 그룹에 4x4x4 브 릭이 있으므로 브릭 그룹이 16m의 범위를 커버하고, 32x32x8 브릭 그룹의 수가 있으므 로 512x512x128 미터를 커버할 수 있습니다.

 

다음은 브릭과 비표면 조명 아틀라스에서 조명 데이터를 가져오는 의사 코드입니다. 첫 번째 레이마칭은 브릭 그룹 비트 마스크를 사용하여 브릭 수준에서 이루어지고, 그 다음 복셀 수준에서 레이마칭이 이루어지며, 각 레이마칭 프로세스는 64비트를 사용 하여 64개의 브릭 또는 복셀의 존재 여부를 확인합니다.

 

유효한 브릭을 얻는 의사 코드와 복셀 수준에서 레이마칭하는 방법은 비슷합니다.

 

먼저, 어떤 면을 복구해야 하는지 식별해야 합니다. 유효 면의 개념을 간단히 설명 하자면, 간단히 말해 관찰 가능한 면만 유효 면으로 간주합니다. 아래 그림에서 볼 수 있듯이 FaceS는 복셀 A와 복셀 B 사이의 겹치는 면으로, B가 빈 복셀이거나 반투명 복셀 (즉, 불투명도 <1)인 경우 FaceS는 보이는 것으로 간주되어 유효 면으로 간주할 수 있습 니다. 비어 있지 않은 각 복셀에 대해 유효 면이 있고 이러한 면 중 일부가 비어 있 으면 후속 복구 처리를 기다리는 버퍼에 추가됩니다. 구체적으로 복구(Repair)에는 두 가지 옵션이 있습니다. 복구에는 페이스가 위치한 평면을 기준으 로 3x3 그리드 내에서 검색 및 패치의 우선순위를 정하고 알베도와 노멀을 검색하여 채 웁니다. 또 다른 간단하고 직접적인 옵션은 이 면의 알베도와 동일한 복셀에 속한 다른 면의 알베도의 가중 평균을 직접 가져오는 것이며, 노멀은 다른 면의 노멀을 회전하여 얻을 수 있습니다(또는 단순히 복셀 면의 방향을 노멀 방향으로 선택하면 기본적으로 정확하고 빛 누출 없이 효과를 얻을 수 있습니다).

 

카메라 이동 중 프레임에서 업데이트된 바운딩 박스가 매핑된 바운딩 박스의 범위를 초과하는 것이 감지되면 해당 리젝션 로직이 실행되어야 합니다. CPU에서는 모든 브릭이 트래버스되고 새로 매핑된 바운딩 박스를 초과하는 브릭은 삭제됩니다. 동시에 AtlasOrigin과 같은 기본 파라미터도 업데이트해야 합니다. GPU에서는 해당 BrickTexture와 HDDAStruct만 업데이트하면 됩니다. 나머지 브릭에 대한 오프셋이 계산되어 ReprojectionPass에 파라미터로 전달되고, 그에 따라 해당 브릭이 이동합니다.

 

브릭라이저를 사용하여 복셀화를 구현하는 방법을 소개한 후 조명 샘플링 단계로 넘어갑니다. 앞서 언급했듯이 효율적인 조명 샘플링을 위해 루멘과 유사한 스크린 프로브 접근 방식을 활용합니다. 다이어그램에서 볼 수 있듯이 화면을 16x16 블록으로 분할하고 각 블록에 스크린 프로브를 생성합니다. 각 스크린 프로브는 64개 방향의 조도 정보를 기록합니다. 방사 정보 외에도 스크린 프로브에 대한 노멀 및 깊이 정보도 생성합니다. 또한 이전 프레임에서 스크린 프로브의 관련 정보를 추적합니다. 프로브에 대한 밉맵 데이터도 있는데, 그 용도는 나중에 설명하겠습니다. 스크린 프로브 데이터를 계산하는 방식은 루멘과 다른데, 2x2 스크린 프로브를 가상 그룹으로 그룹화하고 이 그룹에서 매 프레임마다 하나의 프로브를 무작위로 선택하여 계산하므로 계산 부하가 루멘의 4분의 1로 줄어듭니다.

 

프레임당 스크린 프로브의 방사도를 계산하는 계산 비용을 더욱 줄이기 위해 과거 스크린 프로브 방사도 데이터의 활용을 극대화합니다. 현재 프레임의 스크린 프로브를 과거 프레임에 투영하여 인접한 스크린 프로브를 찾는 방식과 과거 프레임의 스크린 프로브를 현재 프레임에 재투영하고 기하학적으로 가장 가까운 과거 프레임을 사용하여 현재 프레임을 채우는 두 가지 방식이 있습니다. 이 방법은 이전 접근 방식에 비해 스크린 프로브의 충돌률이 더 낮다는 것을 발견했습니다. 재투영에 실패한 스크린 프로브의 경우 다음 단계인 복사 데이터 수집 및 계산을 진행합니다.

 

어떤 스크린 프로브에 조도 데이터 재계산이 필요한지 결정한 후, HDDA 알고리즘을 사용하여 씬에 광선을 투사하여 복셀화된 표현인 '브릭'에 투사하여 조도 데이터를 얻습니다. 복셀에 조도 데이터만 저장하는 기존 복셀화와 달리 우리는 복셀의 각 방향에 대해 별도의 데이터를 저장합니다. 또한 앞서 브릭라이저 설명에서 설명한 유효하지 않은 얼굴 제거 로직을 적용합니다. 이를 통해 광선이 다른 방향에서 복셀에 닿을 때 서로 다른 조명 데이터를 얻을 수 있습니다. 예를 들어 얇은 벽의 경우 실내와 실외의 조도가 다릅니다.

우리가 계산하는 조명 데이터는 스크린 프로브를 기반으로 하지만 궁극적으로 각 픽셀 셰이더에 대한 조명 데이터가 필요합니다. 현재 픽셀을 둘러싼 4개의 스크린 프로브를 찾고 기하학적 정보의 가중 평균을 기반으로 픽셀의 조명 정보를 계산하는 비교적 간단한 접근 방식을 사용합니다. 그러나 앞서 가상 그룹에 있는 스크린 프로브의 4분의 1만 매 프레임마다 계산되므로 일부 스크린 프로브에는 실제 조명 데이터가 없어 리플렉션에 실패할 수 있다는 점을 눈치챘을 것입니다. 이러한 경우 스크린 프로브의 밉맵이 작동합니다. 밉맵 계층 구조에서 적절한 스크린 프로브를 검색하여 현재 픽셀 포인트로 보간합니다.

알고리즘에 대한 자세한 소개를 마쳤으니 이제 실제 환경에서 테스트 결과가 어떻게 나타나는지 살펴보겠습니다.

 

여기서는 2023년형 플래그십 모바일 디바이스를 사용해 VXGI와 BrickGI를 테스트하고, PC의 Lumen을 기준으로 삼았습니다. 보시다시피 BrickGI는 반경 512미터의 구형 볼륨에 30MB 미만의 메모리만 필요합니다. 반면, 루멘과 기존 클립맵 방식은 50MB 이상이 필요합니다. 또한 성능 측면에서도 2ms 이내에 모든 GI 계산을 완료할 수 있습니다.

다음은 클립맵을 기준으로 복셀화 방법의 세부 메모리 사용량이며, 약 50MB입니다.

최신 브릭라이저 기술을 기반으로 한 복셀화 방법의 자세한 메모리 사용량은 다음과 같습니다. 약 30MB의 메모리를 사용하며 장면 범위는 4레벨 클립맵의 두 배인 최대 512미터에 이릅니다.

알고리즘의 장점과 향후 개선 가능성을 정리해 보겠습니다.

이 시스템의 장점은 데이터 저장 속도가 더 효율적이어서 메모리 사용량이 줄어들어 장면을 더 정밀하게 표현할 수 있다는 점입니다. 또한 GPU 캐시와 더 잘 호환되도록 설계되어 하드웨어 기반 레이 트레이싱이 필요하지 않으므로 필요한 레이 트레이싱 계산 횟수를 줄일 수 있습니다. 하지만 거울 반사를 효과적으로 처리하지 못한다는 점과 거대한 물체의 변화에 적응하기 어렵다는 단점도 있습니다. 앞으로 우리는 오버드로를 줄이고, 여러 광원 주입을 통합하고, 텍스처를 압축하는 전략을 구현할 계획입니다. 이러한 개선 사항은 평균 제곱 오차 지표(MSME)를 사용하여 방사도를 평가할 때 특히 유용하며, 성능과 정확도를 모두 개선하는 것을 목표로 합니다.

시간 내주셔서 감사합니다. 추가 질문이 있으시면 언제든지 저에게 연락해 주세요.