역자의 말: 1년 전에 비해 이제는 Claude 나 Sol 의 힘을 비러 쉽고 빠르게 볼만한 수준으로 번역이 되네요. 포스트 가장 아래에 영어+한글 병기 된 PPTX 도 첨부 되어 있으니 참고하시면 될 것 같구요. 2025년부터 2026년까지 꾸준히 GI 와 볼류메트릭에 대한 구현 내용이 이어지고 있습니다. 특히 GI 는 DDGI, Surface Cache, Path Tracing 경량화 등등 꾸준히 품질과 성능이라는 트레이드오프 간극을 줄여나가는 것에 포커싱을 두고 있어보입니다.
원문: SIGGRAPH 2026 Advances in Real-Time Rendering in Games course
초록: 최근 몇 년 사이 비디오 게임의 실시간 렌더링 분야에서 볼류메트릭 렌더링 기법이 점점 널리 사용되고 있습니다. 하지만 기존 기법은 대개 구름이나 볼류메트릭 포그처럼 특정 용도에 한정되거나, 사실적인 결과를 얻기 위해 많은 맞춤형 설정 작업이 필요합니다.
저희는 007 First Light를 개발하면서 완전히 통합된 확장형 실시간 볼류메트릭 이펙트 렌더링 프레임워크인 Smolder를 자체 Glacier 엔진에 도입했습니다. Smolder를 사용하면 볼류메트릭 이펙트도 다른 VFX와 동일한 방식으로 활용할 수 있습니다. 또한 Glacier의 모든 조명 시스템은 물론, 불투명·반투명·볼류메트릭 포그를 비롯한 장면의 다양한 레이어와도 완전히 통합되어 있습니다.
이 덕분에 아티스트는 환경, 시네마틱, 게임플레이 장면을 제작할 때 Smolder를 자유롭게 활용할 수 있습니다. 아울러 Bond가 사용하는 여러 장비에도 플레이어가 직접 제어하는 볼류메트릭 이펙트를 추가할 수 있습니다.
이 발표에서는 Smolder가 작동하는 원리와 현재의 시스템에 도달하기까지 거쳐 온 개발 과정을 깊이 있게 살펴봅니다. Smolder 알고리즘을 구성하는 각 요소의 장단점을 평가하고, 앞으로 Smolder를 어떤 방향으로 발전시킬 수 있을지도 함께 전망합니다.
발표자 소개:
Alexander Mueller는 IO Interactive의 선임 렌더링 엔지니어로, 자체 개발한 Glacier 엔진을 담당하고 있습니다. 조명과 성능 최적화를 전문으로 하며, 특히 볼류메트릭 렌더링과 글로벌 일루미네이션에 중점을 두고 있습니다. IOI에 합류하기 전에는 Ubisoft Mainz에서 렌더링 프로그래머로 근무했습니다.
안녕하세요! 소개해 주셔서 정말 감사합니다, Natasha. 그리고 오늘 이 자리에 함께해 주신 여러분께도 감사드립니다.
제 연락처 정보 몇 가지입니다. 언제든 편하게 연락 주세요.
게임 이야기부터 시작하겠습니다.
저희는 약 2개월 전에 007 퍼스트 라이트를 출시했고, 수많은 볼류메트릭 이펙트와 함께 선보였습니다. 여기 출시 트레일러에서 그 일부를 보실 수 있습니다.
이 이펙트들은 저희가 Smolder라고 부르는 렌더 시스템으로 구동됩니다. 저희 아티스트들은 세트 드레싱, 게임플레이 장치, 컷신, 그리고 강렬한 액션 시퀀스에 이르기까지 게임 전반에 걸쳐 Smolder 이펙트를 사용했습니다.
이 게임은 저희 자체 엔진인 Glacier를 기반으로 제작되었습니다. Glacier는 IOI의 모든 프로젝트를 구동하는 엔진으로, 시스템 기반 게임플레이와 빠른 반복 작업을 중심으로 설계되었습니다.
자체 엔진으로 작업해 본 적이 있다면, 그것이 늘 우리가 바라는 만큼 매끄럽게 동작하지는 않는다는 걸 아실 겁니다. 하지만 잘 동작할 때는 정말 마법 같아서, 아티스트와 디자이너가 몰입 상태에 빠져 정말 놀라운 것들을 만들어낼 수 있습니다.
이것이 바로 Smolder의 배경이 된 꿈으로 이어집니다. 얼마 전, 저희 수석 테크니컬 아티스트 중 한 명인 Martin Nielsen이 저를 찾아왔습니다. (제가 발음하기 어려운 아주 덴마크식 중간 이름이 두 개 있어서 그건 생략하겠습니다.)
그는 007 퍼스트 라이트가 아닌 다른 프로젝트를 위한 동적 게임플레이 VFX 몇 가지를 가지고 있었는데, 그것들은 어디서나 동작하는 볼류메트릭 렌더러가 필요했습니다. Martin은 기술적으로 매우 뛰어난 아티스트로 주로 결과물에 관심이 있었지만, 제게는 워크플로가 중요한 부분이었습니다.
저는 아티스트가 Glacier에서 볼류메트릭을 다른 시스템처럼 자유롭게 다룰 수 있게 하고 싶었습니다.
저는 Glacier에서 볼류메트릭을 일급 요소로 만들고 싶었습니다. 이는 훌륭한 워크플로의 힘, 그리고 그것이 아티스트가 아름다운 세계를 만들 수 있게 해준다는 점과 연결됩니다.
제게 이것은 어떤 렌더 시스템에서든 가장 중요한 부분이며, 사내에서 끊임없이 밀어붙이려 하는 것입니다.
아무리 놀라운 기술을 만들어도, 아티스트가 그것을 다루지 못하거나 다루는 것을 즐기지 못한다면 그만큼 놀라운 결과물을 만들어내지 못합니다. 그러니 결국 그 기술은 의미가 없습니다.
그래서 저희는 아티스트가 아무 제약도 신경 쓰지 않고 월드에 볼륨을 배치하며 자신의 예술적 비전에 집중할 수 있는, '그냥 되는' 시스템을 정말로 원했습니다.
이는 또한 아티스트가 실행 대상 하드웨어를 신경 쓰지 않게 하고 싶다는 뜻이기도 합니다.
PS5나 Xbox Series X 같은 고사양 플랫폼에서 훌륭한 결과를 내는 렌더 기술을 추구하는 게임들을 꽤 많이 봤습니다. 하지만 그 기술을 구동할 수 없는 저사양 하드웨어로 이식할 때가 되면, 아티스트가 폴백 시스템을 위한 콘텐츠를 별도로 만들어야 했습니다.
특히 요즘은 플레이어가 하드웨어를 업그레이드하기가 점점 더 부담스러워지고 있어, PC 최소 사양을 낮게 유지하는 것이 그 어느 때보다 중요합니다.
이제 문제는 이를 어떻게 접근하느냐였고, 저희는 다른 이들이 이미 출시한 것들을 살펴보는 것부터 시작했습니다. 관련 자료는 아주 많으며, 지난 몇 년간의 Advances에서 볼류메트릭을 다룬 발표만 봐도 목록이 꽤 깁니다.
당시 Glacier에는 froxel 기반 볼류메트릭 포그 같은 시스템이 이미 있었지만, 거기서 얻을 수 있는 비주얼은 충분히 좋지 않았습니다. 볼류메트릭 구름 또한 Horizon 게임에서 Andrew Schneider의 작업 덕분에 매우 인기를 끌었고, 예를 들어 카운터 스트라이크 2의 연막 수류탄처럼 다른 시스템도 많이 있었습니다. 하지만 그 모든 시스템에는 우리 용례에 잘 맞지 않게 만드는 제약이 있었습니다.
그것들은 대개 특정 목적에 매우 특화되어 있습니다.
많은 경우 씬 통합이 제한적이며, 특히 투명도 처리에서 그렇습니다.
그리고 다수가 라이팅 통합이 매우 제한적이어서, 보통 소수의 광원과 극히 적은 그림자 광원만 지원합니다.
우리가 원하는 것을 만들려면 새로운 방법을 찾아야 한다는 것이 분명했습니다. 저희는 범용적이고 완전히 통합되었으며 성능이 뛰어난 볼류메트릭 이펙트 렌더러를 원했습니다.
세부 내용에 들어가기 전에, 레이마칭을 한 번도 해본 적 없는 분들을 위해 그 원리를 간단히 살펴보겠습니다.
더 깊이 있게 살펴보려면 scratchapixel의 관련 시리즈를 추천합니다. 정말 잘 만들어져 있습니다.
볼류메트릭을 렌더링할 때는 두 가지를 계산해야 합니다. 볼륨 뒤의 빛이 그것을 얼마나 투과하는지, 그리고 들어오는 빛이 카메라 쪽으로 얼마나 산란되는지입니다.
이러한 볼륨을 렌더링하기 위해 보통 레이마칭을 사용합니다.
주 광선을 따라가는 각 스텝마다 볼륨의 밀도를 샘플링합니다.
이를 통해 투명도의 척도인 광학적 깊이를 계산하고, 투과율 함수를 조금씩 만들어 나갈 수 있습니다.
이는 각 스텝 내의 밀도가 균일하다고 가정합니다. 만약 그렇지 않다면 여기서 오차가 생기며, 볼륨을 과소 샘플링하지 않으려면 더 작은 스텝 크기가 필요합니다.
산란을 적분하려면, 각 샘플마다 들어오는 빛의 양을 결정해야 합니다.
그 빛이 샘플 지점에 도달하기 위해 볼륨을 통과하므로, 들어오는 빛에 대한 투과율도 함께 계산해야 합니다.
전체 알고리즘에서는 한 스텝을 나아가고,
밀도를 샘플링하여 이 지점까지의 투과율을 갱신합니다.
그런 다음 광선에 대한 투과율을 계산하기 위해 2차 레이마칭을 수행하고, 해당 샘플의 산란을 계산합니다. 그 산란은 주 광선의 투과율로 감쇠된 뒤 결과에 더해집니다.
주 레이마칭은 다음 샘플로 이어지며, 끝에 도달하거나 투과율이 0이 될 때까지 볼륨을 따라 나아갑니다. 투과율이 0이 되면 추가 샘플이 결과에 기여하지 않으므로 멈출 수 있습니다.
그 이야기는 여기까지 하고, 이제 볼류메트릭 렌더러의 요구사항 목록과 목표 달성을 위해 해결해야 할 여러 문제를 살펴보겠습니다.
먼저 완전한 라이팅 통합부터 시작합니다.
직접광의 경우 먼저 태양광이 있는데, 저희의 경우 세 가지 종류의 그림자를 동반합니다.
매우 전통적인 캐스케이드 섀도우 맵이 있으며, 007 퍼스트 라이트에서는 3개의 캐스케이드를 사용하고 25미터를 커버합니다.
그 너머로는 카메라 주변에 정적 그림자만 담는 스크롤링 캐스케이드가 있으며, 이는 200미터를 커버합니다.
맵의 나머지 영역은 매우 저해상도의 글로벌 섀도우 맵이 커버합니다. 007 퍼스트 라이트에서 가장 큰 맵은 4 x 4km입니다.
지역 광원의 경우, 주된 문제는 씬에 존재하는 지역 광원의 개수입니다.
저희 라이팅 아티스트들은 곳곳에 수많은 광원을 배치하는 것을 좋아합니다.
가장 복잡한 뷰에서는 150~200개의 광원이 있습니다.
당시 저희는 여전히 히트맨 2016을 위해 처음 만들어진 매우 구식의 타일 기반 광원 컬링 시스템을 사용하고 있었습니다.
예를 들어 이 디버그 뷰에서는 타일당 최대 60개의 광원이 있습니다.
그 외에도 모든 종류의 광원 타입을 지원해야 하며, 각각 다양한 기능을 동반합니다. 이는 높은 레지스터 압박으로 이어집니다.
마지막으로 전역 조명도 고려해야 합니다.
007 퍼스트 라이트에서는 완전한 실시간 DDGI 방식 전역 조명 시스템을 추가했습니다.
프로브는 상당히 표준적이며, 저희의 경우 8x8 팔면체 텍스처에 복사조도, 복사휘도, 깊이를 저장합니다. 3개의 캐스케이드가 있고 각각 64x64x16 프로브를 가지며, 가장 작은 그리드 레벨에서는 프로브 간격이 60센티미터입니다.
상당히 조밀한 그리드입니다.
이 프로브를 샘플링하는 데는 높은 비용이 듭니다. 8개의 프로브를 샘플링하고 그 사이를 삼중선형으로 보간해야 합니다.
일반 표면의 경우, 이는 프로브당 하나의 복사조도 샘플을 취해 주어진 법선 주위 반구에 대한 사전 적분 결과를 얻는 것을 의미합니다.
볼류메트릭의 경우는 그렇지 않습니다.
볼류메트릭은 구 전체에 걸친 입사 복사휘도의 완전한 적분을 필요로 합니다.
등방성 위상 함수를 사용하지 않는다면, 이를 런타임에 수행해야 합니다.
이제 두 번째 라이팅 요구사항인 볼류메트릭 그림자로 이어집니다.
비용의 일부인 값비싼 그림자 광선에 대해서는 이미 언급했습니다. 이들은 확장성이 나쁠 뿐만 아니라 웨이브 일관성과 캐시 적중률에도 좋지 않습니다. 적분하는 동안 개별 광선마다 볼륨의 큰 부분을 샘플링해야 합니다.
그 옆에 두 번째 광선을 추가하면 또 다른 문제가 보입니다. 바로 샘플의 대규모 중복입니다. 같은 볼륨 영역을 계속해서 반복적으로 샘플링해야 합니다.
환경에 드리운 그림자까지 보고 싶다면, 씬의 각 픽셀마다 각 표면에서 광원으로 추가 그림자 광선을 쏘아야 합니다.
그리고 모든 광원이 볼류메트릭 그림자를 드리우게 하려면 각 광원마다 이 작업을 해야 한다는 점을 기억하세요.
당연히 그만큼 많은 그림자 광선은 감당할 수 없습니다.
저는 또한 모든 그림자가 실시간이길 원했습니다. 베이크된 그림자는 아티스트 워크플로에 또 하나의 제약이 되기 때문입니다.
다음 문제는 씬 통합입니다.
불투명의 경우는 간단합니다. 픽셀의 깊이에 도달하면 레이마칭을 멈추면 됩니다. 여기서 유일한 요구사항은 깊이 불연속 주변의 아티팩트를 피하기 위한 픽셀 단위 정확도입니다.
투명도와의 통합은 훨씬 더 복잡합니다. 투명 표면이 볼륨과 겹치지 않을 때는 해결하기 쉽습니다.
하지만 겹칠 때는 볼류메트릭 이펙트가 투명 표면을 가려야 하고, 그 반대도 마찬가지여야 합니다. 여기서 순환 의존성이 생기며, 래스터화 기반 파이프라인에서는 둘을 같은 패스에서 렌더링할 수 없습니다.
여기에 볼류메트릭 포그까지 고려하면, 그 의존성 사슬에 세 번째 시스템이 추가됩니다.
겹치는 볼륨 지원은 아티스트가 볼륨을 자유롭게 배치할 수 있게 하는 또 하나의 퍼즐 조각입니다.
가장 저렴한 방법으로는 샘플 위치를 오브젝트 공간으로 변환한 뒤 볼륨 경계 바깥에 있는지 확인합니다. 하지만 각 샘플마다 각 볼륨에 대해 이 행렬 곱을 해야 한다면 그 비용조차 빠르게 쌓입니다. 또한 그다지 정확하지도 않은데, 볼륨이 박스인 경우는 드물어 오탐이 많이 발생합니다.
이상적으로는 볼륨 주변의 빈 공간을 완전히 건너뛰고 싶습니다.
겹치지 않는 픽셀에 대해서는 아예 레이마칭을 시작조차 하고 싶지 않습니다.
마지막 요구사항 묶음은 비주얼과 성능에 관한 것입니다. 비주얼 측면에서 시스템은 현세대 수준의 충실도 요구사항을 충족해야 합니다. 이펙트가 환경에 어우러지지 못하고 일부 게임에서 지향하는 더 사실적인 아트 디렉션을 지원하지 못한다면, 사실상 사용할 수 없습니다.
성능 측면에서는 고사양의 5090부터 저희가 지원하려는 저사양 기기까지 전 범위로 확장되어야 합니다.
Switch 2, 스팀 덱, Series S, 그리고 PC에서는 GTX 1660과 RX 5700입니다.
무슨 일이 있어도 피하고 싶은 한 가지는 저사양 플랫폼을 위한 폴백 시스템이 필요해 콘텐츠를 두 번 제작해야 하는 상황입니다.
기존의 많은 볼류메트릭 시스템은 품질과 성능 사이의 균형을 맞추기 위해 시간적 필터링에 의존합니다.
안타깝게도 이펙트가 빠르게 움직이거나 카메라에 가까울 때는 모션 벡터가 없어 심한 고스팅이 발생하는 경향이 있습니다.
결국 해결해야 할 문제 목록이 꽤 길어졌습니다. 분명히 저희 앞에는 약간의 도전이 놓여 있었습니다.
구현에 들어가기 전에 소개해야 할 시스템이 두 가지 더 있습니다.
볼류메트릭 포그의 경우 거의 표준적인 froxel 그리드 기반 접근법을 사용합니다.
자세한 내용은 참고 문헌을 남겨두었지만, 핵심은 간단히 말해 절두체 정렬 그리드에 중간 결과를 저장하는 앞에서 뒤로의 볼류메트릭 적분이라는 점입니다.
이 그리드는 매우 저해상도의 레이마칭이라고 생각할 수 있으며, 기저 코드는 동일합니다.
이전과 마찬가지로 이를 투과율 함수에 매핑할 수 있습니다
그리고 그리드의 슬라이스를 따라 이동하면서 그 함수를 조각조각 조립해 나갑니다.
투명도의 경우, 단일 패스 내에서 올바르게 적분하기 위해 전통적으로 표면을 뒤에서 앞으로 렌더링합니다.
각 표면의 불투명도는 알파 값으로 표현됩니다.
이 경우에도 이전과 유사하게 투과율 함수를 그릴 수 있습니다.
정렬이 픽셀 단위가 아니라 드로우 단위로 이루어지며, 이는 대개 매우 눈에 띄는 깜빡임 아티팩트를 동반합니다.
바로 이 지점에서 순서 독립 투명도(OIT)가 등장합니다.
모든 OIT 알고리즘은 어떤 형태로든 이 CPU 측 정렬 의존성을 피하려 합니다.
보통 GPU 측에서 픽셀 단위 정렬을 만들거나, 투과율 적분을 실제 표면 렌더링과 분리하는 방식으로 이를 해결합니다.
이 투과율 함수를 미리 확보해 두면, 개별 투명 표면을 원하는 순서로 렌더링할 수 있고, 해당 깊이에서 올바른 투과율을 샘플링해 적용하기만 하면 됩니다.
다양한 기법에 대한 개요는 작년 Michal Drobot의 발표를 참고하세요.
저희의 경우 모멘트 기반 순서 독립 투명도(MBOIT)를 사용합니다.
이는 투과율 함수를 광학적 깊이의 거듭제곱 모멘트 급수로 저장하며, 광선 끝에서의 광학적 깊이를 담은 정확한 0차 모멘트 하나도 함께 저장합니다.
이 모멘트들은 로그 공간에 있습니다. 이는 모멘트 블렌딩을 곱셈 문제에서 덧셈 문제로 바꿔, GPU에서 이 함수를 생성하기 매우 쉽게 만듭니다. 모멘트의 또 다른 좋은 특성은 완전히 미분 가능하다는 점으로, 예를 들어 이를 자유롭게 필터링할 수 있습니다.
단점은 저장 공간 부담이 매우 크다는 것입니다. 저희는 각 32비트짜리 6개의 모멘트를 사용합니다.
16비트 모멘트로도 시도해 봤지만, 발생하는 아티팩트가 너무 눈에 띄었습니다.
이 모멘트를 위해 픽셀당 총 224비트가 필요하며, 이는 매우 무겁고 메모리 대역폭과 캐시에 큰 부담을 줍니다.
이제 드디어 첫 번째 시도로 이어집니다.
핵심 아이디어는 꽤 단순했습니다. 같은 OIT 알고리즘을 볼류메트릭에 적용하면 어떨까? 투과율 모멘트를 먼저 생성하면, 두 시스템 중 어느 것을 리졸브하기 전에 투명 표면 모멘트에 그냥 더하기만 하면 되어 통합이 아주 간단해집니다.
그리고 여기서 저희가 한 아주 초기 테스트에서 그것을 확인할 수 있습니다.
그림자의 경우, 자기 그림자와 다양한 표면의 그림자를 위해 임의의 깊이에서 샘플링할 수 있도록 거기에도 투과율 함수의 어떤 표현이 필요하다는 것을 알고 있었습니다.
이렇게 하면 모든 중복 비용을 제거하여, 그림자를 매우 웨이브 일관적인 방식으로 한 번만 렌더링하고 필요한 곳에서 그 그림자를 샘플링합니다.
밀도 모델링을 위해 저희는 GPU 파티클을 활용하기로 했습니다.
저희 프로그래머 중 한 명인 Asger Meldgaard가 이를 위한 실시간 유체 시뮬레이션 시스템을 만들기 시작했고, 이를 기반으로 삼으면 많은 기능을 공짜로 얻을 수 있어 그 방향으로 결정했습니다.
하지만 다수의 파티클을 레이마칭하는 것은 저렴하지 않으며, 특히 생성 패스와 리졸브 패스를 위해 두 번 해야 한다면 더욱 그렇습니다.
가속 구조를 이용한 초기 테스트는 그다지 고무적이지 않았고, 다른 접근이 필요하다는 것이 분명해졌습니다.
저희는 컴퓨트 셰이더에서 파티클을 소프트웨어 래스터화해 보기로 했습니다.
각 스레드가 하나의 픽셀을 렌더링합니다.
먼저 어떤 파티클이 해당 픽셀과 겹치는지 계산하고, 각각에 대해 투과율을 해석적으로 계산해 모멘트를 누적합니다.
그런 다음 OIT와 유사하게 같은 로직으로 두 번째 패스에서 산란을 렌더링할 수 있었습니다.
저희는 모든 파티클을 밀도 감쇠를 가진 단순한 구체로 취급했습니다.
이것은 충분히 확장되지 않았습니다.
중간 크기의 파티클조차 금세 수백, 심지어 수천 픽셀을 덮었고, 큰 이펙트에는 수십만 개의 파티클이 있었습니다.
이를 해결하기 위해, 저는 이 시스템을 여러 스케일로 렌더링하고 각 파티클을 크기에 따라 특정 밉 하나에만 그리려고 시도했습니다.
이렇게 하면 각 파티클마다 대체로 같은 수의 픽셀을 렌더링하게 됩니다.
모든 밉이 렌더링된 후, 각 밉의 모멘트를 단순히 더해 병합할 수 있습니다.
선형 필터는 매우 눈에 띄는 아티팩트를 남겨서 큐빅 필터를 사용해야 했습니다.
이것이 이 단계에서의 기술 결과입니다. 007 퍼스트 라이트가 아닌 Glacier 영상이라 비디오를 상당히 많이 잘라내야 했습니다. 이 발표를 위해, 여러분 모두 이것이 007의 영상이고 본드가 화면 밖에서 화염방사기를 들고 서 있다고 상상해 주세요.
실시간 유체 시뮬레이션이 작동하는 것을 볼 수 있으며 이 영상에는 많은 가능성이 있었습니다. GPU 파티클을 활용한 덕분에 테스트 초기부터 복잡한 이펙트를 구현할 수 있었고, 지면과의 충돌 같은 기능도 공짜로 얻었습니다.
하지만 몇 가지 문제도 보입니다. 이 비디오들의 차이는 사용한 파티클의 크기입니다.
왼쪽은 상당히 선명하지만, 개별 파티클의 점들이 보입니다.
여기서 이미 파티클 수를 매우 높게 밀어붙였지만, 이펙트가 매우 커서 충분하지 않았습니다.
오른쪽 비디오에서는 파티클을 키웠고, 그렇게 하면 점들은 보이지 않지만 이펙트가 눈에 띄게 흐릿합니다.
아트 디렉션이 원하던 것에 비해 너무 흐릿했습니다.
같은 이펙트의 클로즈업입니다.
또한 오른쪽 비디오에서 다중 스케일 렌더링으로 인해 전경 가장자리에 생긴 깊이 테스트 아티팩트에 주목하세요. 이는 제가 끝내 좋은 해결책을 찾지 못한 문제였습니다.
그리고 안타깝게도 이것은 이 시스템의 개발 과정 내내 반복된 패턴이었습니다.
가능성은 정말 많았지만, 항상 점점 고치기 어려워지는 문제들이 잔뜩 있었습니다.
작은 문제도 알고리즘에 복잡한 변경을 요구했고, 이는 성능에 도움이 되지 않았습니다.
저희는 이것이 잘 안 될 수도 있다는 것을 알고 시작했고, 이 시스템의 현실은 해결책을 찾지 못한 채 같은 문제들만 계속 이야기하는 것이었습니다.
너무 복잡했습니다.
성능은 원하는 방식으로 확장되지 않았고, 특히 그림자 렌더링 비용이 너무 높았습니다.
비주얼 품질 또한 여러 아티팩트와 트레이드오프로 인해 원하는 수준에 이르지 못했습니다.
무엇보다도 이펙트를 제작하는 것이 거의 불가능했습니다.
또한 Martin과 Asger가 하던 멋진 작업을 보면서도 렌더링 측면에서 그것을 구현해내지 못하는 것은 그저 괴로웠고, 그들이 우리가 얻은 결과에 점점 실망하고 있다는 것을 느낄 수 있었습니다.
특히 이 마지막 두 가지는 접근 방식을 재고해야 한다는 것을 분명히 해주었습니다. 그것들은 제가 지닌 하나의 황금률을 깨뜨렸습니다. 워크플로가 비참했던 것입니다.
그 무렵 저는 근본적으로 다른 접근이 필요한지 고민하기 시작했습니다.
저는 볼류메트릭 파티클에서 얻은 교훈을 가지고 처음부터 다시 시작했습니다.
가장 중요한 교훈은 샘플링 기반 렌더러가 없는 것이 아티스트에게 너무 제한적이라는 점이었습니다.
그래서 저는 레이마칭과 처음에 그것을 왜 버렸는지 다시 살펴봤습니다.
첫 번째 이유는 모멘트 생성과 산란 리졸브를 위한 두 번의 레이마칭 패스가 너무 비싸다는 것이었지만, 그것들이 없어도 투명 표면과 포그 통합 문제는 여전히 해결해야 했습니다.
두 번째는 겹치는 볼륨을 효율적인 방식으로 처리해야 한다는 것이었습니다.
원래 세 번째 문제는 거의 해결된 상태였는데, 바로 그림자를 위한 2차 광선의 비용입니다. 이론적으로 저희에게는 해결책, 즉 볼류메트릭 섀도우 맵이 있었습니다.
다른 문제들을 해결할 아이디어는 있었지만, 핵심 질문은 품질을 필요한 수준까지 끌어올릴 수 있는지, 그리고 목표로 한 성능 수준에서 그것을 해낼 수 있는지였습니다.
하지만 그 당시 제가 가진 가장 큰 문제는 단연 많은 의심이었습니다. 첫 시도에 이미 2개월 반을 썼고 잘 안 됐지만, 어쩌면 그 문제들을 여전히 해결할 수 있을지도 몰랐습니다. 확실했던 건, 두 번째 시도마저 실패하려고 그 작업을 버리는 사람이 되고 싶지는 절대 않다는 것이었습니다.
저에게는 어느 정도의 확신이 필요했습니다.
운 좋게도 저는 그 다음 주에 가족과 스키 여행을 갔습니다.
그리고 부모님과 여동생이 밤 10시에 잠자리에 든 사이, 저는 노트북을 들고 매일 저녁 몇 시간씩 프로토타입을 코딩했습니다.
거기엔 Unity밖에 없었지만, 제가 코딩해야 했던 것은 컴퓨트 셰이더 몇 개뿐이라 Unity로 충분했습니다.
저는 절차적 구체를 통과하는 간단한 레이마처를 코딩했고, 품질과 성능 확장성을 판단할 수 있도록 거기에 그림자 하나를 추가하고 싶었습니다.
기존에 나와 있는 몇 가지 해법을 살펴봤지만, 상당수를 초기에 배제했습니다.
볼류메트릭 섀도우 캐스케이드는 제가 원하는 품질을 내지 못했기 때문이고, 적응형 볼류메트릭 섀도우 맵은 메모리와 성능 면에서 비용이 너무 커 보였기 때문입니다.
제가 찾은 가장 유망한 것은 Hillaire의 비어 섀도우 맵이었습니다.
매우 저렴하고 많은 메모리를 필요로 하지 않습니다.
실험해 봤지만, 이는 볼륨의 균일 밀도를 가정하기 때문에 그 결과로 나온 자기 그림자의 품질이 충분하지 않았습니다.
결국 저는 그림자에 MBOIT 방식의 모멘트를 계속 사용하기로 결정했습니다.
이는 품질과 비용의 좋은 조합을 제공했고, 앞서 언급한 훌륭한 특성들을 갖추고 있었습니다.
볼류메트릭 파티클 사례에서 겪은 품질·성능 문제는 다중 스케일 렌더링 때문이었고, 기술 자체는 사실 매우 잘 작동했습니다.
또한 이러한 그림자는 본래 흐릿한 특성 덕분에 상당히 낮은 해상도와 큰 스텝 크기로도 충분히 렌더링할 수 있다는 것을 깨달았습니다.
이 테스트에서 얻은 결과는 훌륭했습니다.
제가 원하던 비주얼 품질을 얻었을 뿐만 아니라, 성능 소식도 그만큼 좋았습니다.
3050Ti가 탑재된 제 노트북에서도 그림자 렌더링은 매우 저렴했고, 메인 뷰 성능도 훌륭했습니다.
특히 앞으로 최적화할 여지가 많다는 것을 알고 있었기에 더욱 그랬습니다.
이 작은 프로토타입은 이미 이전 기술을 크게 뛰어넘는 도약이었고, 휴가에서 돌아와 그 다음 주 월요일에 기존 기술을 버리기로 결정할 수 있는 자신감을 주었습니다.
무엇보다도 Martin이 크게 흥분했습니다. 이전 시도에서 다소 막혀 있던 터라 저희에게 절실히 필요했던 활력이었습니다.
그렇게 결정된 뒤, Smolder는 Glacier에서 형태를 갖추기 시작했습니다. 저는 구체를 옮겨오는 것부터 시작해 기본 설정을 구축하고 구동시켰습니다.
…이어서 기본적인 라이트 루프와 그림자 샘플링을 구성했습니다.
저는 프로젝터 맵 같은 다른 여러 라이팅 기능도 연결했습니다. 007 퍼스트 라이트의 아티스트들은 프로젝터 맵 사용을 매우 좋아해서, 이는 지원해야 할 핵심 기능으로 밝혀졌습니다.
예를 들어 게임의 이 특정 호텔 구역에는 총 1500개가 넘는 광원이 있고, 그중 1000개 이상이 프로젝터 텍스처를 사용합니다.
볼류메트릭 스포트라이트 그림자에 대한 초기 테스트입니다.
저희는 결국 4개의 모멘트와 16비트 양자화를 사용하기로 했습니다. 그 결과 텍셀당 80비트의 메모리 사용량이 됩니다.
엄청나게 저렴하지는 않지만, 그림자 해상도 측면에서 많은 것을 감수할 수 있어 이를 보완합니다.
여기 있는 것들은 128x128이지만, 저희는 저사양의 64x64부터 1k까지 해상도를 지원합니다.
투명 표면에서 이 그림자를 샘플링하는 예시로, 볼륨의 깊이에 따라 그림자가 누적되는 것을 볼 수 있습니다. 정렬은 아직 작동하지 않습니다.
이 시점에서 이 그림자의 샘플링 비용이 궁금하실 수 있습니다. 그림자와 주 광선을 렌더링하는 초기 수치를 보여드렸지만, 불투명 및 투명 라이팅에 추가되는 비용도 고려해야 합니다.
바로 이 지점에서 모멘트 기반 그림자가 또 다른 좋은 기회를 제공합니다.
기억하신다면, 광선 끝의 광학적 깊이를 담은 0차 모멘트가 필요합니다.
이를 먼저 샘플링하면 그 값으로 그림자 안에 있는지 여부를 알 수 있고, 그러면 다른 모멘트의 샘플링과 투과율 함수 평가를 건너뛸 수 있습니다.
또한 볼류메트릭 그림자에는 깊이를 저장하지 않으며, 비용이 큰 PCF 필터도 필요 없습니다. 단일 이중선형 샘플로 충분합니다.
007에서 두 종류의 그림자를 모두 가진 광원의 경우, 볼류메트릭 그림자의 샘플링 비용은 일반 그림자 샘플링 비용의 약 30%입니다.
더 이상 다중 스케일 방식을 사용하지 않았기 때문에, 깊이 테스트도 예상대로 작동했습니다.
옴니 광원 그림자는 래스터화 파이프라인에서 대개 엄청난 골칫거리지만, 레이마칭 그림자의 경우에는 고정된 투영에 제약받지 않습니다.
단일 패스로 팔면체 텍스처에 렌더링하기만 하면 됩니다.
바로 이 지점에서 비주얼이 조금씩 영감을 주기 시작했습니다. 여전히 절차적 구체만 있었음에도, 게임에서 흔히 볼 수 없는 시각 효과를 만들어낼 수 있었습니다.
저는 볼류메트릭 포그에도 그림자 샘플링 지원을 추가했습니다.
이 무렵부터 엔진 팀의 더 많은 사람들에게 기술을 보여주기 시작했고, 이 기술을 둘러싼 기대가 크게 쌓였습니다. 이 시점에서는 새 기능을 추가하는 데 몇 시간밖에 걸리지 않아 큰 도움이 되었고, 진행도 순조로웠습니다.
더 높은 주파수의 그림자 디테일로 시스템을 약간 스트레스 테스트한 예시입니다.
이 초기 Smolder 작업은 2025년 2월에 이루어졌으며, 이 시점에는 이 기술을 007에 사용할 계획이 전혀 없었습니다.
하지만 그때 연막 가젯이 등장했습니다.
기존 버전은 비주얼과 성능에 문제가 있었습니다. 무엇보다도 저희 게임플레이 디렉터는 볼륨의 형태를 알아보기 어렵다는 점을 마음에 들어 하지 않았습니다.
그 형태는 AI 시야 계산에 사용되기 때문에, 명확한 시각적 표현은 스텔스 게임플레이에 매우 중요했습니다.
Smolder에서 본 초기 결과 덕분에, 대신 그것을 연막 가젯에 사용할 수 있는지에 대한 논의가 빠르게 나왔습니다.
이 시점은 3월 초였고, 007 퍼스트 라이트는 본격적인 제작에 들어가 있었습니다. 공개 트레일러는 3개월 뒤로 예정되어 있었고, Sony의 State of Play에서의 전체 게임플레이 공개는 그로부터 다시 3개월 뒤에 이루어질 예정이었습니다. 출시는 1년 후였습니다.
그리고 Smolder는 진전을 이루고 있었지만 완성과는 거리가 멀었습니다. 여전히 떠 있는 구체에 불과했고, 미지수가 많았으며, 실시간 유체 시뮬레이션을 출시 가능한 수준으로 준비하는 것은 또 다른 거대한 문제였습니다.
또한 Smolder를 제 전담 프로젝트로 삼을 여유가 없었습니다. 제 할 일 목록에는 다른 작업이 많았습니다.
결국 저는 결정을 내려야 했고, 그것은 그 연막 가젯을 위해 Smolder를 만들되 유체 시뮬레이션 기술 위에 구축하지는 않기로 한 것이었습니다.
대신 시뮬레이션을 오프라인으로 실행하고, 사전 베이크된 밀도 데이터를 사용하기로 했습니다.
밀도 데이터의 경우, 최선의 선택이 OpenVDB 포맷을 활용하는 것이라는 점은 꽤 분명했습니다. 얼마 전 작은 오프라인 렌더러 프로젝트에서 실험해 봤고, 저는 이 포맷을 상당히 좋아합니다. 매우 성숙한 C++ 라이브러리를 제공하며, 현재 시점에서 충분히 검증되어 있습니다.
하지만 언제나처럼 가장 중요한 것은 훌륭한 워크플로를 지원한다는 점입니다. 널리 지원되며, 아티스트는 원하는 어떤 도구든 사용할 수 있습니다. 그들이 익숙한 많은 모델링·절차적 도구가 이를 지원합니다. 저희 볼륨 대부분은 EmberGen과 Houdini에서 제작됩니다.
하지만 OpenVDB는 GPU 측에서 실제로 사용하기 어려워, 런타임 포맷이 필요했습니다. 가장 명백한 선택지는 NanoVDB였는데 – 경험은 없었지만 시도해 볼 만큼 설정이 충분히 쉬워 보였습니다.
또한 구름 데이터셋을 공개하고, 특히 1/16 스케일 버전을 추가해 준 Disney에게 감사를 전합니다.
NanoVDB는 본질적으로 OpenVDB의 희소 복셀 트리를 평탄화한 버전일 뿐입니다. 그 위에 fp4 같은 유용한 런타임 기능이 몇 가지 있습니다.
하지만 안타깝게도 주로 높은 레지스터 압박 때문에 성능을 확보하지 못했습니다.
저는 커스텀 런타임 포맷이 더 최적의 선택이라고 판단했습니다. 개발 시간은 늘었지만 결국 성능을 크게 절약하고 훨씬 더 많은 유연성을 주었습니다.
포맷 자체는 그리 복잡하지 않습니다. 리소스 헤더는 리소스에 대한 일반적인 정보를 담고 있으며 Smolder에 특화된 것은 아닙니다.
다음은 Smolder 헤더입니다. 애니메이션의 프레임 수, 복셀의 크기, 그리고 전체 애니메이션에 대한 바운딩 박스를 담고 있는데, 이 박스는 실제 렌더링이 아니라 에디터에서 경계를 표시하는 데만 사용됩니다.
그 뒤에는 프레임 헤더 목록과 프레임 데이터 목록이 이어집니다.
헤더는 기본적으로 각 데이터 조각이 데이터 블롭 내 어디에 있는지를 설명할 뿐입니다.
또한 해당 프레임에 대한 타이트한 바운딩 박스를 담고 있으며, 이는 렌더러에서 실제 경계 검사에 사용됩니다.
이제 실제로 흥미로운 부분인 데이터로 넘어가겠습니다. 데이터는 1레벨의 희소 브릭 그리드에 저장되며, 각 브릭은 4x4x4 복셀입니다. 인다이렉션 인덱스는 16비트입니다.
저는 그것으로 충분하고도 남는다고 생각했지만, 아티스트들이 몇 번 그 한계에 부딪혔습니다. 앞으로는 32비트로 늘려야 할 수도 있습니다.
다음으로, 빈 공간 건너뛰기에 사용하는 브릭용 비트마스크가 있습니다. 각 브릭은 이 그리드에서 1비트이며, 4x4x2 브릭 그룹으로 저장합니다.
이를 위해 고속 복셀 탐색 알고리즘을 사용하는데, 이는 현시점에서 거의 40년 된 것입니다. 그래도 여전히 훌륭하게 작동합니다.
이 브릭 그룹들을 따라가며 0인지만 확인하면 그룹 전체를 건너뛸 수 있습니다.
이 비트마스크는 인다이렉션 인덱스를 하나씩 따라가는 것에 비해 컬링 단계를 눈에 띄게 빠르게 합니다.
다음으로 GI 오클루전 그리드가 있는데, 이는 포맷에 꽤 늦게 추가했습니다.
이는 극도로 낮은 해상도의 사전 베이크된 오클루전을 담고 있으며, 그 데이터는 브릭 블록 주변의 균일 랜덤 샘플에서 생성합니다.
이것이 필요한 이유는 GI 샘플링을 추가하자 볼륨이 눈에 띄게 밋밋해졌기 때문입니다. 스크린샷은 오클루전을 켠 것과 끈 것입니다.
GI만 적용한 뷰입니다.
이 낮은 해상도에서도 저희가 원하는 볼륨 내부의 어두워짐을 제공하며, 비용은 매우 적게 듭니다.
마지막으로 브릭 데이터가 있습니다. NanoVDB의 fp4 압축과 유사하게, 저는 커스텀 포맷의 브릭에도 매우 단순한 블록 압축을 추가했습니다. 메타데이터는 각 브릭의 최솟값과 최댓값을 담고 있습니다.
저희는 결국 복셀당 4비트를 사용했고, 밀도 데이터에서 사실상 품질 손실이 없었습니다.
2비트도 시도해 봤지만, 여기서 보시다시피 그림자의 일부 디테일이 사라지기 시작했고 품질이 눈에 띄게 나빠졌습니다.
그래도 사용할 수 없는 정도는 아니어서, 앞으로 확장 옵션이 될 수 있을지도 모릅니다.
마지막으로 브릭 데이터가 있습니다. 런타임에 같은 브릭 내에서 삼중선형 보간이 가능하도록 복셀을 복제하기 때문에, 데이터상 실제 크기는 5x5x5 복셀입니다.
그 대가로 브릭은 훨씬 더 많은 메모리를 필요로 하지만, 그 트레이드오프는 그만한 가치가 있습니다.
런타임 포맷이 정리되면서, 아티스트들이 콘텐츠 제작을 시작하는 데 필요한 것을 갖추게 되었습니다. 저는 또한 007 퍼스트 라이트 환경에서 Smolder의 첫 테스트를 만들어 게임 팀 채팅에 올렸습니다.
많은 아티스트가 이 기술에 크게 흥분했고, 바로 이 지점에서 Smolder는 사실상 연막 가젯 기술이기를 멈췄습니다.
그 다음 날 저는 테크 아트 디렉터와 회의를 했는데, 그는 게임플레이 트레일러의 볼류메트릭 구름에 Smolder를 사용하는 것이 실현 가능한지 물었습니다.
이 무렵 더 많은 테크 아티스트가 Smolder를 실험하기 시작했고, 특히 Per가 많은 테스트를 하며 훌륭한 결과를 얻었습니다.
Smolder가 점점 더 많은 이펙트에 사용되면서 생길 작업량이 매우 걱정되었지만, 한편으로는 저희가 전혀 계획하거나 테스트하지 않은 사례에 사용되는 것을 보는 것도 정말 좋았습니다.
그리고 그중 많은 경우를 꽤 잘 처리하고 있었습니다.
저와 테크 아트 사이의 매우 긴밀한 협업과 빠른 처리 속도는 그룹 내에 많은 긍정적 모멘텀을 계속 쌓아갔습니다.
아티스트들이 도구와 워크플로에 익숙해지면서 시뮬레이션의 품질을 계속 끌어올리는 모습을 보는 것도 흥미로웠습니다.
또한 사람들이 이 기술이 만들어낸 일부 결과물을 미처 예상하지 못한 경우들도 나타나기 시작했습니다.
이 영상에서 Martin의 운전은 양해 부탁드립니다.
하지만 그 모든 실험이 진행되는 동안에도 저는 여전히 해결해야 할 문제가 많았습니다. 그리고 더 많은 이펙트가 만들어지면서 나머지 시스템을 작동시켜야 한다는 압박이 커졌습니다.
가장 먼저 해결할 문제는 겹치는 볼륨을 어떻게 처리할 것인가였습니다.
샘플별 검사를 피하기 위해, 저는 볼륨 겹침을 미리 계산하고 싶었습니다.
Smolder는 스레드그룹 일관성을 중심으로 구축되어 있어, 이 계산을 그룹 단위로 수행할 수 있습니다. Smolder의 스레드그룹은 Wave64 하드웨어 지원 여부에 따라 8x4 또는 8x8 픽셀입니다. Smolder는 웨이브 인트린식을 많이 사용하며, 서로 다른 웨이브 크기에 대해 두 가지 버전의 셰이더를 두는 것은 훌륭한 최적화였습니다.
저는 결국 오프라인 렌더링에서 찾을 수 있는 아이디어를 따라 광선을 세그먼트로 나눴습니다. 겹치는 각 볼륨은 총 두 개의 세그먼트를 추가합니다.
마지막 세그먼트는 건너뛸 수 있는데, 그것은 어떤 것과도 겹치지 않기 때문입니다.
007에서는 전체 겹치는 볼륨의 수를 4개로 제한했지만, 필요하면 더 늘릴 수 있습니다.
그런 다음 모든 교차 거리를 정렬해 세그먼트의 경계를 얻고, 어떤 볼륨이 어떤 경계를 만드는지에 대한 정보를 이용해 각 세그먼트마다 비트마스크를 생성할 수 있습니다.
예를 들어 처음 두 세그먼트에 대해서는 이 두 개의 비트마스크가 나옵니다.
그리고 나머지 모든 세그먼트에 대해서도 똑같이 하면 됩니다.
세그먼트의 경우 8개의 깊이 값을 저장해야 하는데, 이에는 16비트로 충분했습니다.
또한 주변의 볼륨 중 어느 것이 이 웨이브의 4개 볼륨인지 알려주는 마스크도 저장해야 합니다.
점유 비트마스크 데이터를 이용해 경계를 좁히며, 이는 세그먼트를 매우 정확하게 만듭니다.
이는 볼륨 내부의 구멍은 고려하지 않는데, 이는 앞으로 개선할 수 있는 부분일 수 있습니다.
저는 특히 작년 GPC에서 Hugh Malan이 발표한 BCN 압축 볼륨 데이터를 테스트하는 데 관심이 있는데, 이는 사전 베이크된 볼륨 데이터에 매우 잘 맞아 보입니다.
컬링에서 한 부분을 빼놓았는데, 교차 거리는 어떻게 정렬할까요?
답은 cutesort입니다! 제가 가장 좋아하는 알고리즘 중 하나로, 본질적으로 WaveActiveBallot을 활용하는 랭크 정렬 알고리즘이라 웨이브 내에서 값을 정렬해 줍니다.
레이마칭 동안 우리가 해야 할 일은 현재 어느 세그먼트에 있는지 추적하는 것뿐이며, 그것이 각 샘플마다 어떤 볼륨을 평가해야 하는지 항상 정확히 알려줍니다.
엔진 내에서 어떻게 작동하는지 보여주는 예시입니다. 서로 부분적으로 겹치는 3개의 볼륨을 설정했습니다.
세그먼트 개수에 대한 디버그 뷰로 전환하면, 세그먼트 개수가 절대적으로 최소로 유지되고 볼륨에 대해 매우 타이트한 경계를 얻는 것을 볼 수 있습니다.
이 세그먼트 깊이들을 조각조각 단계별로 살펴보면 이를 더욱 잘 시각화할 수 있습니다.
겹치는 볼륨이 실제로 작동하는 초기 테스트입니다.
이는 또한 중앙에서 볼 수 있는 색상의 블렌딩 같은 멋진 결과도 만들어냅니다.
이것으로 저희가 목표로 하는 완전히 통합된 시스템에 한 걸음 더 다가갑니다.
발표 초반에 레이마칭, 볼류메트릭 포그, 투명 렌더링을 이야기할 때, 이들 모두를 투과율 함수로 생각할 수 있다는 점을 강조했습니다. 그것은 이 세 시스템의 완벽한 통합을 이론적으로 어떻게 달성할 수 있는지 이해하는 데 핵심이기 때문입니다.
각 시스템에 대해 먼저 투과율 함수를 생성할 수 있다면, 통합된 함수를 만들 수 있고, 이를 통해 세 시스템에 대해 3개의 독립적인 렌더 패스를 두면서도 완벽하게 통합할 수 있습니다.
이를 위해서는 모든 패스를 둘로 분할해야 합니다.
OIT는 이미 그렇게 되어 있습니다.
볼류메트릭 포그의 경우 현재의 투과율 적분을 산란 적분과 분리하는 것이 쉽습니다.
하지만 Smolder에서는 그것이 선택지가 아니었습니다. 레이마칭 비용이 너무 높아 두 번 하기 어렵기 때문입니다.
하지만 제가 깨달은 것은 세 시스템을 모두 분할할 필요는 실제로 없고, 그중 하나는 단일 패스로 실행할 수 있다는 것이었습니다. 단지 나머지 둘 사이에서 실행되기만 하면 됩니다. 그리고 Smolder가 볼류메트릭 포그보다 비싸기 때문에, 그 단일 패스 시스템이 바로 Smolder가 될 수 있습니다. 충분히 간단해 보입니다.
또한 해상도 차이도 해결해야 합니다.
OIT는 픽셀 단위 모멘트를 가지고, 볼류메트릭 포그는 저해상도 froxel 그리드를 가지는데, 하나의 froxel이 8x8 픽셀 또는 그 이상을 덮습니다.
투과율을 양방향으로 적용하려면, 모멘트 텍스처를 밉맵 처리하고 froxel 해상도에 맞는 밉을 샘플링해야 합니다.
이것이 Remedy가 Alan Wake 2에서 이미 한 것이라고 생각하며, 여기 링크한 REAC 2024 발표에서 이야기했습니다.
그래서 저희가 그렇게 했을까요?
당연히 아니죠 -.- 프로덕션의 현실이 또다시 들이닥쳤습니다.
여기서 보여드린 방식으로 설정을 바꾸려면 파이프라인에 큰 변경이 필요했고, 프로덕션 후반의 이 시점에서 그것은 그야말로 엄청난 위험이었습니다.
또한 시간이 꽤 걸렸을 것이고, 제 시간은 다른 곳에 필요했습니다.
9월에 저희의 확장 게임플레이 트레일러를 보셨다면, PS5 Pro에서 구동되었음에도 극도로 끊겼던 것을 아마 기억하실 겁니다.
저는 렌더 측에서 그 최적화 작업을 이끄는 임무를 맡았고, 그것은 그야말로 풀타임 업무였습니다.
본드의 디렉터들은 Smolder에 대한 추가 작업을 계속 요구했지만, 저는 게임을 정상 궤도에 올리기 위해 필요하다고 판단한 작업에 따라 Smolder를 계속 후순위로 미루고 지연시켜야 했습니다.
또한 매우 Glacier 특유의 문제가 하나 더 있었는데, 바로 블러와 굴절 파이프라인이었습니다. 이는 다양한 레이어드 블러와 파티클 정렬 모드 등 매우 복잡한 설정을 지원합니다.
그 복잡성 때문에 유지보수 부담이 극도로 크고, 사실상 다른 어떤 시스템과도 통합이 불가능합니다.
마지막으로 고려해야 할 성능 주제도 있습니다.
모멘트를 기반으로 투과율을 평가하는 것 자체는 극도로 비싸지는 않지만, 모든 레이마칭 스텝마다 하면 금세 비용이 쌓입니다.
제 테스트에서는 각 샘플 비용에 약 20%를 추가했습니다.
자, 그러면 저희가 최종적으로 도달한 통합 파이프라인을 단계별로 살펴보겠습니다.
저는 프레임 대부분을 그대로 유지하고, 대부분의 변경을 Smolder 패스 자체에 국한했습니다.
먼저 일반적인 볼류메트릭 포그 적분 패스로 시작합니다.
그런 다음 이전과 마찬가지로 볼류메트릭 포그를 불투명 씬에 적용하는데, 이는 이후 실행되는 블러 및 굴절 파이프라인에 영향을 주지 않기 위해 중요합니다.
OIT의 모멘트 생성 단계도 변경되지 않았습니다.
그런 다음 실제 Smolder 패스를 시작합니다.
레이마칭 동안 누적된 Smolder 주 광선 모멘트를 로컬 변수에 추적합니다.
또한 Smolder가 상당히 불투명해지는 깊이를 저장하고, 픽셀별 블루 노이즈를 사용해 이 오프셋을 픽셀마다, 프레임 사이마다 변화시킵니다.
이 시점에서 나머지 파이프라인은 Smolder 레이마칭 이후에 실행되며, 매우 편법적입니다.
먼저 그 적분 깊이까지 씬에서 볼류메트릭 포그를 제거합니다. 이는 그 지점까지의 산란을 제거한 뒤 그 깊이에서의 투과율로 나누는 것으로 간단히 할 수 있습니다. 이로 인해 오차가 생기지만, 실제로는 충분히 좋은 결과를 냅니다.
다음으로 Smolder의 투과율을 그 배경에 적용하고, 앞서 제거했던 부분 포그 산란과 투과율을 결과에 다시 더할 수 있습니다.
Smolder 산란을 결과에 더하기 전에, 적분 깊이에 대한 포그 및 투명 투과율을 그것에 적용해야 합니다.
마지막으로 Smolder 모멘트를 투명 모멘트에 더하고 OIT 리졸브 패스를 실행합니다.
이것은 Smolder를 다른 모든 시스템과 통합하지만, 일부 부분에 사용되는 단일 적분 깊이로 이를 단순화합니다.
불완전한 저희 파이프라인으로 얻은 초기 결과입니다.
저는 이것을 진심으로 싫어하지만, 주어진 시간을 감안하면 결국 실용적인 해법이었고 제 역할을 해냅니다.
퍼스트 라이트의 테크 아트 팀은 저를 위해 이 스트레스 테스트도 만들었는데, 세 시스템을 모두 겹쳐 놓고 그 위에서 폭발이 일어나게 했습니다.
전역 조명의 경우, 저는 샘플링을 볼륨당 1개의 샘플 위치로 제한하기로 했습니다. 베이크된 오클루전이 이를 그럴듯하게 만드는 데 도움을 줍니다. 레이마칭을 시작하기 전에 그 샘플을 계산해 LDS에 저장할 수 있습니다.
저는 결국 프로브당 2개 방향을 샘플링했는데, 이상적이지는 않지만 충분히 괜찮아 보였습니다. 그런 다음 삼중선형 보간 가중치를 기반으로 샘플을 로컬로 가중하고, 각 볼륨에 대해 WaveActiveSum을 사용해 이를 누적할 수 있습니다.
그 기간 동안 최적화 작업을 많이 해야 했다고 말씀드렸는데, 그중 하나는 저희의 전체 광원 컬링 파이프라인을 기존 타일 기반 시스템에서 현대적인 클러스터드 라이팅 파이프라인으로 전환한 것이었습니다.
저는 그것을 Smolder를 염두에 두고 진행했습니다.
핵심적으로 이 파이프라인은 상황별 비트마스크를 중심으로 구축되어 있습니다.
저희는 2D로 각 화면 영역에 대한 광원 목록을 저장하고, 실제 클러스터에는 그 목록에 대한 비트마스크만 담습니다.
이 비트마스크는 많은 메모리를 필요로 하지 않아, 용례에 따라 특정 비트마스크를 둘 수 있습니다.
예를 들어 Smolder에서는 캐릭터 전용 광원이나 박스 리플렉션이 필요 없습니다.
또한 인접 스레드가 같은 클러스터 X, Y 좌표를 공유하지만 샘플 깊이가 달라 다른 클러스터 Z 좌표에 속할 때는, 런타임에 비트마스크를 OR로 합칠 수 있습니다.
컬링 패스에서 얻은 세그먼트가 있으므로, 이 정보를 활용해 많은 클러스터와 광원을 빠르게 버릴 수 있습니다.
이 예시에서 볼륨과 겹치는 클러스터에만 광원이 있고, 클러스터당 7~8개의 광원이 되는 것을 볼 수 있습니다.
이 시점에서 저희는 원래의 꿈을 위해 해결해야 했던 거의 모든 문제를 해결했습니다. 마지막으로 남은 조각은 볼류메트릭 그림자의 컬링이었습니다.
이 시점까지 아티스트들은 일부 핵심 광원에서 수동으로 이를 활성화했는데, 짐작하시다시피 그것은 극도로 제한적이고 많은 성능 오버헤드를 동반했습니다.
저는 기본적으로 모든 광원에서 볼류메트릭 그림자가 활성화되고, 필요하면 아티스트가 명시적으로 끌 수 있는 토글을 두고 싶었습니다.
이를 위해서는 이들을 위한 동적 컬링 시스템이 필요했습니다.
먼저 저희가 이미 가지고 있던 절두체 컬링된 광원 목록을 사용하는 것부터 시작합니다.
그 목록은 다양한 광원 속성을 기반으로 더 컬링할 수 있는데, Smolder 광원 클러스터에서 컬링하는 광원과 유사합니다.
하지만 무엇보다도, 주변에 Smolder 볼륨이 그리 많지 않습니다.
어떤 Smolder 볼륨과도 겹치지 않아 볼류메트릭 그림자가 필요 없는 광원은 모두 손쉽게 컬링할 수 있습니다.
그러면 그림자 개수가 매우 관리 가능한 수준으로 줄어드는데, 대부분의 구역에서 보통 10~20개 정도입니다.
여기 보시는 영상은 그때 녹화한 것으로, 주변에 Smolder 볼륨이 전혀 설정되어 있지 않은 게임의 한 구역입니다.
이것은 컬링 시스템의 힘을 보여주지만, 더 중요한 것은 제가 임의의 위치에 볼륨을 떨어뜨렸을 때 그것이 그냥 작동하는, Smolder의 완전한 가능성이 마침내 실현되는 것을 처음으로 본 순간이었다는 점입니다. 라이팅, 볼류메트릭 그림자, 테이블 위 병들과의 투명 통합까지 말이죠.
이는 또한 제가 가장 좋아하는 Smolder 묘기 중 하나를 만들어내는데, 볼륨을 사용해 게임 내 전체 구역을 어둡게 만들 수 있습니다. 이는 연막 가젯을 사용해 출시된 게임에서도 작동하며, 플레이어가 그것을 광원에 던지면 이런 효과를 얻을 수 있습니다.
이런 볼류메트릭 그림자를 10~20개씩 두면 렌더링 비용이 꽤 클 것처럼 들리지만, 실제로는 그렇지 않습니다.
컴퓨트 셰이더에서 실행되기 때문에, 그냥 async compute에서 실행할 수 있습니다.
그리고 어떤 GPU 프레임 데이터에도 의존하지 않고 볼륨만 입력으로 필요하므로, 프레임 중 거의 아무것도 실행할 수 없는 구간에서 실행할 수 있습니다.
콘솔에서는 이를 강하게 스로틀링할 수 있고, 실제로 그렇게 하여 그래픽 큐에서 진행되는 작업을 느려지게 하지 않도록 합니다.
이 모든 것을 통해 Smolder 그림자는 그렇지 않았다면 사용되지 않았을 GPU 자원을 사용하므로, 사실상 공짜로 렌더링됩니다.
이제 모든 핵심 기술 시스템이 구현되고 저희가 겪던 과제들이 해결된 지점에 왔으니, 성능과 품질을 살펴보겠습니다.
Smolder의 목표 중 하나는 시스템 자체에 시간적 필터링을 두지 않는 것이었습니다. 다만 그렇다고 해도, TAA 형태로 전체 프레임에 대한 필터링은 존재합니다.
그것이 Smolder의 비주얼 품질을 개선할 기회를 주었습니다.
가장 명백한 것은 블루 노이즈를 사용해 레이마칭 동안 픽셀별로 샘플 깊이를 오프셋하는 것입니다.
이는 이 시점까지 저희가 가지고 있던 구조적 아티팩트를 깔끔하게 정리해 주었습니다.
그 대가로 볼류메트릭에 모션 벡터가 없어서 생기는 고스팅과 싸워야 했습니다.
저희는 3가지 서로 다른 TAA 시스템으로 출시했고, 사용 가능한 입력에 따라 접근 방식을 조정해야 했습니다.
FSR 3의 경우, Smolder를 리액티브 마스크 입력에 연결해야 했고, 그렇지 않으면 매우 심한 고스팅이 발생했습니다.
DLSS의 경우 내부적으로 다양한 프리셋과 모델이 있으며, 리액티브 마스크 입력에 해당하는 것이 없습니다. 저는 주로 초기 트랜스포머 모델에서 애를 먹었습니다. 좋은 결과를 내려면 픽셀별 노이즈를 유지하는 것이 극도로 중요했고, 일부 상황에서 라이팅을 절반 해상도로 실행하던 테스트 코드를 제거해야 했는데, 그것이 대부분의 문제를 일으켰습니다.
마지막으로 업그레이드된 PSSR에서는 별도 작업 없이도 훌륭한 결과를 얻었고, 다행히 이를 위한 특별한 작업을 하지 않아도 되었습니다. 그러니 이전 발표자인 Daniel과 그의 팀이 이에 기울인 노고에 감사를 전합니다. 덕분에 제 일이 훨씬 수월해졌습니다.
또한 제 많은 질문에 답해주고 각자의 기술에서 최대한을 끌어내도록 도와준 하드웨어 벤더 팀들에게도 감사드려야 합니다.
성능 면에서 저희는 전반적으로 꽤 괜찮은 상태였습니다.
알고리즘을 위한 좋은 핵심 아키텍처를 구축하는 것이 이를 위해 매우 중요하며, Smolder의 높은 웨이브 일관성은 여기서 극도로 강력합니다.
세그먼트는 이미 샘플 수를 최소로 줄이며, 볼륨의 복셀 크기에 따라 샘플 크기를 조정해 과도한 샘플링을 피합니다.
겹치는 영역에서는 더 작은 스텝 크기를 선택했습니다.
가능한 경우 웨이브 인트린식으로 데이터 로드를 벡터화하며, LDS와 VGPR 사용량 사이를 손쉽게 절충할 수 있습니다.
또한 투과율이 0에 가까울 때 레이마칭을 조기에 멈추는 것과 같은 전형적인 상식적 연산도 수행합니다.
남아 있던 주요 성능 문제는 투영 행렬로 인한 샘플 수의 확장이었습니다.
렌더링 비용은 화면에서 차지하는 면적에 비례해 커집니다.
저는 그 특정 문제를 다루기 위해 1월에 3주를 계획해 두었습니다.
하지만 프로덕션의 현실이 또다시 들이닥쳤습니다. 이 시점에서 저희의 전체 렌더 성능이 여전히 필요한 수준에 이르지 못해, 저는 계속 거기에 집중해야 했습니다.
그래서 1월의 그 3주는 결국 4월의 두 번의 토요일이 되었습니다.
저는 가장 명백한 아이디어에 집중해야 했습니다. 바로 카메라에 가까울 때 볼륨을 절반 또는 1/4 해상도로 렌더링하는 것입니다. 분명히 저는 볼류메트릭 파티클 시도에서 교훈을 얻지 못했습니다.
구현은 매우 쉬웠지만, 공간적 업샘플링이 좋은 결과를 내지 못했습니다.
또한 TAA 통합의 픽셀별 노이즈 규칙을 깨뜨렸고, 그 결과 극도로 심한 고스팅이 발생했습니다.
이 성능 문제에 대해 다른 해법을 찾아야 한다고 판단했습니다.
Smolder의 캡처를 살펴보니, 샘플 비용의 상당 부분이 라이팅 계산에서 왔고 밀도 조회는 그중 작은 일부에 불과했습니다.
그래서 전체 이미지를 다운스케일하는 대신, 라이팅을 더 낮은 충실도로 평가하는 데 집중했습니다.
아이디어는 꽤 단순합니다. 웨이브 내 라이팅에 대한 샘플링 레이트를 추적하고, 스레드 그룹이 더 낮은 샘플링 레이트로 전환해 그룹 내에서 작업을 공유하게 합니다.
전체 해상도로 시작합니다.
전체 웨이브에 대해 투과율이 정의된 임계값 아래로 떨어지면 절반 해상도로 전환합니다.
이제 그룹 내 스레드는 여전히 각각 1개의 샘플을 취하지만, 서로 다른 깊이에서 취합니다. 다만 각자의 원래 광선은 유지하는데, 이렇게 하면 그룹 내에서 샘플을 공간적으로 분산시킵니다.
그런 다음 스레드는 자신의 샘플을 LDS에 저장합니다.
마지막으로, 캐시된 이 샘플들을 사용해 픽셀 단위 레이마칭을 이어갑니다.
1/4 해상도로 전환할 때도 동일하게 합니다. 여기 시각화는 2D로, 절반 레이트는 4개 샘플을 공유하고 1/4 레이트는 단일 스텝에서 16개를 공유한다는 의미입니다. 투과율을 기준으로 레이트를 낮춘다는 것은 이미 부분적으로 가려져 있고 정밀도가 덜 필요한 볼륨 내부에서 더 낮은 해상도로 렌더링한다는 뜻입니다.
또한 여전히 결과를 픽셀 단위로 누적하므로, 픽셀 단위 깊이 테스트와 픽셀 단위 OIT 및 포그 통합의 이점을 그대로 누립니다.
모든 것이 웨이브 내에 있으므로 LDS를 거칠 필요가 없고 웨이브 인트린식으로도 가능했을 것입니다. 하지만 여유 LDS 공간이 있었고 가능한 한 많은 점유율이 필요했기에, 이 경우에는 그것이 더 나은 해법이었습니다.
하지만 또다시 TAA가 이를 받아들이지 못했습니다. 볼륨 깊숙한 곳에서도 엄청난 노이즈와 고스팅을 유발했습니다. 이를 피하려면 임계값을 너무 낮춰야 해서 성능을 전혀 절약하지 못할 정도였습니다.
픽셀 단위 블루 노이즈를 다시 가져와야 한다는 것이 분명했습니다.
저는 결국 여전히 샘플을 먼저 LDS에 저장했고, 그 부분까지는 로직이 동일합니다.
하지만 그런 다음 단순히 읽어서 적용하는 대신, lerp 값에 픽셀 단위 블루 노이즈 지터를 적용해 한 번에 두 개씩 보간합니다.
이는 앞서 블루 노이즈로 샘플 깊이를 지터링할 때 이미 했던 것과 똑같은 것을, 단지 더 낮은 정밀도로 흉내 낸 것입니다.
그리고 1/4 해상도에 대해서도 다시 동일하게 합니다.
잘 작동했고, 훨씬 더 공격적인 임계값을 허용해 일부 복잡한 연막 가젯 사례에서 약 50%의 성능을 절약했습니다.
또한 필요하면 품질을 일부 희생하며 저사양 타깃으로 확장하는 또 다른 방법을 제공했는데, 예를 들어 거기서는 레이마칭을 절반 정밀도로 시작하도록 선택할 수 있었습니다.
여기 저희가 여전히 얻은 품질과 적응형 샘플 그룹의 디버그 뷰 예시가 있습니다. 품질 면에서는 최적화 없이 실행하는 것과 극도로 가깝고, 가장 중요한 곳에서는 여전히 정밀도를 확보합니다.
디버그 뷰에서 빨강은 웨이브가 1/4 해상도까지 내려갔음을, 초록은 절반 해상도를, 파랑은 웨이브가 항상 전체 해상도를 유지했음을 의미합니다.
이 최적화는 밀도 높은 연막 가젯에서 훌륭하게 작동했습니다.
… 하지만 밀도가 낮은 볼륨에서는 효율이 떨어집니다. 그래도 거기서도 꽤 좋은 절약을 제공하며, 이런 종류의 볼륨은 애초에 실질적인 성능 문제를 일으키지 않았기에 이 상태로 출시하기에 충분했습니다.
저희가 해야 했던 또 다른 최적화는 특히 Xbox Series S를 위한 것이었습니다. 저희는 끝까지 그 기기의 메모리 예산과 씨름했습니다. 개별 Smolder 프레임을 스트리밍할 수 없고 전체 애니메이션을 한 번에만 스트리밍할 수 있었기 때문에, Smolder는 경우에 따라 총 수백 MB의 메모리를 사용할 수 있었습니다. 여유 메모리까지 있던 더 큰 콘솔에서는 문제가 아니었지만, Series S에서는 그냥 넘어갈 수 없는 문제였습니다.
저는 패커에서 볼륨의 절반 해상도 버전을 생성하기로 했고, 그것으로 각 애니메이션의 메모리 사용량을 약 80~85% 줄였습니다. 이 변경은 런타임 코드를 전혀 바꿀 필요가 없었기에, 바쁜 시기에 저희 핵심 엔진 프로그래머 중 한 명이 저를 돕기 위해 실제로 이 변경을 구현해 주었습니다.
그가 한 일은 단순히 리소스 베이커에서 OpenVDB 라이브러리를 사용해 입력을 다운스케일한 뒤, 기존 코드를 그대로 실행한 것이었습니다. Smolder 헤더에는 다음 밉으로의 오프셋을 담은 필드가 추가되었습니다. 저희 엔진에서 Xbox Series S와 X는 동일한 리소스를 공유하므로, 두 밉을 모두 디스크에 넣고 로드 시점에 어느 것을 사용할지 선택해야 했습니다. 완벽하지는 않지만 문제도 아니었습니다. 좋은 부수 효과로, 이는 PC에서도 추가 확장 옵션을 제공했는데, 최저 설정에서 절반 해상도 밉을 사용해 6GB VRAM 최소 사양에 맞췄습니다.
이것으로 구현 측면은 마무리입니다. 게임 내에서의 몇 가지 예시입니다.
구름의 경우, 이 범용 접근법이 좋은 결과를 냈지만 이상적으로는 라이팅 모델이 약간 달라야 할 것입니다. 이는 앞으로 살펴볼 만한 부분일 수 있습니다.
제가 정말 좋아하는 또 다른 장면입니다.
… 그리고 게임 전체에서 단연 제가 가장 좋아하는 장면으로, 바로 게임 시작 부분에 나옵니다.
성능 수치에 대해 이야기해 보겠습니다. 여기 PS5 동등 품질 설정에서의 여러 사례가 있습니다. 이 수치에는 async 그림자 렌더링 비용이 포함되어 있지 않습니다.
전반적으로 시스템은 그 역할에 비해 꽤 잘 작동한다고 생각하지만, 분명 개선의 여지가 많습니다. 다만 제 할 일 목록에는 성능 관련 아이디어가 20개가 넘게 있어서, Smolder가 훨씬 더 빠르게 구동될 수 있다고 상당히 확신합니다.
여기서 몇 가지를 짚어보고 싶은데, 우선 AMD 카드가 Smolder에서 자신의 체급을 훨씬 뛰어넘는 성능을 내는 경향이 있다는 점입니다. 이는 AMD 기반 콘솔에도 적용됩니다.
이는 그것들이 wave64 모드로 구동되고, Smolder의 강하게 협업적인 코드가 이를 많이 활용할 수 있기 때문입니다. 32 크기의 웨이브에 비해 컬링에서 약간의 비효율이 생기지만, 성능에 큰 영향을 주지는 않습니다.
그렇지만 이는 32 크기 웨이브로 구동되는 카드에서 Smolder의 성능을 훨씬 더 끌어낼 수 있다는 힌트이기도 하며, 앞으로 이를 조사해야 할 것입니다.
또 하나 짚고 싶은 것은 서로 다른 해상도에서의 5060Ti 성능 수치입니다. 보시다시피 우리가 취하는 샘플 수(이 경우 렌더링하는 픽셀 수)에 따라 극도로 선형적인 성능 확장을 얻습니다. 이는 주 광선과 그림자 광선의 분리가 확실히 효과가 있었음을 말해줍니다.
동적 해상도 스케일링으로 구동하는 콘솔에서도 동일한 선형 확장을 볼 수 있습니다. 그 선형적 특성 덕분에 동적 해상도 스케일링은 극도로 효율적이며, 해상도를 지나치게 공격적으로 낮출 필요가 없습니다.
그래서 저희가 007 퍼스트 라이트에 최종적으로 출시한 것은 무엇일까요? 원래의 요구사항 목록을 기억하신다면, 그 모든 것이 게임에 들어갔습니다. 저희는 게임에 출시할 만큼 충분히 잘 작동하는, 완전히 통합된 범용 볼류메트릭 이펙트 렌더러라는 목표를 달성했습니다. 아직 Switch 2에는 출시하지 않았지만, Smolder를 이미 Xbox Series S, 스팀 덱, 저사양 PC 타깃에 출시했습니다.
출시 직전에 찾아본 한 통계는 게임에 결국 450개가 넘는 Smolder 볼륨이 들어갔다는 것이었습니다. 연막 가젯을 위한 기술을 만든다더니 말이죠. 제게 이것은 훌륭한 신호이며, 이를 보게 되어 매우 기쁩니다. 아티스트들은 볼류메트릭 이펙트 작업의 독특함에 빠르게 적응했고, 이는 Smolder로 훌륭한 워크플로를 지원한다는 목표가 잘 이루어졌음을 보여준다고 생각합니다. 다만 이 기술을 이렇게 늦게 게임에 밀어 넣으면서 생긴 스트레스와 골칫거리는 없었더라면 좋았을 것입니다.
하지만 이것이 여전히 명백한 첫 번째 버전이라는 점도 분명히 해야 합니다. 성능은 좋지만 일부 시나리오는 아직 개선이 필요합니다. 또한 바랐던 것보다 Smolder에 쓸 시간이 훨씬 적었기에, 언젠가 다시 돌아가 멈춘 지점에서 이어가기를 고대하고 있습니다.
다음 할 일 목록으로 말하자면, 꽤 깁니다.
성능 작업 외에도, 메모리 제약에 얽매이지 않도록 애니메이션을 제대로 스트리밍하고 싶습니다.
또한 그 실시간 유체 시뮬레이션을 Smolder에 반드시 넣을 것이며, 그것은 이 기술의 엄청난 업그레이드가 될 것입니다.
OIT와 볼류메트릭 포그의 통합을 제대로 고쳐야 하고, 아티스트들에게 더 많은 도구도 제공하고 싶습니다.
색상과 이미시브 지원이 떠오르고, 단일 범용 위상 함수 대신 볼륨별 위상 함수를 지원하는 것도 좋을 것입니다. 장기적으로는 아티스트가 평소의 머티리얼 셰이더 그래프로 디자인할 수 있는 볼류메트릭 머티리얼을 지원하고 싶지만, 그건 조금 너무 야심찰 수도 있습니다.
아직 할 일이 많고, 언젠가 미래에 Smolder 2편에 대해 이야기하는 것을 분명히 고대하고 있습니다.
팀에 몇 가지 감사를 전해야 합니다. 무엇보다도 이 기술을 저와 함께 밀어붙인 Martin과 유체 시뮬레이션 기술을 만들고 있는 Asger에게 감사합니다. 두 사람 모두 끊임없이 극도로 값진 피드백을 주었고, 첫 시도가 실패했을 때도 저에게 인내심을 잃지 않아 준 것에 매우 감사합니다.
렌더 측에서는 특히 저를 위해 수백 건의 코드 리뷰를 해주고, 제가 다른 의견이 필요할 때마다 함께 점검 회의에 앉아준 Owen과 Jon에게 감사하고 싶습니다.
또한 OpenVDB 리소스 패커 작업을 해준 코어 팀의 Arnau와 Ivan, 그리고 그들의 작업을 해준 IOI 테크 아트 및 렌더 팀 전체에게도 감사하고 싶습니다.
마지막으로, 이곳에서 발표하게 해주고 모든 슬라이드를 검토하며 피드백을 준 Natasha에게 감사하고 싶습니다.
오늘 이 발표에 함께해 주셔서 감사합니다. 전설적인 스탠퍼드 버니의 Smolder 버전으로 마무리하며, 이제 질의응답 시간을 조금 가질 수 있을 것 같습니다.
Google Slides 로드 중
docs.google.com
'TECH.ART.FLOW.IO' 카테고리의 다른 글
| [SIGGRAPH 2026] SPEEDING UP PATH TRACING VIA ORCA (ONLINE RADIANCE CACHE ACCELERATION) (0) | 2026.08.05 |
|---|---|
| [공유] Box3D for UnrealEngine (0) | 2026.08.05 |
| [YOUTUBE] 시그라프 2026 리얼타임 라이브 (0) | 2026.07.28 |
| [번역] UE4 UE5 골격 애니메이션 고급 로코모션 시스템 (ALSV4) (1) | 2026.07.28 |
| [번역] UE4 UE5 스켈레탈 애니메이션 고급 로코모션 시스템 ALS 회전 (0) | 2026.07.28 |