2023년 3월 한국으로 귀국 한 이후에 계획도 많이 설립하고 단계별로 뭘 해야할 지도 많이도 생각 하고 결정 했지만 뜻한 대로 실천이 잘 되지 않네요.
그러다 보니 컨설팅 해 주는 회사 업무가 끝나고 집에 오면 뭐라도 해야 할 것 같아서 예전에 공부 하면서 번역 해 놓은 것들 위주로 글을 올리고 있습니다. 하하하. 별루네요.
아마 이 글을 번역 했던 때가 2022년 여름 쯤... 유니티 커스텀 RP 를 개발 할 때 RVT 를 추가 하는 과정이었을 겁니다. 엔진팀에서 주도적으로 IOS 와 안드로이드에서 스테이블 하게 구동 되는 RVT 피처를 만들었거든요. 그때 TA 파트에서 좀 더 그 이해의 폭을 넓히려고 여러가지 문서들을 봤던 기억이 납니다. 그런데 문제는... 오랫만에 노션에 정리 해 논 글을 보고 이걸 내가 번역 한건지도 기억이나지 않았다는 게... 씁슬 하네요. ㅜㅜ;
Texture Virtualization for Terrain Rendering
Daniel Cornel
Vienna University of Technology
개요
가상 텍스처링은 제한된 물리적 비디오 메모리 내에서 임의로 큰 텍스처 사용을 가능케 하는 기술입니다. 페이지 및 스트리밍 시스템을 통해 밉맵 체인의 현재 보이는 부분만 비디오 메모리에 저장되며, 나머지 데이터는 다른 메모리나 저장 장치에 저장될 수 있습니다. 이것은 고유하고 매우 상세한 텍스처 사용 뿐만 아니라 위성 또는 항공 사진 데이터와 같은 고해상도 이미지를 추가적인 수정 또는 다운 샘플링 없이 실시간 응용 프로그램에서 사용 가능하게 만듭니다. 이 작업은 가상 텍스처링 파이프 라인을 스케치하고 이의 혜택과 한계에 대해 논의합니다. 실시간 응용 프로그램에서 지형의 특성으로 인해, 논의된 방법들은 성능 및 사실적인 지형 렌더링을 위해 특히 중요하며, 이러한 속성과 요구 사항을 고려하여 볼 수 있습니다. 가상 텍스처링의 최근 발전과 가능한 미래 응용 분야 및 가속 기술에 대해 특별한 강조를 두고 있습니다.
Keywords: terrain rendering, virtual texturing, clip-map
1 소개.
지형 표면의 현실적인 실시간 렌더링은 과거 몇 년간 연구 대상이었습니다. 지형의 독특한 특성으로 인해 전통적인 렌더링 방법의 적용이 제한됩니다.
장면에 배치된 일반적인 객체와는 달리 지형은 전체 장면에 걸쳐 매우 큰 주변 환경을 나타냅니다. 큰 범위로 인해, 일부 지역은 눈에 매우 가깝고 일부 지역은 매우 멀리 떨어져 있어 보입니다.
따라서 표면이 인공적인 반복이나 형상화 없이 자연에 의해 형성된 경관으로 보이려면 가까이 있는 미세 구조 세부 정보와 더 먼 주변 환경의 매크로 구조 세부 정보가 모두 필요합니다.
텍스처 매핑이 소개된 이후로 텍스처는 시각적 세부 사항을 기하학에 추가하는 중요한 방법 중 하나였습니다. 그러나 지형의 크기와 하드웨어에서의 텍스처 크기 제한으로 인해 지형 표면 전체를 포함하는 단일 텍스처를 기하학에 매핑하는 것은 현실적이지 않습니다. 지형 텍스처를 합성하기 위해 절차적 텍스처 생성 또는 멀티 텍스처링으로 지형의 크기를 해결하기 위한 몇 가지 접근 방법이 있습니다.
후자의 방법은 CryENGINE 2 [Mittring 2008] 및 Unreal Engine 3 [Epic Games 2012]과 같은 게임 엔진에서 사용되며, Frostbite Engine에서 사용되는 절차적 셰이더 스프래팅 [Andersson 2007]과 같은 정교한 구현은 여러 저주파 및 고주파 텍스처를 절차적으로 생성하여 렌더링 단계에서 혼합되어 광범위한 텍스처 조합의 가능성으로 인해 매우 적은 반복적인 패턴만 표시됩니다.
텍스처 스트리밍은 비디오 메모리에 저장해야 하는 텍스처 부분의 수를 줄이는 데 사용될 수 있지만, 단순한 구현에서는 뷰포인트를 기반으로 장면의 어느 부분에 대해 어떤 부분을 스트리밍해야 하는지에 대한 사전 생성 정보가 필요합니다. 멀티 텍스처링 접근 방법의 단점은 사용되는 텍스처 수에 따라 결과 이미지가 창백해 보일 수 있거나 많은 텍스처 룩업(Look-up)을 필요로 한다는 것입니다. 두 번째 제한은 지형 기하학의 규칙적인 태셀레이션에 의존해 개별 지형 타일에 대한 텍스처링을 할 수 있다는 것입니다.
결국, 현재는 텍스처 합성 접근 방법을 사용하여 지형을 매우 실제적으로 텍스처 처리 할 수 있지만, 혼합된 합성 텍스처 타일만 사용 가능합니다. 렌더링에서 매우 높은 현실성을 달성할 수 있고 항공 사진과 같이 매우 고해상도 이미지를 생성할 수 있는 능력을 가진 경우, 이러한 이미지를 사실적인 렌더링 응용 프로그램에서 텍스처로 사용하기 위한 방법이 필요합니다. 비디오 메모리의 제한 내에서 작동해야 하며 일반 하드웨어에서 실시간으로 수행되어야 하며 일반적인 텍스처 매핑과 동일한 시각적 품질을 제공해야 합니다. 또한 텍스처 처리는 기하학 또는 텍스처 데이터에 제한이 없어야 합니다.
이를 달성하기 위한 첫 번째 개념은 클립 맵 [Tanner et al. 1998]이었습니다. Clip-map은 밉맵 체인의 필요한 하위 집합만 비디오 메모리에 저장할 수 있도록 하므로 이론적으로 임의의 큰 텍스처를 사용할 수 있습니다. 이 개념은 텍스처 가상화에서의 마일스톤으로, Clip-map의 개념은 섹션 2에서 개요가 제시됩니다.
Clip-map의 추가 개발은 최종적으로 콘텐츠 생성 및 렌더링 파이프 라인의 광범위한 적응을 이끌어내어 가상 텍스처링이라는 용어로 요약되었습니다. 이러한 수정 사항 중 대부분은 이미 2004 년에 제안되었습니다. [Lefebvre et al. 2004]. 그러나 id Software의 비디오 게임 'Rage' 발표 및 2011년, 출시를 발표하기 전까지 가상 텍스처링은 널리 알려지지 않았습니다.
따라서 해당 주제에 관한 문헌은 희박하며 Mayer [Mayer 2010]의 석사 학위 논문이 현재 가장 포괄적인 출판물로 기능합니다. Mayer는 또한 표준 용어 및 철저한 평가를 제시하는 참조 구현을 제안합니다. 이는 섹션 3에서 자세히 논의되는 가상 텍스처링 시스템의 일반적인 구조의 참조로 기능합니다. Neu [Neu 2010]가 제공하는 유사한 참조 구현을 고려하기도 합니다. 이 보고서의 목적은 최신 가상 텍스처링 시스템 개념 및 해결될 문제에 대한 통찰력을 제공하는 것입니다.
Mayer와 Neu의 기여가 2010 년으로 업데이트되었으므로 섹션 3.5에서 최근 가상 텍스처링의 개발 및 응용 프로그램에 대한 개요가 제공됩니다.
2 Clip-maps
타너 등 [Tanner et al. 1998]이 소개한 클립 맵은 현재 프레임에서 잠재적으로 볼 수 있는 mip-mapping의 하위 집합만 보유하는 클리핑된 mip-map입니다. 클립 맵 뒤에 있는 아이디어는 매우 큰 텍스처에서 mip-map의 모든 데이터가 한 프레임에서 필요하지 않다는 것입니다.
텍스처 샘플링을 위한 mip-map 레벨 선택은 픽셀과 텍셀 간의 1:1 비율을 목표로 하기 때문에, 창 크기는 mip-map 레벨에서 사용되는 텍셀(texel) 수를 직접 제한합니다. 따라서 스택 크기 (그림 2 참조)보다 큰 mip-map 레벨, 즉 창 크기에 상수 여백을 더한 것은 클리핑 되어 비디오 메모리에 완전히 저장되지 않아도 됩니다.
일정한 창 크기와는 달리 실행 중에 뷰포인트가 변경될 가능성이 높기 때문에 Clip-map stack은 지속적으로 업데이트 되어 필요한 데이터를 포함해야 합니다. 클립 중심은 뷰포인트에서 직접 계산되며, 텍스처 공간에서 관심 중심을 지정하고 클립 맵 스택을 통해 해상도가 낮아지는 텍스처 해상도의 링을 정의합니다.
mip-map 레벨의 크기가 스택 크기보다 큰 경우, 클립 중심 주변의 스택 크기 영역이 mip-map 레벨에서 잘려서 클립 맵 스택에 저장됩니다. mip-map 레벨이 스택 크기보다 작은 경우, 전체 텍스처를 낮은 해상도로 커버하며 클립 맵 피라미드에 저장됩니다. 이렇게 하면 클립 중심 주변 영역의 원하는 세부 레벨이 아직 비디오 카드에서 사용할 수 없는 경우 모든 텍스처 영역의 대체 룩업 텍스처(Look-up texture)로 사용할 수 있습니다.
이 개념은 운영 체제의 가상 메모리 관리와 유사합니다. 메인 메모리의 내용이 더 저렴한 하드 디스크 공간으로 외부로 이동합니다. 모든 외부 메모리 페이지를 추적하는 페이지 테이블과 함께 이를 통해 물리적 메인 메모리보다 훨씬 큰 메모리 공간에 액세스 할 수 있습니다. 이제 가상 텍스처가 처리되고 그 가장 작은 부분도 처리됩니다.
유닛은 하드 디스크에서 먼저 로드되고 그 후 메인 메모리에서 스트리밍 되는 균일한 크기의 텍스처 타일입니다. 이는 스트리밍할 타일의 결정, 스트리밍의 일정 및 타일의 주소화(Addressable)와 같은 여러 문제를 발생시킵니다. 두 프레임 사이에서 잠재적으로 볼 수 있는 타일들의 일관성을 이용하여 스트리밍을 크게 줄일 수 있다는 것은 분명합니다. 시점이 이동하면 현재 볼 수 있는 타일의 이웃 타일들이 곧 필요하게 될 가능성이 매우 높기 때문에 가능한 경우 스트리밍 됩니다.
새로운 타일이 렌더링에 필요하기 전에 스트리밍이 완료되지 않으면 원하는 타일의 낮은 해상도를 fallback texture로 사용합니다. 이 낮은 해상도가 다음 더 낮은 클립 맵 레벨에 포함되어 있기 때문에 필요한 텍스처를 아래에서 위로 스트리밍하는 것이 중요합니다. 클립 맵 시스템의 전체 mip-map을 타일에 액세스하기 위해 Tanner et al. [Tanner et al. 1998]은 클립 맵 레벨과 타일에 대한 편평한 주소 지정 체계를 제안하여 클립 중심의 변경 후 새로운 타일을 기존에 있는 비디오 메모리에 쉽게 추가할 수 있게 했습니다.
그러나 제안된 래핑(Wrapping) 주소 지정으로 인해 하드웨어에서 지원되는 제한된 정밀도와 숫자 범위로 인해 주소 지정 가능한 최대 mip-map 레벨 수와 따라서 전체 텍스처의 크기가 제한됩니다. 이것이 클립 맵의 가장 큰 문제이므로 한정된 범위에서 가상 클립 맵을 비디오 메모리에 저장하는 것이 충분하다는 관찰을 기반으로 클립 맵 자체에 대한 두 번째 가상화 단계를 수행했습니다.
이 추가 가상화를 위해 하드웨어 주소 지정이 제안되어 클립 맵 시스템을 하드웨어로 구현할 수 있게 되었습니다. 클립 맵의 핵심 문제 중 하나는 관심 중심에 의한 타일 결정입니다. 클립 중심과 매핑된 타일 사이의 공간적 관계는 가려지는 것을 고려하지 않으며 필연적으로 명확하지 않습니다.
결과적으로 비디오 메모리에 저장된 타일 중 상당 부분은 해당 지오메트리가 가려져 있거나 시야 면 밖에 있기 때문에 보이지 않습니다. 이와 하드웨어 요구 사항으로 인해 클립 맵이 게임의 지형 렌더링에 미치는 영향은 줄어들었지만, 가상화의 지도 아이디어는 그 이후로 계속 발전해왔습니다.
그러나 수정된 클립 맵의 주목할 만한 구현인 메가 텍스처는 2007년 출시된 Splash Damage의 Enemy Territory: Quake Wars [Kalra and van Waveren 2008]입니다. 클립 맵은 지오메트리 클립 맵이라는 버텍스 버퍼가 저장소로 사용되는 지오메트리 가상화에 매우 적합하다는 것이 입증되었습니다. 지오메트리 클립 맵을 사용하면 지형 변형 [Crause et al. 2011]과 적응형 LOD 시스템 [Losasso and Hoppe 2004; Asirvatham and Hoppe 2005]을 매우 효율적으로 디자인할 수 있습니다.
Unity - Scripting API: SparseTexture
Sparse textures are textures where not the whole texture data can be present in memory at once. They are also commonly called "tiled textures" or "mega textures". Imagine a 16384x16384 texture at 32 bits per pixel - it would take 1GB of memory. The texture
docs.unity3d.com
3 Virtual Texturing
Clip-map은 하드웨어가 프로그램 가능하지 않았고 CPU-GPU 대역폭 제약으로 인해 타일 스트리밍이 비싼 때 소개되었습니다. 이것이 가상화 된 텍스처가 그 당시 일반 렌더링 애플리케이션에 사용될 수 없었던 이유입니다.
비디오 메모리 크기와 대역폭이 오늘날 하드웨어에서 증가했지만, 텍스처 크기는 여전히 너무 크고 증가하는 경향이 있기 때문에 이 문제를 해결할 수 있는 해결책은 기존 대역폭 제약에 맞추기 위해 세련된 적응형 타일 결정 및 관리 프로세스를 통해 스트리밍 비용을 줄이는 것입니다.
이를 달성하기 위한 기본 단계는 Lefebvre et al. [Lefebvre et al. 2004] 및 Barrett [Barrett 2008]에 의해 개발된 효율적이고 완전한 가상 텍스처링 시스템을 제공하는 것입니다. 물리적 텍스처와 전체 mip-map 체인을 균일한 크기의 타일로 분할한 후, 텍스처가 없는 지오메트리는 한 번 렌더링하여 지오메트리의 가시적인 텍스처 좌표를 출력합니다. 이러한 좌표는 버퍼에 저장되어 CPU로 다시 읽혀지며, 가시적인 텍스처 타일이 결정되고 이러한 타일이 비디오 메모리에 업로드 됩니다.
두 번째 마지막 렌더링 단계에서는 지오메트리의 가상 텍스처 좌표가 비디오 메모리에 업로드 된 타일을 가리키는 물리적 텍스처 좌표로 변환됩니다.
이 변환에는 가상 텍스처 좌표의 위치에 물리적 텍스처 좌표를 저장하는 indexing texture(색익화 처리 된 텍스처)가 유지되어 빠른 조회가 가능합니다. 따라서 클립맵과 가상 텍스처링의 주요 차이점은 가시 타일의 향상된 스크린 공간 결정 및 mip-map 레벨을 기반으로 한 토로이드 주소가 아닌 페이지 테이블(Page table)과 유사한 index texture의 사용입니다.
이름과 달리, 가상 텍스처링은 텍스처링 단계가 아닌 전체 시스템입니다. 현재 이 전체 파이프라인은 다른 단계로 구분할 수 있으며(그림 3 참조), 이번 섹션에서는 이러한 단계를 개요합니다.
3.1 Texture 생성
가상 텍스처링은 저렴한 메모리에 저장된 균일한 크기의 타일로 나누어진 완전한 밉맵 체인을 필요로 합니다. 타일 경계에서 올바른 필터링을 위해 각 타일에 대해 추가 데이터를 저장해야 합니다. 이러한 타일을 생성하기 위해 새로운 분할 및 병합 도구 체인이 필요하지만, 이전에 언급된 텍스처링 방법과 비교하여 여러 가지 이점을 제공합니다. 예술가나 사용자는 전체 텍스처 또는 일부분만 작업할 수 있습니다.
이는 이미 수정된 기존 텍스처를 사용할 수 있도록 하며, 클립 맵과 달리 대규모 텍스처에 제한되지 않습니다. 현재 가상 텍스처링 시스템은 텍스처 공간에서의 공간 정보 대신 가시성 정보를 사용하여 업데이트되지 않지만, 렌더링 시 자주 텍스처 변경을 피하기 위해 모든 텍스처를 하나의 거대한 텍스처 아틀라스로 병합할 수 있습니다.
이를 통해 Rage에서 사용된 고유 텍스처링(3.5절 참조)과 같이 장면의 모든 표면을 단일 텍스처로 고유하게 표현할 수 있습니다. Mayer [Mayer 2010]는 고유 텍스처에 대한 효율적인 UV 언래핑, 텍스처 아틀라스 내 타일 패킹, 최적의 타일 크기, 데이터 축소 및 텍스처 압축과 같은 추가 텍스처 생성 주제에 관심을 많이 가지고 있습니다.
3.2 Determination of Visible Tiles
비디오 메모리에 저장해야 할 타일을 결정하기 위해 시스템의 첫 번째 단계는 현재 프레임에서 (잠재적으로) 보이는 타일을 분석하는 것입니다. 또한, 다음 프레임에서 필요한 타일을 미리 캐시 하려면 이들을 효율적으로 예측하는 것이 바람직합니다. 장면의 가시성 정보를 얻기 위해 첫 번째 패스에서 CPU에서 읽을 수 있는 대상으로 렌더링 됩니다. 읽기 작업은 일반적으로 시스템의 병목구간 입니다. 그래서 고성능을 위해 가속 기술이 중요합니다.
3.2.1 Generation and Analysis of Visibility Information
가시적 질감 영역을 결정하기 위해 Lefebvre 등 [Lefebvre et al. 2004]은 기하학을 처음 패스에서 텍스처 공간에서 텍스처 로드맵으로 렌더링하는 두 패스 시스템을 제안합니다. 이것은 모든 타일의 가시성 정보를 포함하는 텍스처 공간의 맵 입니다. 그런 다음, 기하학의 일부가 해당 픽셀에 쓰여진 경우 타일이 사용됩니다. 타일을 정확히 결정하려면 올바른 타일 또는 타일 영역을 대상으로 다수의 후속 LOD 계산이 필요합니다. 이 접근 방식은 가리기가 고려되지 않으므로 보수적인 타일 결정이 가능합니다.
실제로는 필요한 계산 량이 많고 결과가 이상적이지 않기 때문에 타일 결정에 더 이상 사용되지 않으며 자세히 논의되지 않습니다. Barrett [Barrett 2008]이 제안한 더 자연스럽고 정확한 두 패스 접근 방식은 첫 번째 패스에서 일반적으로 화면 공간에서 가시 기하학을 needbuffer [Neu 2010]에 렌더링하는 것입니다.
그러나 실제 텍스처를 기하학에 적용하는 대신, 텍스처 좌표 및 추정 Mipmap 레벨이 needbuffer 에 작성됩니다 (예제의 가장 왼쪽 이미지는 Figure 3을 참조하십시오).
이 정보, 타일 ID는 가상 텍스처의 각 타일을 명확하게 식별합니다.
타일은 일반적으로 선형 매핑된 지형과 같이 여러 프래그먼트에서 필요하기 때문에 결과는 실제 디스플레이 크기보다 작은 버퍼에 저장될 수 있으며, 이는 렌더링 및 읽기 작업 모두를 줄입니다. 이는 데이터를 분석하기 위해 필요한 버퍼를 CPU에서 읽어 들여야 하는데, 이는 전체 시스템을 통해 추가적인 데이터 트래픽을 유발합니다.
이 분석에서는 모든 필요한 타일의 목록이 작성되어 관리 프로세스에 전달됩니다. Mayer [Mayer 2010]가 언급했듯이, 쉐이더에서 수동 mip-map 추정을 dFdx 및 dFdy 함수를 사용하여 수행하는 것은 OpenGL에 의한 미맵 선택과 동일한 결과를 얻지 못할 수 있습니다. 이는 명확하게 지정되지 않기 때문입니다.
dFdx, dFdy - OpenGL 4 Reference Pages
registry.khronos.org
이와 같은 경우, OpenGL의 새로운 확장인 ARB texture query lod를 사용하여 OpenGL mip-map 선택의 결과를 반환할 수 있습니다. Fragment stage level에서 제공되는 새로운 쉐이더 함수는 수동 mip-map 레벨 계산보다 정확하고 빠릅니다. 두 개의 패스 솔루션의 단점은 모든 지오메트리가 두 번 처리되어 상당한 추가 작업을 유발한다는 것입니다. needbuffer 해상도는 디스플레이 크기보다 작을 수 있으며, 첫 번째 패스에는 저해상도 지오메트리를 사용할 수 있지만, 계산 비용이 여전히 많이 듭니다. 다중 렌더 타겟을 사용하면 타일 결정과 최종 렌더링을 단일 패스에서 수행할 수 있습니다. 그런 다음, 현재 프레임을 렌더링하기 전에 현재 프레임에서 계산된 타일 세트를 사용합니다. 이것이 정확하지 않을 수 있지만, 두 프레임의 needbuffer 간의 시간적 일관성으로 인해 편차는 인식하기 어렵습니다. 더 중요한 것은 스트리밍 프로세스가 바로 필요한 타일을 제공할 수 없으므로 두 개의 패스 접근 방식도 뒤쳐질 수 있다는 것입니다. 더욱 문제는 다중 렌더 타겟을 사용할 경우 needbuffer가 메인 랜더 타겟과 동일한 크기여야 하므로 GPU와 CPU 간의 데이터 전송이 크게 증가한다는 것입니다.
3.2.2 GPU-Accelerated Needbuffer Processing
Hollemeersch et al. [Hollemeersch et al. 2010]은 CUDA를 이용한 데이터 축소 GPGPU 방법을 제안하여 버퍼 다운로드 전에 처리 지연을 줄입니다. 그들의 구현은 여러 렌더 타겟에 의존하지만, 이 방법은 두 단계 접근 방식에서도 사용할 수 있습니다. 이웃 픽셀 간의 공간적 일관성으로 인해 needbuffer는 많은 중복 정보를 포함하므로 고유 타일 ID만 포함하는 버퍼를 생성하는 것이 아이디어입니다. 보통 이 버퍼는 원래의 needbuffer보다 훨씬 작으므로 읽기가 더 빠릅니다. 이 구현의 결과 중 하나는 그림 1에 나와 있으며 대규모 항공 사진을 사용하여 실시간으로 섬을 재구성합니다.
Hollemeersch et al. [Hollemeersch et al. 2010]의 평가는 축소된 needbuffer 해상도 또는 전체 해상도를 사용할 때 성능상의 차이가 없음을 보여줍니다. 반면, Mayer [Mayer 2010]의 OpenCL 구현은 낮은 해상도에서 훨씬 더 좋은 성능을 발휘합니다.
이는 CUDA와 OpenCL 간의 내부 API 차이뿐만 아니라 하드웨어 세대 및 제조업체 제한 등 여러 가지 원인이 있을 수 있습니다. Hollemeersch et al.은 CUDA를 사용하는 경우 하드웨어에 따라 needbuffer의 데이터를 사용하기만 하거나 복사할 수 있음을 지적하고 있습니다. 마지막으로, Neu [Neu 2010]의 가상 텍스처링 구현도 여러 렌더 타겟을 사용하며, 따라서 전체 크기의 needbuffer를 사용하지만, 읽기 전에 데이터를 처리하지 않습니다.
그러나 제시된 결과는 비디오 게임에 적합함을 입증하기 위해 다양한 실내 및 실외 게임 레벨에 대해 평가된 전반적으로 높은 시각적 품질을 보여줍니다.
3.3 Tile Management and Streaming
타일 관리 단계는 가상 텍스처 파이프 라인의 주요 구성 요소입니다.
이곳에서 가상 텍스처에 대한 액세스가 제공됩니다. 이전 타일 결정 단계에서 현재 프레임에 필요한 모든 타일 ID가 포함된 목록을 받고, 이 타일들을 사용할 수 있도록 보장합니다. 이를 위해서, 세 가지 작업이 수행됩니다.
참조 텍스처의 유지 관리, 타일 로딩 및 스트리밍.
3.3.1 Maintenance of the Indirection Texture
간접 텍스처는 가상 텍스처 좌표를 물리적 좌표로 변환하는 페이지 테이블과 비교할 수 있는 구조입니다. 이는 물리적 비디오 메모리의 타일이 타일 캐시에 저장되기 때문에 필요합니다. 이 타일 캐시는 주소 지정 프레임으로 분할된 큰 텍스처입니다.
하지만 가상 텍스처의 모든 타일을 저장할만큼 충분히 크지 않기 때문에 현재 보이는 표면에 따라 내용이 계속 변경됩니다. 이러한 모든 변경 사항을 추적하는 것은 간접 텍스처의 역할입니다. 따라서 간접 텍스처에는 각 가상 텍스처 타일과 해당 미맵 체인이 하나의 항목으로 표시됩니다. 렌더링 단계에서 항목은 물리적 텍스처나 텍스처 배열 [Mittring 2008]을 생성하는 것을 의미합니다.
그러나 이러한 구조는 관리 단계와 렌더링 단계에서 모두 필요하기 때문에 CPU 측에서도 쿼드 트리로 나타낼 수 있습니다. 쿼드 트리는 각 타일에 대한 상태 정보를 저장해야 합니다.
예를 들어, 이미 로드되어 있는지 여부 등입니다. 가상 텍스처에서의 타일 위치는 간접 텍스처에서의 위치와 일치하므로 needbuffer에 저장된 타일 ID를 사용하여 해당 타일의 간접 텍스처 값을 직접 참조할 수 있습니다.
타일 결정 단계에서 요청된 각 타일에 대해 타일 캐시에 이미 있는지 확인합니다. 이 경우 로드 중이거나 스트리밍 중인 경우가 아니라면, 스트리밍을 시작해야 합니다.
스트리밍할 모든 타일은 우선순위 큐에 저장되며, 이는 시야점과의 거리 또는 이 타일에 대한 요청 빈도 등과 같은 지정된 기준에 따라 계속 업데이트됩니다. 타일 우선순위는 이 타일 또는 이 타일이 없을 때의 시각적 영향을 측정하는 기준으로 볼 수 있습니다. 일반적으로 낮은 해상도의 타일이 더 높은 우선순위를 갖는데, 이는 대체 텍스처로 사용될 수 있기 때문입니다. 이로 인해 런타임에서 전체 장면에서 세부 정보가 점진적으로 증가합니다. 보수적인 타일 결정 또는 타일 예측이 구현된 경우, 여분의 용량이 있으면 이러한 추가 타일도 미리 캐시할 수 있습니다.
Neu [Neu 2010]는 다양한 페이지 우선순위 휴리스틱에 많은 관심을 기울이며, 구조적 유사성을 측정하는 방법으로 시각적 품질을 상세하게 평가합니다. 또한, 현재 카메라 이동을 추적하고 다음 프레임에서 필요한 타일을 예측하기 위해 LookAhead 카메라 개념을 소개합니다.
3.3.2 Loading of a Requested Tile
가장 우선순위가 높은 타일을 스트리밍하기 전에, 보조 저장소에서 로드해야 합니다.
이 작업은 대상 시스템으로 고려해야 하는 다양한 하드웨어 구성 때문에 실시간으로 수행하는 것은 쉽지 않은 작업입니다. 간단한 시나리오에서는 하드 디스크 드라이브에 있는 모든 타일이 메인 메모리로 로드되어 스트리밍 준비가됩니다.
심지어 이 경우에도 메모리 인터페이스, 크기 및 속도, 저장 장치 유형(HDD, SSD) 및 인터페이스의 다양성은 매우 큽니다. 느린 하드 디스크의 영향을 줄이기 위해 최근 로드된 타일의 이웃 타일을 미리 메인 메모리에 두 번째 캐싱 레벨을 만드는 것이 작은 개선입니다. 타일은 이동식 또는 광학 저장 장치에 저장될 수도 있습니다.
콘솔용 비디오 게임의 경우 타일을 직접 DVD에서 로드해야하는 경우가 있습니다. 그러나 DVD의 제한된 저장 용량 때문에 Rage 게임과 강하게 압축 된 텍스처 데이터를 세 개의 듀얼 레이어 DVD에 저장하고 런타임에서 교환해야했습니다. 광학 장치에서 읽는 것을 최적화하려면 큰 청크를 순차적으로 읽어야 하므로 타일 크기를 선택하는 데 영향을 미칩니다. [Mittring 2008]에 따르면 느린 저장 장치에서 지형 텍스처를 로드하는 더 깊은 이해가 제공됩니다.
데이터 획득의 또 다른 방법은 인터넷을 통한 것이며 특히 유망합니다. Mittring은 이미 광학 장치의 대안으로 멀티플레이어 게임의 전체 게임 레벨을 스트리밍하는 아이디어를 제시했습니다.
최근에는 Andersson과 Goransson [Andersson ¨and Goransson 2012]이 가상 텍스처링의 WebGL 구현을 위해 인터넷을 통한 스트리밍의 실제 구현을 제공했습니다.
휴대용 장치에서는 GPS 내비게이션 서비스에서 위성 사진을 표시하는 등의 작업에 가상 텍스처링과 네트워크 스트리밍이 사용될 수 있습니다. 이러한 경우에는 거의 실시간 스트리밍이 우선순위가 아니므로 타일의 네트워크 전송으로 인한 지연 및 처리하기 위한 제한된 컴퓨팅 파워의 지연이 허용됩니다.
3.3.3 Compression and Encoding of a Tile
타일이 메인 메모리에 로드되면, 그것의 압축 방식 (예 : JPEG, PNG)에 따라 해제되어야 합니다. Mayer [Mayer 2010]의 벤치마크는 고려해야 하는 다른 압축 및 해제 라이브러리에 따라 상당한 성능 차이를 보여줍니다.
일반적으로 JPEG는 보조 저장소에서 더 높은 (손실 압축) 압축 및 PNG보다 더 빠른 해제를 제공합니다. 타일을 해제 한 후에는 GPU에서 사용할 수 있지만 상대적으로 크기가 큽니다.
스트리밍 지연은 일반적으로 가상 텍스처링 파이프 라인의 병목구간이므로 GPU에서 지원되는 텍스처 압축인 DXT를 권장합니다. [Hollemeersch et al. 2010; Mayer 2010]. DXT를 사용하면 업로드 대역폭 및 비디오 메모리 사용량을 크게 줄일 수 있습니다. Hollemeersch et al. 및 Mayer의 기여에서 제안된 가상 텍스처링을 위한 GPGPU 활용의 유망한 추가 기술은 GPU에서 DXT로의 텍스처 변환입니다.
CPU에서 타일을 해제하고 DXT로 다시 압축 한 다음 스트리밍하는 대신, 현재 인코딩으로부터 GPU에서 압축 된 (JPEG) 타일을 DXT로 변환 할 수 있습니다. JPEG는 DXT보다 훨씬 더 우수한 압축 비율을 제공하기 때문에 업로드 대역폭을 더 줄일 수 있습니다. 그러나 GPU 변환 작업은 가끔 Rage에서 스트리밍 가속화에 사용할 때 실패하기 때문에 최근에는 인기가 떨어졌습니다 (3.5 절 참조).
3.3.4 Streaming of a Tile
스트리밍은 로드된 타일을 비동기적으로 처리하는 별도의 스레드에서 수행됩니다. 이 스레드는 로드된 타일을 지속적으로 확인하고 필요한 경우 CPU에서 변환된 타일을 가져옵니다. 단순한 경우에는 캐시가 아직 가득 차지 않았기 때문에 타일을 캐시의 빈 프레임 중 하나에 업로드할 수 있습니다.
캐시가 가득 찬 경우, 캐시 내의 기존 타일 중 하나를 교체할지 이미 로드된 타일을 삭제할지 결정해야합니다. 후자는 모든 캐시된 타일이 현재 필요하며 각 타일의 우선 순위가 최근에 로드된 것보다 높은 경우에만 발생해야합니다.
볼 수있는 정보 및 최근 사용되지 않은 일정을 유지하기 위해 추가적인 타일 속성을 CPU 측 표현에 저장할 수 있습니다.
타일이 마지막 테스트를 통과하면, 마지막으로 물리적 메모리로 업로드됩니다. 그런 다음, 인더렉션 텍스처가 그에 따라 업데이트되어야 합니다.
새 타일을 나타내는 항목은 해당하는 타일 캐시 프레임의 위치와 이미 해당 정보에서 저장된 원래 미맵 레벨을 저장하도록 설정해야합니다. 새로운 타일을 대체 한 경우,이 타일 캐시 프레임을 가리키는 인덱션 텍스처의 모든 항목은 대체 된 타일에 가장 적합한 대체 타일의 프레임을 가리키도록 변경해야합니다.
이전 타일 영역을 커버하고 캐시에 존재하는 이전 타일보다 낮은 가상 미맵 레벨의 타일입니다. 따라서 가상 텍스처 전체를 커버하는 최하위 미맵 레벨 타일을 단일 타일로 업로드하면 언제든지 각 타일에 대한 대체 타일이 보장됩니다.
관리 단계의 마지막 단계는 CPU 측 인덱션 텍스처의 변경 사항을 GPU에 업로드하는 것입니다. 그림 3은 인덱션 텍스처의 예를 보여줍니다.
가상 텍스처의 외부에 위치한 현재 보이지 않는 영역이 몇 가지 저해상도 타일에 매핑되어 있음을 알 수 있습니다.
3.4 Rendering
파이프라인의 마지막 단계에서는 생성된 데이터, 즉 타일 캐시 텍스처와 간접 텍스처를 사용하여 보이는 지오메트리를 올바르게 텍스처링해야 합니다. 지오메트리의 정점당 텍스처 좌표는 가상 텍스처의 위치에 해당하므로 클립맵의 주소 변환과 유사한 변환 단계가 필요합니다. 토로이드 주소 지정 대신, 그림 4에 나와 있는 것처럼 간접 텍스처에서 룩업이 사용됩니다.
3.4.1 Address Translation with the Indirection Texture
물리적 텍스처에 대한 올바른 텍스처 좌표는 해당 영역을 덮는 타일 캐시 내 타일의 위치 및 내부 오프셋에 따라 결정됩니다. 간접 텍스처의 각 텍셀은 가상 텍스처의 타일에 해당하므로 프래그먼트 스테이지에서 보간된 텍스처 좌표로 비필터링 조회를 수행할 수 있습니다. 이 조회는 이미 인덱스 텍스처에 저장된 캐시 내 타일 위치를 반환합니다.
이제 간접 텍스처 업데이트 시 폴백 타일이 쿼드 트리 표현에서 모든 하위 항목으로 전파되는 이유도 명확해야 합니다. 이는 가상 텍스처 좌표마다 캐시 내 타일을 찾을 수 있도록 보장하기 때문입니다.
내부 오프셋을 계산하는 것은 가상 타일 위치에 상대적이므로 타일의 원래 밉맵 레벨에 따라 달라집니다. 이것이 타일을 스트리밍할 때 이미 인덱스 텍스처에 밉맵 레벨이 쓰여진 이유입니다. 밉맵 레벨은 인덱스 텍스처의 세 번째 구성 요소로 저장될 수 있으며 물리적 타일 위치와 함께 검색됩니다. 그런 다음 가상 텍스처 좌표는 밉맵 레벨에 따라 이동 및 스케일 조정되어야 합니다.
해결책의 예는 van Waveren과 Hart [van Waveren and Hart 2010]의 논문에 제시되어 있습니다(그림 4 참조). 그러나 이차 2의 거듭제곱 텍스처와 같은 제한이 있는 셰이더 구현은 적은 수의 명령으로 변환을 수행할 수 있는 산술적인 요령을 사용할 수 있습니다[Barrett 2008; Mittring 2008; Hollemeersch et al. 2010]. 물리적 텍스처 좌표를 검색한 후에는 타일 캐시 텍스처에서 두 번째 조회를 수행하여 텍스처 정보를 가져올 수 있습니다.
이후 렌더링은 평소처럼 수행됩니다. 이 시점에서 타일의 형식이나 내용은 임의로 설정할 수 있습니다. 따라서 노멀, 스펙큘러, 디스플레이스먼트, 라이트 및 섀도우 맵 및 인덕션 텍스처[Mayer 2010]와 같은 모든 유형의 데이터가 가상화되어 셰이더에서 사용될 수 있습니다.
타일 캐시가 2D 텍스처 대신 텍스처 배열로 표현되는 경우 같은 x 및 y 좌표에 대해 텍스처 배열의 서로 다른 레이어에 대해 다른 속성의 타일을 저장하는 것이 쉽습니다. 그런 다음 모든 원하는 레이어에서 조회를 위해 텍스처 좌표 변환을 한 번만 수행하면 됩니다.
3.4.2 Texture Mapping with Filtering
텍스처를 샘플링할 때 필터링은 물론 바람직합니다. 그러나 하드웨어 필터링에 의존하면 타일 경계에서 아티팩트가 발생합니다. 타일 캐시에 저장된 타일은 임의의 타일로 둘러싸여 있으므로, 이진 선형 또는 이방성 필터링에 필요한 모든 정보는 타일 자체에 포함되어야 합니다.
셰이더에서 필터링을 수동으로 수행하는 것이 가능하지만, 각 샘플에 대해 텍스처 좌표를 변환해야 하므로 실행 불가능한 오버헤드를 초래합니다 [Neu2010]. 이것이 왜 3.1 절에서 이미 올바른 필터링을 위해 타일 생성 도구가 경계를 추가해야 한다고 명시되었는지 이유입니다. 타일 경계의 이웃은 필터링을 위해 고려되어야 하기 때문입니다.
그러나 이렇게 하면 타일의 사용 가능한 영역이 감소하거나 타일 크기가 증가하게 되어 시각적 품질을 위해 업로드 대역폭이 증가할 수 있습니다. DXT 인코딩 된 타일을 사용할 때는 올바른 필터링을 위해 경계에 4 x 4 텍셀 블록을 추가해야 합니다 [Mittring 2008].
트리리니어 필터링은 일반적으로 추가적인 미맵 레벨에서 샘플링해야 합니다. Barrett [Barrett 2008]은 물리적 타일 캐시를 사용하여 캐시 콘텐츠를 반 사이즈로 저장하는 것을 제안합니다.
이 방법은 가상 텍스처링이 이미 최적의 매칭 레벨에서 샘플링하기 때문에 충분합니다.
이를 통해 그래픽 API의 트리리니어 필터링을 사용할 수 있지만, Mittring [Mittring 2008]에 따르면 비디오 메모리 소비를 증가시키는 무의미한 부분입니다(4분의 1). 이것은 미맵 레벨에 대한 반 해상도 데이터가 이미 시스템 어딘가에 존재하기 때문입니다. 심지어 타일 캐시 내에 이미 존재할 수도 있습니다. 따라서 Neu [Neu 2010]는 API의 바이리니어 필터링에 의존하고, 프래그먼트 셰이더에서 트리리니어 필터링을 수동으로 수행하는 것을 제안합니다.
이를 위해 간접 텍스처와 타일 캐시에서 두 배의 텍스처 룩업이 필요합니다. 추가적으로, 타일 관리는 다음 낮은 해상도의 필요한 타일도 캐시되도록 보장해야 하므로, 약간 수정된 타일 결정 알고리즘은 각 가시 타일의 추가적인 직접 부모 타일을 요청합니다.
이는 스트리밍 노력과 타일 캐시에서 필요한 타일 수를 증가시키지만, 추가적인 타일의 일부는 이미 대체 텍스처로 캐시됩니다.
3.4.3 Reduction of Pop-In Artifacts
이 시점에서 가상 텍스처 시스템은 일반적인 텍스처 매핑과 함께 대규모 텍스처가 사용된 것처럼 작동해야하지만, 가상의 실제 상황에서 제거하기 어려운 것이 있습니다.
전체 파이프 라인은 업로드나 리드백에서 절대로 멈추지 않도록 비동기 업데이트를 위해 설계되었습니다. 따라서 작업이 아직 완료되지 않았고 렌더링이 시작되면 완료되지 않은 작업을 처리해야 합니다.
이것이 대체 타일이 사용되는 이유입니다. 파이프 라인이 더 빠르게 수행될수록 원하는 출력에 대한 모든 텍스처가 셰이더에서 더 빠르게 사용 가능해집니다. 마지막으로 새 타일의 스트리밍이 완료된 후 어떻게 행동해야 할까요?
새 타일이 다음 프레임에서 바로 텍스처링에 사용되면 타일의 더 높은 디테일은 갑자기 광란스러운 방식으로 팝인됩니다. 이는 레벨 오브 디테일 알고리즘의 팝인과 유사하며 런타임에서 레벨을 부드럽게 전환하도록 강제하는 것으로 처리됩니다. 예를 들어 두 레벨의 결과를 혼합함으로써 [Mayer 2010]입니다.
가상 텍스처에서는 텍스처의 점진적인 혼합을 이미 구현하는 트리리니어 필터링이 사용되는 경우 쉽게 혼합할 수 있습니다. 새 타일이 도착한 후 시간에 따라 낮은 해상도 타일은 높은 디테일로의 부드러운 전환을 강제하기 위해 수동으로 가중치가 매겨집니다. [Mayer 2010].
양선형 필터링과 혼합하기 위한 경우 van Waveren과 Hart [van Waveren and Hart 2010]는 타일 캐시의 디더링 업데이트를 제안합니다. 이것은 매 프레임마다 새 타일의 일부만 업로드하고 낮은 해상도 타일과 결합하는 것을 의미합니다. 이를 위해 새 타일에서 포함된 하위 수준 타일의 영역이 업샘플링되어 타일 캐시에 저장됩니다.
그런 다음이 타일은 더 높은 해상도 타일의 일부를 각 프레임마다 점진적으로 업데이트하여 새 콘텐츠가 완전히 이전 콘텐츠를 대체할 때까지 업데이트됩니다. 이것은 물론 더 많은 스트리밍과 다른 타일의 지연 스트리밍을 유발하므로 좋은 타협점을 찾아야 합니다.
3.5 Recent applications
이전 섹션에서는 가속 기술을 포함한 최첨단 가상 텍스처링 시스템의 완전한 설계가 제시되었습니다.
이 구조는 주로 2010 년에 발표된 Mayer [Mayer 2010] 및 Neu [Neu 2010]의 기여에 기반하고 있습니다. 이후 가상 텍스처링은 대규모 응용 프로그램에서 지형 렌더링을 위한 가치있는 도구가되었습니다.
이에는 비디오 게임 [van Waveren and Hart 2010; Widmark 2012]이 포함되지만 Rage와 같은 인기있는 비디오 게임을 제한하지는 않습니다. 이 섹션은 이러한 최근 개발에 대해 전달합니다. 목표는 이미 넓은 텍스처 가상화 분야에서 제시된 시스템의 구체적인 응용 프로그램 개요를 제공하는 것입니다. 특히 기하학 또는 볼륨 데이터와 같은 일반 데이터의 가상화는 흥미로운 주제입니다.
3.5.1 id Software’s Rage
2007년 발표 이후 id Software의 비디오 게임 Rage는 텍스처 가상화 사용으로 인해 열광적으로 기다려졌습니다. Splash Damage의 Enemy Territory: Quake Wars 및 BRINK에서 지형 텍스처 가상화에 사용된 클립맵과 같은 MegaTextures 구현과는 대조적으로, MegaTextures는 Rage에서 완전한 가상 텍스처링 시스템으로 확장되었습니다. 그러나 2011년 출시 직후, 많은 PC 고객들은 렌더링 및 특히 가상 텍스처링에서 심각한 문제를 겪었습니다.
스크린 전체에 잘못된 타일이 흩어져 보이는 찢어짐 및 깜빡임뿐만 아니라, 아티팩트의 주요 원인은 타일 팝핑 및 일반적으로 느리게 스트리밍되는 타일이었습니다. 많은 경우 대체되지 않은 대체 타일만 표시됩니다.
이 보고서에서는 GeForce GTX 480 비디오 카드, Intel i7-950 CPU, 12GB의 주 메모리 및 솔리드 스테이트 드라이브를 포함하는 시스템에서 1920 x 1200 픽셀 화면 해상도에서 게임을 테스트했습니다. 이로 인해 게임에서 180도 회전하는 데 약 다섯 초가 걸렸으며 모든 저해상도 대체 텍스처가 교체되었습니다. 또한 더 높은 해상도의 타일조차 흐릿하게 보였습니다. 이러한 문제를 해결하기 위해 게임 패치와 타일 캐시 크기와 같은 가상 텍스처링 동작을 변경하는 콘솔 명령에 대한 참조가 게시되었습니다. 패치와 구성 변경 모두 적용한 후 테스트 시스템에서는 더 이상 팝핑 아티팩트나 대체 텍스처가 보이지 않을 정도로 시각적 품질이 크게 향상되었습니다.
버네스 [Burnes 2011]에 따르면, 초기 성능 이슈의 원인은 PC 시스템의 편향적인 적응형 퀄리티 조절입니다. 콘솔 플랫폼에서는 하드웨어가 균일하게 지정되어 시스템이 하드웨어 요구사항에 맞게 조정될 수 있기 때문에 디스크 로딩 지연 시간이 높아도 게임은 처음부터 잘 작동했습니다(3.3절에서 언급한 것처럼). 대조적으로, 다양한 PC 하드웨어 조합때문에 파이프라인의 일부분을 런타임에 하드웨어에 동적으로 적응시켜 부작용을 방지해야 했습니다. 이에는 GPU 트랜스코딩도 포함됩니다. 앞서 언급한 것처럼, GPU 트랜스코딩의 목적은 GPU에서 로드된 텍스처를 압축 해제하여 CPU의 작업 부하를 줄이는 것입니다. 이는 Rage에서 전체적인 성능에 엄청난 영향을 미치므로 패치로 프레임당 GPU 트랜스코딩 수를 제한하거나 완전히 비활성화 할 수 있는 선택지가 제공됩니다. Rage는 이미 GPU를 최대한 활용하기 때문에, Hollemeersch et al. [Hollemeersch et al. [2010]에서 제안한 하드웨어 가속화는 사실 시스템 성능을 떨어뜨립니다. 이는 JPEG와 유사한 압축 방식이 병렬화하기 어렵기 때문에 GPU 구현의 이점을 충분히 누리지 못하기 때문일 수 있습니다.
Rage는 일반적인 범위와 성능 뿐만 아니라 유니크한 텍스처링을 위한 소규모 텍스처도 가상화한다는 점에서 텍스처 가상화에서의 중요한 발전입니다. 각 지오메트리에 고유한 텍스처를 사용하려는 야심찬 목표 때문에 매 프레임마다 스트리밍해야 하는 타일의 양이 방대하여 게임의 부자연스러운 시작에 일부분의 책임이 있습니다. 그러나 id Software가 이를 대화형 프레임 속도와 전반적으로 인상적인 품질로 구현했다는 것은 더욱 놀라움을 주었습니다(그림 5 참조). 그러나 이를 통해 모든 텍스처를 동일하게 처리할 수 있게 된다는 것은 Rage에서 최근 게임들과 비교하여 작은 객체의 보수적인 텍스처매핑과 비교했을 때 시각적 품질이 크게 향상되지 않는다는 것을 의미합니다. 반면, 매우 높은 세부도와 비교하여 다중 텍스처링 방식에 비해 높은 세부도를 가지는 지형 텍스처에 대한 텍스처 가상화의 이점은 의심의 여지가 없습니다.
3.5.2 Virtual Texturing for WebGL
게임 분야 외에도, 가상 텍스처링은 지리적 데이터 시각화에 있어서 점점 더 중요한 역할을 할 것입니다. 특히 온라인 및 모바일 매핑, 위치 및 내비게이션 서비스는 항공 영상의 가속화된 표시로 큰 이점을 얻을 수 있습니다.
가상 텍스처링의 구현이 모바일 플랫폼에서 일반적으로 가능하다는 것은 Andersson과 Goransson [Andersson and G ¨ oransson 2012]에 의해 WebGL 구현으로 증명되었습니다. 그러나 이 구현에서 상호 작용하는 프레임 속도를 항상 달성할 수는 없습니다. WebGL 및 OpenGL ES 2.0 구현의 우세한 문제점은 제한적인 기능 세트와 불만족스러운 브라우저 지원입니다. 저자들이 언급한 대로, DXT 압축 이미지의 로딩은 아직 불가능하며 픽셀 버퍼 객체의 부재로 인해 needbuffer의 readback 또는 tile의 업로드는 완료될 때까지 전체 스레드를 중단시킵니다. 그러나 이러한 기능이 지원될 때까지 시간이 걸리지 않을 것입니다. 현재 WebGL을 통해 GPGPU 가속화는 불가능합니다. WebCL API는 이미 개발 중이므로, 제시된 몇 가지 수정 사항은 곧 WebGL에 적용될 수 있을 것입니다.
3.5.3 General Data Virtualization
Rage와 관련된 가상 텍스처의 등장은 가속화 방법에 대한 연구 및 개발에도 이바지하였습니다. 따라서 일반적으로 데이터 가상화에 대한 관심이 증가하고 있습니다. 가상 텍스처 개념과 마찬가지로, 기하학 가상화를 위한 개념도 clipmap과 같이 확장할 수 있습니다. Sugden 및 Iwanicki [2011]의 최근 기여 중 하나는 MegaTextures에 대한 비유로 Mega Meshes 시스템이며, 이는 게임 개발에서 조각 작업 도구와 가상 텍스처를 결합합니다. 콘텐츠 작성에서는 대량의 기하 데이터가 여러 분할 수준으로 이루어진 쿼드트리와 같은 계층 구조에 저장되어 스트리밍될 수 있습니다. 런타임에서는 가상 텍스처 시스템에서 서브디비전 레벨에 따른 텍스처 데이터(예: 법선 및 환경 빛 데이터)가 사용됩니다.
일반적으로 3D 텍스처로 표현되는 볼륨 데이터를 가상화하는 것은 Crassin et al. [2008]에 의해 GigaVoxels 용어로 소개되었습니다. 2011년에는 Crassin이 e.g. 생체 의학 응용 프로그램 및 복셀 기반 게임 엔진에서 사용 가능한 볼륨 가상화를 위한 완전한 시스템을 제안했습니다. 이는 볼륨을 사용하면 기하학 및 표면 텍스처의 (인위적인) 분리를 극복할 수 있기 때문에 매우 흥미롭습니다. 따라서 기하학 및 텍스처 스트리밍을 통합할 수 있지만, 이러한 엔진을 위한 콘텐츠 작성은 훨씬 더 비싸집니다.
Mayer et al. [2011]의 기여는 가상 텍스처와 포인트 클라우드 렌더링의 결합으로 문화 유산 보존을 위한 것입니다. 그러나 이 응용 프로그램에서는 포인트 클라우드를 가상화하지 않고 다른 검증된 out-of-core 렌더링 방법에 의존합니다. 그럼에도 불구하고 이것은 실시간 렌더링이 가는 방향을 보여줍니다.
3.5.4 Hardware-Implemented Virtual Texturing
이러한 혁명의 결과로, 가상화 파이프 라인을 위한 부분적 하드웨어 지원이 곧 사용 가능해 보입니다. 라데온 HD 7970과 같은 AMD의 Graphics Core Next 아키텍처를 사용하는 비디오 카드는 다시 설계된 프래그먼트 셰이더 단계와 AMD 희소 텍스처 확장을 통한 부분적으로 상주하는 텍스처 [Bilodeau et al. 2012]을 지원합니다.
이들을 사용하면 부분 할당으로 대규모 텍스처를 정의할 수 있습니다. 가상 텍스처 사용을 위해 인다이렉션 텍스처와 타일 캐시를 사용하지 않아도 되며, 모든 가시적인 타일을 희소 텍스처에 저장할 수 있습니다. 부분적으로 상주하는 텍스처를 내부적인 텍스처 좌표 계산을 통해 가상 텍스처 좌표에 사용할 수 있다면, 하드웨어에서 전체 가상화 단계를 수행할 수 있습니다. 타일 결정을 위해 셰이더는 부분적으로 상주하는 텍스처에 대한 조회가 저장된 데이터를 가져오도록 수정되었으며, 추가로 가져오기 상태를 반환합니다. 조회 위치에 데이터가 저장되어 있지 않은 경우 해당 타일이 아직 사용 가능하지 않으며 스트리밍해야 함을 나타내는 Fail이 반환되어 CPU에서 읽을 수 있습니다. 또 다른 상태는 LOD 경고이며, 텍스처의 미리 정의된 LOD 한도에 따라 현재 타일의 고해상도 표현이 곧 필요할 수 있음을 나타내므로, 하드웨어 지원 타일 예측을 제공합니다. 이 확장 기능으로 필터링과 같은 작업도 단순화됩니다. 부분적으로 상주하는 텍스처를 사용하는 가상 텍스처의 미래 구현은 이 확장 기능이 약속을 지킬 수 있는지를 보여줄 것입니다.
4 Conclusion and Outlook
지형의 특성으로 인해, 현재의 항공 및 위성 영상 취득 기술은 큰 이점을 가질 수 있습니다. 이들은 전체 장면에 미치며, 따라서 만족스러운 방식으로 텍스처링 하기 위해 많은 양의 데이터가 필요합니다. 이는 현재 하드웨어의 텍스처 크기 및 총 메모리 소비 능력을 초과합니다. 런타임에서 한 프레임에 대해 텍스처 데이터 및 mipmaps의 일부만 필요하다는 것을 관찰하여, 이 정보를 감지하고 업로드하기 위한 다양한 접근 방법이 제시되었습니다. 운영 체제의 가상 메모리 관리를 활용하여 텍스처 데이터 가상화를 위한 클립맵을 도입하여 더 유연하고 효율적인 가상 텍스처링으로 진화했습니다. 본 보고서에서 제시 된 가상 텍스처링 파이프 라인은 세 개의 독립적인 단계로 구성된 다중 스레드 시스템에 의존합니다.
이 시스템의 주요 이점 중 하나는 화면 공간에서 타일 결정을 제공하여 타일 가시성 문제에 대한 정확한 해결책을 제공한다는 것입니다.
소프트웨어 및 하드웨어의 가상 텍스처링의 다른 단계에서 품질 향상 및 가속화에 대한 여러 가능성이 논의되었지만, 일반적인 응용 프로그램에 대한 이점은 아직 평가되지 않았습니다.
특히 AMD 비디오 카드의 부분적으로 상주하는 텍스처에 대한 하드웨어 지원은 가상화 및 특히 가상 텍스처링이 대중화될 수 있다는 희망을 제공합니다. 가상 텍스처링을 구현하는 것은 대규모 응용 프로그램에 대해서만 효과적인 복잡한 작업이며, 파이프 라인의 단일 구성 요소를 효율적으로 작동시키는 것은 더 어려운 작업입니다.
가상 텍스처링의 기동이 어려운 Rage는 이러한 구성 요소의 상호 작용이 많은 미세 조정을 필요로 하며, 미래에는 더 견고한 솔루션이 필요할 수 있습니다. 게임에 따라 고려해야 할 한 가지 사항은 작은 객체의 고유 텍스처링이 스트리밍 오버헤드와 정적 텍스처와 비교하여 유용하고 가치 있는지 여부입니다. 텍스처 압축의 GPGPU 가속화가 성능에 부정적인 영향을 미칠 수 있음을 깨달았으므로 이러한 동적 시스템의 모든 구성 요소에 대한 작업 부하 분산에 대한 더 조심스러운 작업이 필요합니다. WebGL 및 OpenGL ES는 실시간 가상 텍스처링에 적합하지 않아 보입니다.
OpenGL에서 이미 흔한 기능이 없으므로 모바일 장치에서 가상 텍스처링은 한 또는 두 단계 뒤에 머물고 있습니다. 그러나 이러한 장치에서 얻을 수 있는 품질을 고려하면, 예술가가 전체적으로 구성 할 수 있는 고유한 대규모 텍스처로 가능한 가상 텍스처링이 현재 지형 텍스처링 방법보다 우수합니다.
적절한 타일 우선 순위 계산을 통해 아티팩트를 최소화 할 수 있기 때문에 다른 현재 텍스처 스트리밍 방법보다 우수합니다. 이것이 모든 종류의 데이터의 가상화가 미래 렌더링 시스템에서 계속되고 채택될 것으로 안전하게 추측할 수 있습니다.
'TECH.ART.FLOW.IO' 카테고리의 다른 글
| 테크니컬 아티스트의 역할 (2) | 2023.09.03 |
|---|---|
| [번역]A Data-Driven Paradigm for Precomputed Radiance Transfer. PART-1 (0) | 2023.09.01 |
| [Example]테크아트팀 조직 운영의 예. 타입 1 (0) | 2023.08.29 |
| Made a short but strong announcement at ADOBE DAY 2023. (0) | 2023.08.29 |
| [번역]Engine architecture overview (0) | 2023.07.14 |