'Precomputed Radiance Transfer'에 해당되는 글 1건

  1. 2009.12.07 PRT : Precomputed Radiance Transfer


아래에서 퍼옴

http://allosha.tistory.com/category/니시카와%20젠지/PRT



Precomputed Radiance Transfer(PRT)란?


2009-06-04 01:15:11
現在、次世代の3Dゲームグラフィックス技術として実用化が進められているものにPRT(Precomputed Radiance Transfer)がある。 PRTは日本語訳では「事前計算・放射輝度・伝搬」ということになり、なにをするものか難解 ...... >> Read more

(C) Mainichi Communications Inc. All rights reserved.


오늘날, 차세대 3D게임 그래픽스 기술로서 실용화가 진행되고 있는 것으로 PRT(Precomputed Radiance Transfer)가 있다.

PRT는 일본어 번역에서는 「사전계산 방사휘도 전달」이라 하고, 무엇을 하는 것일까 난해한 키워드들로 되어 있지만, 현재, 근대 GPU의 활용 테마로서는 가장 유행하는 것들 중 하나이며, 근대의 실시간 3D그래픽스를 말할 때 아무래도 피할 수 없는 것이 되고 있다.

이번회 부터는, 이 PRT 기술에 대한 기본사항과 최첨단 PRT기술의 최신 동향까지를 소개한다.

PRT는 실시간 글로벌 일루미네이션(Global Illumination)

오늘날의 실시간 3D그래픽스에서는, 광원을 설정하면 기본적으로는 그 광원의 빛을 직접 받는 음영계산 밖에 하지 않는 약식처리가 대전제로 되어 있다.

현실 세계에서는, 광원으로부터의 빛이 제삼자에 의해 차폐된다거나, 또는 빛이 어떤 물체에 닿아서 반사한 그 빛도, 다시 광원이 될 수 있다(2차 광원). 그러나, 현재의 실시간 3D그래픽스에서는 이러한 처리는 생략되거나 유사방법(Fake)으로 대신하는 경우가 많다. Fake라고 해도 그 나름대로 이치에 맞는 것처럼 보이면 상관없는 것이지만, 무언가 위화감이 남아 버리는 국면도 적지는 않다.

이러한 차폐나 상호반사등을 다뤄, 복잡한 조명을 재현하려고 하는 것이「 대국적인 조명 기술」(Global Illumination : 글로벌 일루미네이션)이라는 기술/개념이다.

하지만, GI는 복잡하고 계산량도 많기 때문에, 정식으로 구현된 것은, 실시간에 작동 시키기가 매우 어렵다.

거기서, 이 GI를, 복잡한 빛의 이동에 대해서는 오프라인으로 시간을 들여 미리 계산해 버리고, 실시간 렌더링시에는 그 사전 계산 결과를 이용해서 실현하려는 아이디어가 등장한다.

그 하나가 이「PRT」라는 것이다.

이 PRT가 각광을 받기 시작한 것은, 2002년 SIGGRAPH 2002에서 「Precomputed Radiance Transfer for Real-Time Rendering in Dynamic, Low-Frequency Lighting Environments.」(Peter-Pike Sloan)라는 논문이 발표되고 부터이다.

이 원조적인 아이디어에서는, 어느 씬에 대해 PRT를 실시할 때 , 광원은 움직일 수 있지만「그 씬에 등장하고 있는 캐릭터나 오브젝트는 일절 움직일 수 없다」라는, 실시간 3D그래픽스에 있어서는 치명적인 제약이 있었다. 거기서 「움직이지 않는 배경에만 PRT를 사용한다」라는 한정 조건부로 3D게임 그래픽스에 응용하는 예도 제창되었지만, 메모리 사용량이나 얻을 수 있는 효과의 밸런스를 생각하면 실용성은 낮다고 하지 않을 수 없었다.

그러나, 이 논문이 기폭제가 되어, 각방면에서 연구 개발이 이루어지게 되었다. 그 보람이 있어, 최근 몇년 사이에, 씬을 실시간으로 움직여도 적용할 수 있는 PRT 기법, 말하자면「동적인 PRT」까지도 발표가 되었다.

본연재에서는, 이 동적 PRT의 기초 이론까지를 소개하겠지만, 갑자기 동적 PRT로 넘어가도 의미가 없기 때문에, 가장 기본적인 PRT인 「정적 PRT」……즉 「그 씬에 등장하고 있는 캐릭터나 오브젝트는 일절 움직이지 않는」, 고정적인 씬에 있어서의 정적PRT 부터 차례대로 보고 가기로 하자.(계속)

                                                          PRT의 기본 개념

< 그림 설명>
좌:
현재의 실시간 3D그래픽스
광원, , 벌레
(버블) 이 픽셀의 음영처리는 광원의 차폐나 반사광의 영향을 무시하고 있다.
우:
광원, 반사, 차폐
(버블 상) 하나의 픽셀에 오는 모든 빛이나 차폐를 실시간으로 고려하는 것은 어렵다.
(박스) 이 픽셀에 어떤 빛이 오는지를 사전에 가능한 계산해 두려는 것이 PRT의 기본방침
(버블 하) ?을 사전에 계산 실시간 렌더링 때에는 사전에 구한 "?"의 부분을 사용한다.


CEDEC2006_kor01.zip


Precomputed Radiance Transfer(PRT)의 기본. 정적 PRT


PRT의 기본 ~ 정적 PRT란?

PRT는, 무엇을 미리 계산하는가에 따라 복잡도가 달라진다.

본연재에서 다루는 PRT는, 2006년에 개최된 게임 개발자 회의 CEDEC 2006에서 피라미드사가 발표한 내용을 바탕으로 하며, 「환경맵을 통째로 광원이라 생각하고, 복잡한 차폐를 고려해 실시간으로 렌더링한다」라는 테마로 한정하고 있다.

씬 내의 오브젝트가 움직이지 않는다고 전제하는 PRT가 「정적 PRT」이다. 2002년에 발표된 PRT의 원조격인 논문은 이 정적 PRT였다. 원안 발표자인 Sloan씨는 이전에 마이크로소프트사에서, Direct3D 개발에 깊게 종사한 인물이다.


그 씬을 둘러싸는 정경을 큐브 환경맵으로 만들어, 이것을 광원으로 보고 실시하는 라이팅을 특히 「Image Based Lighting」(IBL)이라 부른다. 본연재에서 해설하는 PRT 라이팅은 이 IBL를 전제로 한다.

IBL : Image Based Lighting의 기본 개념

<그림 설명>
좌:
이런 씬이 있다고 하면...
(버블) 배경을 텍스처에 렌더링해서 환경맵이라 한다.(실제로는 전방위 6면체 환경맵인 큐브맵을 생성한다.)
우:
(박스) 그 환경맵으로 라이팅을 하는 것이 IBL의 기본개념


픽셀 단위의 라이팅을 할 때, 그 픽셀의 방향(법선벡터)에 근거해 큐브 환경맵을 참조하고, 그 텍셀을 광원으로 보고 음영연산을 실시하는 간이기법도 IBL로 불리지만, 여기서 말하는 IBL은 차폐나 그 외의 복잡한 빛의  움직임(음영 뿐만이 아니라, 경우에 따라서는 빛의 침투나 굴절, 반사 등)을 고려한 것을 가리킨다.

IBL에서는 이와 같이 6면체 구조의 전방위 환경맵을 광원으로서 이용하는 경우가 많다

<그림 설명>
좌:
환경광원
무한원(無限遠, 무한히 먼 곳)에 존재
중:
구(球)에 투영
우:
전개(展開)


그러한 고도의 IBL을 온전히 구현하려면 , 우선, 그 씬의 각 정점으로부터 전방위를 둘러 보았을 때의 차폐정보와 법선벡터 정보(실제로는 코사인값. 뒤에서 서술)를 텍스처에 기록해 둔다. 이것이 「사전 계산」부분이다.

그리고 렌더링시에는, 각 픽셀내지는 각 정점에서, 사전 계산으로 작성한 그 텍스처로부터 광전달 함수를 복원해, 그 때의 시선 방향(시선 벡터)을 고려해서, 큐브 환경맵 광원을 참조해 라이팅을 실시한다. 이것이 IBL기반
 PRT의 기본적인 흐름이다.

사전 계산 부분에서, 「전방위의 차폐 구조를 조사」하는데, 전방위라고는 해도, 실제로는 텍스처 리소스는 유한하기 때문에 8방향, 또는 16방향이라든지 적당한 수의 방향으로의 조사를 된다. 또,  그 차폐 구조 조사는 ray tracing적인 기법으로 행해진다(GPU 가속을 사용한 방법도 있음).

「코사인값」이란, 그 적당한 전방위 방향벡터들과 법선벡터와 내적한 값. 예를 들면 32방향에 대해 차폐 구조를 조사해 그것을 큐브맵에 기록한다면, 그 32방향에 대한 코사인값도 함께 계산해 큐브맵에 저장한다.

이 차폐와 코사인의 2개의 큐브맵을 곱한 것을 IBL적분항이라 부르고, 실제로는 이것을 사전에 계산해서 보관해 둔다.  4만개 정점의 씬이라면, 이 IBL적분항도 4만개 만들지 않으면 안되는 것으로, 이것을 리얼타임에 계산하는 것은 우선 무리라는 것은 상상할 수 있을 것이다. 게다가, 4만개의 큐브맵을 관리한다는 것도, 비디오메모리 용량의 관점에서 보면 비현실적이라고 하지 않을 수 없다.(계속)


IBL베이스의 PRT 개념. 씬을 구 모양의 정경이 둘러싸고 있다라는 이미지. 녹색 화살표는 그 정점의 법선, 오렌지색들은 전방위를 모식적으로 나타낸 것.

그 구 형태의 정경을 큐브 환경맵(6면체의 환경맵)으로서 근사 한다

그 씬의 모든 정점에 대한, 전방위로의 차폐구조(왼쪽)와 법선벡터 정보(코사인값, 오른쪽)를 텍스처에 기록. 이것도 역시 큐브 환경맵으로서 기록

실제로는 차폐 구조와 법선벡터 정보(코사인값)를 하나로 모아 IBL적분항으로서 관리. 논리상, 예를 들면 4만 정점의 씬에서는 이 IBL적분항의 텍스처가 4만개 필요하게 된다. 이것은 비현실적.



 

정적 PRT를 실시간으로 구현하기 위한 타협과 고안

이것을 실시간으로 구현하기 위해서는, 몇개의 타협과 간략화가 필요하게 된다. 1번째의 타협점은,「씬 상태의 고정화」다. 즉, 씬에 등장하는 오브젝트가 전혀 움직이지 않는다라는것. 이것은 「정적」PRT의 「정적」을 붙힌 이유이기도 하다.

PRT에서는, 모든 정점으로부터 전방향으로의 차폐 정보를 사전에 계산해서 취득, 보관했다가 활용한다는 방침을 기본으로 취했다. 따라서, 씬에 등장하는 오브젝트가 움직이면 차폐구조를 다시 한번 계산하지 않으면 안되기 때문에, 실시간에는 씬을 고정화 할 수 밖에 없다

2번째의 타협점은 조명계산(음영 처리)을 정점 단위로 하는 간략화다. 음영 처리를 픽셀 단위로 하는 것이 고품위 영상을 얻을 수 있는 것은 당연하지만, 이것을 정점 단위로 삭감함으로써 처리시간을 벌 수 있다. 실제의 처리계에서는 세정점의 계산 결과로부터, 그 폴리곤을 구성하는 픽셀 컬러를 선형보간해서 구하는 Gouraud Shading적인 접근방법을 취한다.

단, 정점 단위의 라이팅에서 주의하지 않으면 안 되는 것은, 렌더링 대상 3D모델의 정점수(폴리곤수)이다.

비록 아무것도 없는 평면의 지면이라도, 여기에 제3자의 그림자나 그 외의 복잡한 음영이 투사될 것이라고 상정하기 때문에, 1개의 폴리곤이 아니라 다수의 폴리곤으로 분할해 표현할 필요가 있다. 그렇지 않고 대강의 폴리곤 개수라면 음영의 결과가 반영되지 않고 부자연스럽게 되어 버린다.

퍼포먼스를 벌기 위해서 음영 연산을 정점 단위로 실시한다

비록 아무것도 없는 평탄한 마루일지라도, 그곳이 차폐되어서 그림자가 지는 경우, 그 부근의 정점들이 그림자색이 되는 것을 생각할 수 있다. 이것을 상정해, 어느 정도의 폴리곤수로 분할할 필요가 있다

다수의 폴리곤으로 분할하면 할수록 정점 단위의 음영 처리의 결과는 고퀄리티가 되지만, 그 만큼, 지오메트리 부하는 증가한다

3번째는, 모든 정점에 대해서 사전에 계산한 방대한 용량의 데이터를 압축하자는 방책이다.

예를 들면, 4만 정점의 씬으로, 큐브맵화한 IBL적분항이 32×32 텍셀의 작은 큐브맵이었다 해도, 1 정점 당32×32×6면×4바이트(αRGB각 8비트 칼라) = 24kB. 이것이 4만 정점 만큼 있으면 총 938MB의 비디오메모리가 차폐 정보의 저장만으로 사용되어져 버린다.

이것을 압축하는 기술로서 이용되는 것이, 요즘 3D그래픽스의 세계에서 볼 기회가 많아진「구면 조화 함수」(SH : Spherical Harmonics)이다. 이 구면조화함수는「양자 역학」 교과서에나 실려 있을 것 같은 것으로, 그러한 특수 수학을 3D그래픽스의 세계에 응용했다는 점이 PRT의 독특하고 획기적인 점이라 할 수 있다.

그런데, 모든 정점의 차폐 구조를 사전에 계산하고 있다고 해도, 실제로, IBL적분항으로부터 각 정점에 대해서 전방향의 음영 연산을 하는 건 처리가 무겁다. 그러나, 이 구면조화 함수를 사용하면 마침 그 문제도 해결 가능하게 된다.(계속)



 

구면조화(Spherical Hamonics) 함수란 무엇인가?

「구면조화 함수」는 말부터 어렵게 들리므로, 우선은 이미지로부터 파악해 보자.

구면조화 함수란, 극단적으로 간략하게 설명하면, 구(球) 같은 물체로부터 임의의 길이의 가시들이 뚫고 나와있는 「타원형의 찌그러진 성게」같은 물체의 형태를 수학적인 함수로 나타내기 위한 것……이라고 할 수 있다(성게의 가시들이 반대로  오목하게 패여 있는 경우도 있다).

이것이 어째서 큐브맵의 압축에 사용할 수 있는지 이미지가 쉽게 떠오르지 않을 지도 모르겠다.

차례차례 설명해 나가자.

모든 방향의 정경을 나타낸 큐브 환경맵을 구(球)로 보고 그 큐브 환경맵의 텍셀(화소)의 값을 "높이" 로 본다. 그러면 「찌그러진 성게」같은 입체가 완성된다. 그리고, 이 찌그러진 성게를 정확하게 기록하는 것은 포기하고, 「대략적인 형태」만을 기록하기로 한다. 그 수단으로서 구면조화 함수를 이용하는 것이다.

앞에서, 32×32 텍셀의 6면체의 큐브 환경맵을 예로 들었는데, 비압축 시에는 하나의 정점 당 24kB의 데이터량이 필요했다. 저장하는 구면조화 함수의 계수들의 개수에 따라 데이터량이 변하지만, 실용 레벨로는 16개 정도의 계수로도 충분하다고 한다. 만일, 16개의 32비트 부동소수점이면 불과 64바이트. (즉) 24kB의 1/400로 작아진다. 방금전의 4만 정점의 예라면, 2.4MB로 끝나므로, 938MB와 비교하면 상당히 현실적인 데이터량으로 압축할 수 있음을 알 수 있다.

구면조화함수는 「찌그러진 성게」형태의 근사적인 표현방법으로 사용된다.

<그림 설명>
(제목) 구면조화함수의 요점
상:
(박스) 구면조화함수를 사용한 근사 ≒ 본래의 휘도 분포  <-  각방향의 휘도를 높이로 변환
<- 구에 투영
구면조화 함수는, 대강의 특징을 극도의 효율로 근사할 수 있다
하:
(박스 좌) 데이터량
16개~36개의 float: 64byte(16개의 경우)
(박스 우) 데이터량
큐브맵의 데이터량: float * (32*32*6) 필셀: 24,576byte
데이터량을 1/400로 압축!!

구면조화함수는, 어떤 형상을 표현하기 위해 복수의 함수군들로 구성된다. 그 함수의 수가 많을 수록 형상 표현이 정확하게 된다. 자세한 수학적인 정의는 여기서는 생략 하지만, 아래 그림은, 어떤 파라미터가 주어진 구면조화함수를 나타내고 있다. 그림에서 위에서 부터 1차(first order, 또는 1레벨) 까지 구면조화함수를 사용하면 1개, 2차(secode order)까지 사용한다면 합계 4개, 3차까지는 합계 9개, 4차까지는 합계 16개……라는 상태로 함수의 개수가 증가한다.

l = 0,1,2,3…, m = -l ~ +l에서의 구면조화함수의 수식(上)과 3차원으로 가시화한
그림(下). 만일, 예를 들어 l=3의 4 레벨까지 사용한다고 하면 총16개의 구면조화함수를 사용하게 된다


그림을 한번 더 보고 싶다.

l 값이 작을 수록 형상이 단순하고, 반대로 l 값이 커지면(아래에 가면 갈수록) 뾰족뾰족한 형상이 복잡하게 되어 지는 것을 알 수 있다. 방금「찌그러진 성게」의 형상을 근사하는 것에, 많은 구면조화함수를 사용하면 고품질로 근사 할 수 있다고 말했다. 이것은 결국, 이 그림의 아래쪽의 복잡한 형상들을 사용하면 할수록, 그「찌그러진 성게」를 보다 정확하게 표현할 수 있다는 것이다.

표현하고 싶은 「찌그러진 성게」는, 큐브 환경맵이고, 그 값은 큐브 환경맵 마다 고유하다. 그 말은, 각각 그 가시의 길이나 그 구처럼 생긴 형태의 크기가 다 다르다는 것이다. 어느 가시가 길면 그 가시가 길어지도록 구면조화함수의 크기를 바꾸어 줄 필요가 있다.「찌그러진 성게」형상의 근사에는, 복수의 구면조화함수에 대해서 가장 적당한 스케일링 계수(크기를 결정 짓는 에누리)를 줄 필요가 있다. 이 계수를 구하는 계산은 여기서는 생략 하지만, 간단하게 말해 어떤 정해진 방정식을 풀어서 구할 수 있다.

예를 들면, l = 3까지의 16개의 구면조화함수를 이용해 근사 할 때는 16개의 스케일링 계수를 구할 필요가 있다.

「찌그러진 성게」형상의 근사에는, 사용한 구면조화함수 1개마다 가장 적합한  스케일링 계수를 도출해 조합해 줄 필요가 있다

<그림 설명>
(제목) 구면 조화 함수에 의한 근사
좌:
(박스) 대략적인 특징을 근사 가능
(박스) 근사한 결과
우:
(박스 좌) 압축하고 싶은 정보 S
(박스 우) 최적의 계수 계산식
(박스 중) 구면조화함수 -> 스케일링 계수
(박스 우) 1:1 대응
(박스 우) 최적의 계수를 수치적으로 계산 가능
(박스 하) 구면조화함수

스케일링 계수를 도출하면, 이것만으로 근사를 한 「찌그러진 성게」의 형상을 복원할 수 있다. 덧붙여 경험적으로, 실시간 3D그래픽스에서의 PRT용의 경우,  대개 16개(l=3)~36개(l=5)의 구면조화함수면 충분한 것으로 알려져 있다.

<그림 설명>
(제목) 구면조화 함수의 요약
근사한 정보 = 구면조화함수  ≒ 근사전의 원래 정보
계수벡터를 보존하면, 큐브맵을 보존하는 것과 같다
각 정보 사이에서 변화하는 것은 계수 뿐 -> 계수만 정보단위로 보존
계수 벡터라고 호칭
0.0 - 검은색, 1.0 - 흰색의 그레이스케일로 가시화


구면조화함수 그 자체는 이미 존재하는 것이며, 산술적으로 산출할 수 있다. 그렇다면, 어떤 「찌그러진 성게」형상을 기록&재현하려고 했을 때(근사되어 버리지만), 그 구한 계수만을 기록해 두면 복원이 가능하게 된다.

예를 들면 앞의 한개 정점 당 24kB의 데이터량이 필요했던 그 형상 데이터를, 16개의 구면조화함수로 표현한다면, 불과 16개의 계수를 보존해 두면 복원 할 수 있다. 구면조화함수로 1/400로 압축할 수 있는 트릭이 여기에 있다.

보다 감각적인 예를 든다면, 구면조화함수란, MPEG나 JPEG의 압축에 이용되는 이산 코사인 변환의 「구체(球體) 버젼」이라고 할 수 있을지도 모른다.(계속)




 

렌더링 시의 음영 처리는?

여기까지를 근거로 정적 PRT의 흐름과 개념을 정리한 것이 아래 그림이다.

정적 PRT(Static PRT)의 개념도.「구면조화함수」는 데이터 압축 메서드로 활용된다

< 그림 설명>
(제목) Static PRT의 개념도
상:
사전 계산
차폐계수 벡터
차폐정보를 취득 -> 데이터 압축 -> 휘도계산
하:
실행시
구면조화함수
광원정보 입력 -> 데이터 압축 -> 휘도계산
광원계수 벡터


차폐구조의 구면조화함수는 흑백이므로 1채널 분량만 다루면 되지만, 주변 정경의 큐브 환경맵의 압축은 RGB 3채널 분량을 같은 형태의 구면조화함수로 압축해야 한다.

그런데, 이 정적 PRT에서는 각 정점 단위로 음영계산(휘도계산, 조명연산)을 한다고 앞에서 말했다.

그러나, 각 정점에서 차폐구조 큐브맵도, 광원으로 취급하는 전체 정경을 그린 큐브 환경맵도, 모두 구면조화 함수의 계수가 되기 때문에, 그 음영계산 방식이 쉽게 이해되지 않는다. 실은, 이 계산은, 이 구면조화함수의 스케일링 계수열들을 벡터로 가져와서 내적 계산하는 것이다.

수학적인 증명은 여기에서는 생략 하지만, 이번회의 예로 보면, 차폐구조압축에서 구한 구면조화 함수의 스케일링 계수열로 된 「차폐계수벡터」와, 광원용 큐브 환경맵 압축에서 구한 구면조화함수의 스케일링 계수들로 된「광원계수벡터」의 내적을 구하면 음영계산을 한 것이 된다.

구면조화함수를 이용해 정보를 압축할 수 있었을 뿐만 아니라, 부차적으로 음영 계산의 간략화도 동시에 가능한 것이다.(계속)

차폐구조 압축에서 구해진 구면조화 함수의 스케일링 계수열로 된 「차폐계수벡터」와, 광원용 큐브 환경맵 압축에서 구해진 구면조화 함수의 스케일링 계수로 된 「광원계수벡터」의 내적을 구하면 음영연산(휘도 계산)을 해 준 것이 된다

<그림 설명>
제목: 휘도계산
계산정점,
Double Product(내적)


Posted by 노을삼킨별
,