최상단 광고

2012년 6월 4일 월요일

표준 rand()함수보다 유용한 랜덤 생성 알고리즘 ? MT, WELL [출처] 표준 rand()함수보다 유용한 랜덤 생성 알고리즘 ? MT, WELL


이 글은 게임 개발 포에버에 같이 연재된 글입니다. 
안녕하세요. 알콜코더 민군입니다.

현재 제작 중인 게임에서, 랜덤 시드 값을 일치 시켜서, 랜덤 결과를 서로 다른 클라이언트끼리 동기화 시키는 작업을 진행 하였습니다. 랜덤 시드값만 서로 일치시키면, 이후에 생성되는 랜덤 함수의 결과값들은 모두 일치가 되기 때문에, 예전에 스타크래프트와 같은 패키지 게임에서 자주 사용했던 테크닉입니다. ^^; 
서로 다른 클라이언트끼리 처음 시드값만 일치 시키면, 이후의 랜덤값은 정해져 있기 때문에, 그 랜덤값을 사용한 이벤트등의 동기화에 사용하는 것이죠.

이런 테크닉은 패키지 게임 시절에는 리플레이 저장이나 네트워크 동기화등에서 상당히 많이 사용하였습니다. 하지만 온라인 게임으로 넘어오면서, 대부분 서버에서 랜덤값을 직접 생성하여 넘겨주기 때문에, 이 테크닉 쓸일이 거의 없었는데… 이번 상황은 랜덤값이 게임의 결과에 전혀 영향을 끼치 않고, 단지 연출에만 영향을 끼치기 때문에 이 테크닉을 사용하기로 하였습니다. 
(서버 부담을 줄여달라는 서버쪽의 간절한 요청 때문에.. 아흑..OTL)

일반적으로 랜덤 함수라면 C++ 표준 rand() 함수를 사용하게 됩니다. 뭐.. 일반적인 랜덤값을 사용하는 경우에는 사실 이 표준 함수를 사용해도, 별 문제는 없습니다. ^^; 하지만 위와 같은 테크닉을 사용할 때는 rand() 함수를 사용하면 안됩니다!
왜냐하면, C++의 표준 rand() 함수는 아래와 같은 약간의 문제점을 가지고 있습니다.
  1. rand() 함수의 분포는 그리 고르지 않다. 특히 작은 표본을 사용할때는 더욱 그렇다. 즉, 이말은 1~10까지 랜덤을 1억번쯤 돌리면, 확률이 다들 비슷하게 나오긴 하지만, 10번 정도만 돌릴때에는 1 하나만 10번이 나온다거나 하는 가능성이 있다는 것입니다.

  2. rand() 함수는 전역 함수이다. 어디서든 사용이 가능하다이 함수는 표준 함수이기 때문에, 코드의 어디에서도 호출이 가능합니다. 그래서 호출 되는 경우를 제어할 수 가 없습니다.

< 즉 이런 기적의 확률이 나올수도 있는거임.. ㅠ.ㅠ >

저의 경우에 문제가 되는 것은 1번이 아니라, 2번입니다. 같은 랜덤 시드값으로 서로 다른 클라이언트에서, 싱크를 맞추기 위해서는 랜덤 호출 횟수가 정확히(!) 일치하여야 합니다! 내가 랜덤함수를 5번 호출했으면, 상대방도 5번 호출해야 같은 결과 값이 나와서 싱크가 일치하게 됩니다.
그런데 만약? 내가 작성한 코드가 아니라 어딘가 다른 코드에서 그것도 한쪽 클라이언트에서만 그 사이에 rand()를 호출하게 되면 어떻게 될까요? 넵. 당연히 그 다음부터는 모든 싱크가 아작이 나게됩니다…
(그리고 이 경우에는 어디서부터 문제가 발생 했는지 찾는 것도 거의 불가능)
전역 함수라는 특징 때문에, 어디서 어떻게 불리울지 모르기 때문에, 언제 호출 횟수가 어긋날지 모른다는 문제가 발생하기 때문에, 랜덤 시드로 씽크를 맞추는 이 테크닉에서는 rand() 함수를 사용하는 것은 불가능 합니다. 
(내 코드에서는 절대 그럴리가 없어! 라고 해도… 다른 사람이 작성한 코드에서 과연 부르지 않는다는 보장이 있을까요…)

그래서 따로 랜덤 생성 클래스를 만들어 사용하게 됩니다. 랜덤 클래스를 만들고 그 인스턴스만을 사용하게 되면, 호출 횟수가 어긋나는 문제를 해결할 수 있으니까요. ^^
저의 경우가 바로 이런 경우라서, 랜덤 생성 알고리즘을 한번 찾아 봤습니다. 랜덤 생성 알고리즘은 "난수 생성기(Random Number Generator)", 혹은 "의사 난수 생성기" 등으로 불리웁니다. 
(그냥 저는 편의를 위해.. 이후 '랜덤 생성기'라고 칭하겠습니다. 이게 걍 편해요…)

이렇게 따로 랜덤 생성기를 이용해서, 랜덤 생성 클래스를 만들어 사용하면, 위와 같이 코드의 다른곳에서 랜덤값이 불리우는 경우를 제어할 수 있습니다. 물론 그렇다고 랜덤 생성 알고리즘을 혼자 고급 수학책이나 물리책 펴놓고 만들어서 쓰라는 이야기는 아닙니다. 친절하게도 이런 알고리즘은 전문 수학자 분들이 편하게 갖다 쓸수 있도록 편하고도 멋지게 만들어 두었습니다.
 (아이구~ 이런 감사할때가….)

이런 랜덤 생성기중에서 가장 유명하고 널리 쓰이는 알고리즘이 바로 
[메르센 트위스터(MT.Mersenne Twister)][WELL]이라는 랜덤 생성기입니다.
그리고 이 랜덤 생성기들은 위와 같은 테크닉에 사용할 수 있는 용도 외에도 다음과 같은 뛰어난 장점들을 가지고 있습니다
  1. 표준 함수보다 랜덤 분포가 훨씬 고르다
    표준 함수의 경우 2^32승의 period를 가지는데 반해, MT의 경우는 2^19937-1를 가집니다. 그리고 623차원까지 동일분포 되어 있습니다. (자세한건 아래 링크 참조)

  2. 표준 함수보다 훨씬 속도가 빠르다.
    MT의 경우에 비트 연산만으로 구현되어 있어서, 표준 rand()보다 약 4배가 빠르다고 합니다. 그리고 WELL 같은 경우에는 MT보다 40%가 더 빠르다고 합니다.



메르센 트위스터

위키백과우리 모두의 백과사전.
메르센 트위스터(Mersenne Twister) 1997년에 마츠모토 마코토(松本 ) 니시무라 다쿠지(西村 拓士) 개발한 유사난수 생성기이다.[1] 메르센 트위스터는 동일한 저자들이 개발한 TT800 생성기의 개선판으로기존 생성기들의 문제점들을 피하면서 매우 질이 좋은 난수를빠르게 생성할  있도록 설계되었다.
메르센 트위스터의 이름은 난수의 반복 주기가 메르센 소수 데에서 유래했다메르센 트위스터는  속도와 난수의 품질 때문에 점점 많은 곳에서 채택되고 있으며흔히 주기가 219937 − 1 MT19937 사용한다. MT19937 같으나 생성해 내는 난수가 32비트가 아닌 64비트인MT19937-64 쓰이며2006년에 동일한 저자들이 발표한 SIMD 기반 메르센 트위스터는MT19937 비해 대략   정도 빠른 것으로 알려져 있다.
난수의 품질에도 불구하고메르센 트위스터는 암호학적으로 안전한 유사난수 생성기 아니다 난수의 특성(주기난수 범위) 알고 있을  유한한 수의 난수( 경우 624)만으로 현재 생성기의 상태를 알아   있으며 뒤에 나올 난수를 예측해   있다암호학적으로안전한 유사난수 생성기를 얻기 위해서는 해시 함수 사용해야 하지만 난수의 생성 속도가 낮아진다또는 블룸 블룸 (BBS) 같이 암호학적으로 안전하게 설계된 생성기를  수도 있다.


메르센 트위스터는 현재도 가장 널리 사용되고 있는 랜덤 생성기입니다. C++에서는 Boost에도 
이 MT 랜덤 생성기가 구현 되어 있습니다. 또한 MATLAB, Ruby, Python등의 언어에서도 기본 난수 알고리즘으로 채택되어서 사용 되고 있습니다. 뭐 물론 단점이 없는 건 아니지만, 장점이 훨씬 더 크기 때문에 표준으로 채택이 되었겠죠. ^^
그리고 가장 큰 장점은 특별히 따로 구현하지 않아도, Boost에 포함되어 있기 때문에, Boost만 
있다면 바로 사용이 가능하다는 장점이 있습니다. 사용 방법에 관해서는 하단의 참조 링크에서
 확인하실 수 있습니다.

WELL
WELL은 위 MT의 디자이너가 10년후에 고안한 난수 발생 알고리즘 입니다. 그의 주장에 따르면 
MT보다 40% 빠르고 코드도 더 간단합니다. WELL은 분포도에 따라서 WELL512, WELL1024,
 WELL19947, WELL44497의 종류가 있습니다. 숫자가 클수록 분포도가 높긴 하지만, 게임에서
 사용하기엔 512나 1024만으로도 충분할 것 같습니다.
WELL의 구현 코드는 이곳에서 받을 수 있습니다. 실제로 보면 정말 구현은 간단합니다.
아래가 WELL512의 구현 코드입니다.
이게 다입니다. Period는 이름 그대로 2^512입니다. 그렇다 해도 일반 PC로 저걸 세는데 
10^100년이 걸린다고 하는군요. 초나 분이 아니라 년 말입니다. (googol years라고 부른다고 하는군요)
사용법은 위의 state만 적절히 초기화 해주고, 함수를 호출하면 32비트 정수(난수)가 리턴됩니다.

간단한 시물레이터로 두 난수 발생기를 시뮬레이팅 해 보았을 때의 차이를 보여드리겠습니다.

C/C++의 rand함수

WELL512 알고리즘


일반적으로 게임 개발할때는 이런 랜덤 생성기까지 필요 하지 않을지도 모릅니다. 그러나 MMORPG와  같이 랜덤이 게임의 밸런스에 큰 영향을 끼치는 경우에는, 서버 측에서 이런 고성능의 랜덤 생성기가 필요한 경우가 많습니다. 유저나 해커가 랜덤값을 함부로 예측해서는 안되니까요. ^^; 그리고 저의 경우 처럼 랜덤 시드를 이용해서 이벤트 동기화를 맞추는 경우에는 전역 함수인 rand()를 사용할 수 없기 때문에 꼭 이런 랜덤 함수가 별도로 필요합니다. 그런 경우에 굳이 이런 좋은 난수 알고리즘들을 놔두고 새로 짜는 고생은 안하는게 낫겠죠.
(그렇다고 내가 만든 알고리즘이 저것보다 좋을리는 택도 없을 테니…=ㅅ=;)

위대한 게임의 탄생 - 좋은 게임을 넘어 위대한 게임으로 [출처] [본문스크랩] 위대한 게임의 탄생 - 좋은 게임을 넘어 위대한 게임으로




UnCharted 2, WOW, HALF-LIFE2, 마영전, 스포2등 국내외 내노라하는 게임들의 포스트 모템을 모아 놓은 책이다..

단순히 잘된 점만을 기술한 것이 아닌, 잘된 점, 잘못된 점들을 모두 드러냄으로써

같은 업종에 종사하는 사람들에게 교훈을 주고 스스로도 실수를 반복하지 않게 하도록 해 준다는 점에서

이 책은 충분히 읽을 가치가 있다.

성공했던 게임들의 사례들을 하나 하나 들어가면서 중간에는 다시 한번 게임들의 잘 된점과

잘못된 점들을 분석하는 부분을 넣은 것은 중간에 상기하지 못했던 부분을 다시 떠오르게 하고

정리를 해주고 배운것을 어떻게 적용할 것인가에 대한 부분도 실어 넣음으로써 쉽게 머리속에 남을 수 있게 하는 배려도 보였다.

또한, 마지막에도 직접 이 책을 내면서 있었던 부분을 포스트 모템으로 만들면서 직접 실천으로 보여주는 형태도 

보여주어 더욱 좋았던 책이었던 것 같다.. ( 마지막에 잘못된 점에 LOL을 했다 보고 빵 터짐...)

WOW 같은 경우엔 예상 인원이 넘쳐나서 1년 치 예비 서버를 다 써버렸다는 등.. 자랑도 했지만(뭐 충분히 자랑할 만 하지..)

성공의 공식은 없다..

하지만 이 책에 나왔던 게임들은 하나 같이 잘했던 점을 최대한 다시 살리고 자기 반성을 할 줄 알며

잘못 된 점들은 내치고, 게임 개발은 혼자 하는 것이 아닌 조직의 구성원과 함께 만들어 가는 것이고

같이 개발하는 사람들에 대한 관심과 이해가 필수적으로 요구 되고 그 사람들의 의견을 존중해주며 나아갔다는 것이다..

이딴 마인드 따위....

하나하나가 주옥같은 말들이지만 그 중 와닿았던 부분 일부를 발췌한다 (빨강은 게임 이름, 파랑은 각 직군 인터뷰)
-----------------------------------------------------------------------------------------------------

LBP : 중요한 것은 여러가지를 시도하고, 직관적으로 생각하고, 창의적이 되고, 
우리 팀 사람들과 회사에는 어떤 방법이 맞을지를 찾는데 있습니다. 
창조적 프로세스를 향해 처음부터 달려들지 마세요.
씨앗이 잡초인지 아닌지 알려면 자라는데 시간이 필요합니다

WOW : 우리는 믿기 어려울 정도로 테스트를 많이 했습니다, 또한 데이터 분석 툴이 필요하다는걸
좀더 빨리 알았어야 할 필요가 있었습니다..

DINER DASH : 개발자가 하고 싶은 게임을 만든 것은 잘된점 이면서 잘못된 점이기도 합니다.
그런것으로 인해 게임의 난이도가 너무 빨리 높아지는 실수를 하였지만, 만들고 있는 게임이
자기한테 별로 재미가 없다면 뭐하러 만드냐는 마음으로 하여서 늘 즐거움과 열정이 가득햇습니다

HALF - LIFE 2 : 일정이 길 때 생길 수 잇는 부작용 하나는 게임에서 기능을 잘라내기가 더 어려워진다는 점입니다
어떤 기능을 누군가가 좋아하게 되면 이 기능 없이는 게임이 성공하지 못할거라고 믿게 되죠
기능 제거는 게임의 품질을 높일 수 있는 최선의 방법중 하나이기 때문에 이러한 사태는 위험할 수 있습니다
핵심 기능 외에는 전부 잘라내는 것이 게임의 품질을 극대화하는 최고의 방법입니다

UNCHARTED2 : 스토리는 장애물이 아닙니다. 그 반대에요. 스토리안에서 개발하다 보면 게임플레이도 근사하게 만들 수있습니다.
게임 플레이에 필요한게 있다면 이를 스토리가 쓰인 세계관 안으로 포함시켜 보려고 해보세요.
스토리의 현실성에 기반을 두려고 하다 보면 스토리와 게임 플레이, 이 둘의 결합에 더 신경쓰게 되고
게임에도 전반적인 영향을 미칠것입니다

ROCK BAND : 사람들이 서로를 믿고 기회를 주는 문화를 만들어왔으며 앞으로도 만들어 가려고 합니다
사실 이부분은 많이 어렵습니다. 사람들이 서로를 신뢰하여 위험을 무릅 쓸수 있고 뒤통수 맞지 않을 거라는 확신이 서야만 
이런 문화가 가능하죠. 또한 게임에 대한 열정도 저희 게임의 한몫 했던 부분입니다

FARM VILLE : 소셜게임에서는 개발속도가 굉장히 중요합니다
6개월 이후에 활 기획을 미리 생각하지 마세요 지금 유저들이 원하는 것을 찾아내서 빠르게 만들어 주세요
지금 하고 있는 일이 게임 런칭 준비에 도움이 안되거나 런칭 이후 업데이트에 필요하지 않다면 시간낭비 하고 있는 겁니다

BEJEWELED TWIST  : 피처 크립 현상이 심했습니다
시간이 지남에 따라 특수 기능 수도 계속 늘어났고 RPG같은 복잡한 매커니즘도 나왔지요
결국 감당 할 수있는 기능 외에 다 처내버렸지만 이 부분을 바로 잡느라 프로젝트 기간의 반을 까먹어야 했습니다

MADDEN NFL 10 : 팬 커뮤니티에 뛰어 들었다. 게시판으로 유저들과 소통하고 트위터를 팔로잉 하는 식으로 어떻게든 팬에게
접근의 팬들의 소리를 듣고 팬들의 피드백을 따라 게임을 변경했다
"변경한 내용이 게임에 어떻게 영향을 미치는지를 보여주는 동영상을 올리고 이에 대한 팬들의 반응을 모아 
게임을 최종적으로 튜닝 하기였습니다. 멋진 의견이 오갔고 게임의 품질과 현실감을 훨씬 좋게 만들 수 있었습니다"

WORLD OF GOO : 지금까지 Kyle에게 배운 가장 중요한 점은 게임 디자인은 완벽한 게임 매커니즘을 만드는것
이상으로 체험을 만드는 것이라는 점입니다



Spore : 수석게임 디자이너 (Chris Trottier ) : 

훌륭한 게임을 만드는 것은 개인의 끝내주는 아이디어나 솔루션보다는 
매우 똑똑한 사람들과 잘 협력하는데 있다는 것입니다.

Blue Casle Games 개발 디렉터 (Robyn Wallace )  :  

어려운 것을 먼저 하세요 
압박을 받다보면 양은 많고 쉬우면서 근사해보이는 일부터 먼저하고 싶은 유혹을 받게 됩니다
이렇게 하면 백발백중 문제가 터집니다.
빨리 시도를 해야 안되면 다르게라도 할 수 있는 것이지 방향이 정해진 후에는 바꾸기 훨씬 어렵습니다

Gobit Games 프로듀서 ( Don Walters ) :  

좋은 게임을 만들고 싶다면 괜찮다고 생각하는 아이디어에서부터 시작해보세요
그리고 프로토 타입이 별로라면 어떻게든 좋게 만들려고 하는 것보다 아이디어를 포기하는 것이 더 좋을 수도 있습니다
무엇보다 좋은 게임을 만들때 중요한 점은 개발팀 간에 의사 소통이 잘 되고, 잘 조직 되고
모든 팀원이 각자 필요할때 원하는 정보, 에셋, 툴을 얻을 수 있게 하는 거라고 생각합니다

Red Storm/UbiSoft 게임작가 ( Richard Dansky ) :  

최고의 게임은 스토리,캐릭터, 대사 등으로 불리는 각본이
게임의 일부라는 점을 이해하고 그에 맞게 대해주는 게임입니다.

MS 343 Industries 선임배경아티스트 ( Wade Mulhern ) : 

훌륭한 게임을 만드는 것에 배경아티스트들에게 말 할 수 있는 것은 팀워크가 전부라고 생각합니다. 
저는 12명의 배경아티스트중 한사람이자 God Of War 3를 만든 120명중 한사람일 뿐입니다
개인적으로 게임이 훌륭해지도록 할 수 있는 일은 God Of War3의 기준에 맞도록 레벨을 만드는 것 뿐입니다
진부하게 들리겠지만 이게 사실입니다 한사람이라도 망치면 많은 부분은 엉망이 됩니다


프리랜서 음악 작곡가 Peter McConnell : 
여러분이 정말로 정말로 잘하는 부분에 집중하세요, 어떤것은 정말로 잘하지 못한다면
그것을 잘 할수 있는 사람과 함께 일하는 것이 정답입니다


Certain Affinity 수석 프로그래머 ( Stefan Sinclair ) : 
훌륭한 게임을 만들기 위해서 팀원들에게 요구하는 만큼 자신도 기꺼이 해내고 이를 모범으로 보여줘야 합니다
의사소통이 끊어지지 않도록 노력하세요
의사소통이 줄거나 끊기는것은 건강과 프로젝트 성공에 해롭습니다 미뤄봐야 나중에 더 큰 문제로 돌아올 뿐입니다
이런 문제는 초반에 과감하게 해결해야 더 좋은 결과를 얻을 수 있습니다

Skate 3 프리젠테이션 아트 디렉터 (Clint Jorgenson ) :

지금까지 제가 작업해온 최고의 게임들에는 하나의 공통점이 있습니다
그것은 개발자들이 자신이 플레이하고 싶어하는 게임을 열심히 만들었다는 점입니다

Simlish 성우 ( Stephen kearin ) : 

훌륭함은 최고의 것을 만들기 위해 꾸준히 노력하다 보면 저절로 찾아옵니다

Nexon America 아트 디렉터 (Rich Curren ) : 

관습에 도전해야 합니다
관습적인 부분을 찾아내 고치려고 노력하다보면 적절하면서도 훨씬 재미있고 매력적인 게임을 만들 수 있습니다
또한 게이머들은 새로운 스타일을 잘 받아들인다고 생각해요
늘 새로운 스타일에 목매고 있는 게이머들에게 요즘 나오는 게임은 그렇지 않습니다
요즘 나오는 게임은 실사같은 그래픽 스타일을 추구한다고 하지만
그런 게임을 실제로 해보면 그래픽이 실사 같을 뿐이지 전혀 스타일이라고는 찾아 볼 수 없습니다

Certain Affinity 외부 프로듀서 ( Tim Fields ) :

아무도 쓰레기 같은 게임을 하고 싶어 하지 않습니다
예산이나 출시 시기같은 시장의 현실은 게임을 명작에서 멀어지게 만들지요
개발팀이 원한다고 해서 훌륭하게 만들 수 있는 것도 아닙니다
게임 개발의 필요한 개발팀의 능력과 시장상황, 예산이 하나가 될때에만 게임을 명작으로 만들수 있습니다
이 것들이 전부 맞아 떨어질때 이 책에 나온 멋진 게임들같이 10년 이상 기억될 게임을 만들 수 있습니다


아래는 기타 와 닿았던 내용들...

비전을 믿고 열정이 가득찬 스탭들이 많았다. 개발팀의 가장 큰 재산은 바로 이 멤버들이다 - 마영전
고객들의 입장에서 사고하기 위해서는 창의력의 근간인 " 관점 전환 능력"이 필요하며 관점 전환을 자유롭게
하기 위해서는 사람에 대한 관심과 이해가 필수적으로 요구된다 - 스페셜포스2

잘 된 점은 앞으로 우리가 훌륭한 게임을 만드는데 쓰일 도구이자 비법이 될 것이며
잘못 된 점은 열린대화를 끊임없이 함으로써 정면 대응 할 수 있다는 사실도 알려준다 - 잘된점과 잘못된 점 정리//

유능하고 창조적인 개발팀의 특징은 솔직함과 자기 반성이다
어디에도 똑같은 게임프로젝트, 똑같은 개발팀은 없다
하지만 유능한 개발팀에서 공통적으로 보이는 특징은 몇가지 살펴볼 수 있을 것이다.. - 유능한 개발팀의 특징

니시카와젠지의 3D 게임 팬을 위한「KILLZONE 2」그래픽스 강좌 (전편) PS3의 하이퀄리티 그래픽스는 Deferred Shading으로 [출처] [본문스크랩] 니시카와젠지의 3D 게임 팬을 위한「KILLZONE 2」그래픽스 강좌 (전편) PS3의 하이퀄리티 그래픽스는 Deferred Shading으로 결정!?


2009년 4월 27일 게재된 글이지만,  살펴볼 것도 있고 해서 번역합니다..



를 참조하세요~


니시카와젠지의 3D 게임 팬을 위한「KILLZONE 2」그래픽스 강좌(전편)
PS3의 하이퀄리티 그래픽스는 Deferred Shading으로 결정!?




【필자근황?】
 삼시 세끼보다 격투게임을 더 좋아하는 테크니컬 저널리스트。
본 잡지에서는 주로 GPU나 3D 그래픽스 관련 기사를 집필하고 있다.
태어나서 처음 산 게임 하드웨어가
「판타지 존」이라는 중고 게임 기판이라고 할 정도의 게임센터 죽돌이. 게임을 뭐든 사랑하지만 그중에서도  괴상한 내용의 게임을 좋아하는 경향이 있다. 최근 맘에 들었던것은 「NINJA BLADE」(프럼 소프트웨어)。개인블로그는 여기
 
  일본에서 그다지 알려져지 않지만 유럽에서는 절대적인 인기를 누리고 있는 1인칭 슈팅게임(FPS : First Person Shooter)가「KILLZONE」시리즈다。
   개발 회사는 네덜란드 유일의 하이테크 스튜디오 Guerrilla Games。
항상 최신기술을 자사 타이틀에 넣는 모습은, 게임엔진을 직접 만드는 EPIC GAMES, CRYTEK등과도 많이 닮아 있으며 최신작(당시에는..)
「KILLZONE 2」는 매력적인 게임내용은 물론 PS3용 최신예기술의 쇼케이스이다

 「KILLZONE 2」는 유럽에서는 2월에 발매되어 높은 평가를 받았다. 일본에서도 4월23일 발매되었다. 그야말로 발매직전이라는 절호의 타이밍이라는 형태로 이번에는 저번달 샌프란시스코에서 개최했던 GDC에서의 기술 세션의 내용을 베이스로「KILLZONE 2」의 그래픽스 테크닉을 차근차근 전후편으로 나누어 소개 하고자한다。


■ 「KILLZONE 2」가 채택한 Deferred Shading 파이프라인이란?(1)
 ~ 무거운 셰이더 그래픽스 최적화 수단중의 하나

GDC에서「KILLZONE 2」에 관한 세션을 진행한 Guerrilla Games Senior Programmer Michal Valient씨
왼쪽상단이 Z 버퍼의 내용。오른쪽상단이 픽셀단위의 법선벡터. 왼쪽 하단이 텍스처 컬러. 오른쪽하단이 스펙큘러. 이러한 중간값을 미리 렌더링해서 최종적인 라이팅 설정을 나중에 수행하는것이 Deferred Shading
  일반적인 3D 게임 그래픽스는 버텍스처리-> 픽셀단위의 음영처리 라는 흐름으로 렌더링을 수행한다. 이러한 형태를 굳이 이름을 붙이자면 「전방(순방향)렌더링(Forward Rendering)」이라고 부른다。

    포워드 렌더링에서는 오브젝트마다 셰이더를 전환하거나 하는 렌더링 엔진에서는 픽셀셰이더로부터 얻은 결과가 깊이테스트에서 그려내지못하고 버려지 버리는 것도 많다.
이것은 쓸데없는 연산이라는 것도 된다。

   또 멀티 패스 렌더링에서는 몇번이고 같은 지오메트리에서 구성된 씬을 렌더링하는 케이스도 나오게된다(지오메트리 처리의 무의미한 중복).
즉, 포워드 렌더링에서는 화면에 표시하는 프레임내에 총 픽셀 수 보다도 많은 연산을 하여 그 결과를 버리거나, 반복적으로 같은 계산을 쓸데없이 수행해버리는 것이 종종 있는 것이다.

   또, 하나의 씬을 렌더링할때에 고도의 픽셀 셰이더 프로그램을 여러개 동작 시킬 경우, 각각의 픽셀셰이더 프로그램이 계산중간의 같은값을 사용하는 것이 종종 있다. 이것이 복잡한 계산이나 텍스처참조를 동반한 것일 경우, 그 중간치를 구하는 것만으로 GPU에 부하가 걸리게 되 버린다.
  
   그래서 복잡한 음영처리를 수행하는 헤비 셰이더가 많이 사용되는 3D 그래픽스의 렌더링에서는 기존의 [ 포워드 렌더링 ] 이 아닌 별도의 연구가 시작되었다. 그 결과물의 방법으로써 최근 대두가 되고 있는 것이 
Deffered Shading(디퍼드 셰이딩 : 연장 셰이딩) 이라는 방식이다

 Deferred Shading에서는 씬내의 폴리곤 베이스(지오메트리 베이스)의 렌더링을 무거운 소재표현의 픽셀 셰이더는 동작시키지 않고 미리 수행배 버리고, 복수의 픽셀 셰이더 프로그램에서 필요한 계산의 중간값을 복수의 버퍼에 미리 동시 출력해 버린다. 그 때의 유효한 것이 DirectX 9 이후에 유효하게 활용할수 있게 된 MRT (Multi - Render Taget) 이다.
한번 렌더링 패스에서 복수의 버퍼로 다른 값을 동시출력하는 기능이며, DirectX 9에서는 4장, DirectX 10에서는 8장의 동시출력이 가능하다

   MRT를 사용해서 복수의 버퍼(텍스처)에 대해서 출력할 내용은, 렌더링 엔진마다 다르지만 심도값(Z 값), 폴리곤을 구성하는 픽셀단위의 법선벡터 정보, 스펙큘러 값, 조도(텍스처를 적용한 결과)가 있다.
MRT를 사용하면 이들의 데이터를 한번의 복수 버퍼의 입력하는것이 가능하다

   그리고, 최종적인 픽셀 단위의 라이팅은, 그 전에 출력한 중간 값들을 사용하여 화면좌표계에서 포스트 프로세스 적으로 수행한다. 픽셀 단위의 음영처리를 나중에 수행하므로 「Deferred(연장)Shading」이라는 이름이 붙여졌다. 참고로 이것을 처음 제안한 사람은 Michael Deering씨로 이 알고리즘을 20년전인「SIGGRAPH 1988」에 발표하였다

    회사가 자랑하는 킬러 타이틀로써 PS3 최고의 그래픽스를 요구하는「KILLZONE 2」에서는 셰이더가 무거운 것이 확실하므로 렌더링 파이프라인으로써 Deferred Shading을 채택했다는 것이다。

【Deferred Shading 처리 프로세스】
심도값(Z값、Depth 값)카메라좌표계에서의 법선벡터 정보
스펙큘러 강도하이라이트 강도
움직임 벡터텍스처 컬러
Deferred Shading 완료후포스트프로세스 적용후 완성화면



■ 「KILLZONE 2」이 채택한 Deferred Shading 파이프라인이란?(2)
 ~ 구현과 지오메트리 패스

「KILLZONE 2」의 Deferred Shading 4MRT 내역。Deferred Shading에서 이 복잡한 중간값들을 저장하는 버퍼를 싸잡아서「G-Buffer」라고 부른다
 「KILLZONE 2」에서 Deferred Shading은 2개의 커다란 스텝으로써
    (1)지오메트리・패스(G버퍼 작성 부분)
    (2)라이팅・패스(픽셀・셰이딩) 

의 2단계로 나뉜다. 처음 지오메트리・패스에서는 씬내의 모든 폴리곤을 평범하게 렌더링하지만, 무거운 픽셀셰이더에 의한 라이팅은 수행하지 않는다。

 PS3의 GPU인 RSX는 NVIDIA GeForce 7800 GTX의 기능을 떨군것이며、DirectX 9세대의 GPU이기 때문에 MRT는 4장까지 가능하다。「KILLZONE 2」의 Deferred Shading 지오메트리・패스 에서는 이 4MRT로 그림과 같은 RT0~3까지의 4장의 출력을 수행하고 있다

   우선 MRT에 사용되는 출력 포맷으로는  PS3의 RSX에서는 FP16-64비트 버퍼는 패스의 성능상 능력부족이므로 필연적으로 정수32비트 버퍼(RGBA8)이 선택되었다.

  다음으로 렌더링 해상도는 1,280×720을 채택。AA는 NVIDIA의 Quincunx 2×MSAA모드를 적용하여、1,280×720×(RGBA8×4장+D24S8)×2×MSAA로 합계 36.8MB의 대역폭 소비라고 어림잡을 수있으므로, 개발팀에서는「뭐어, 이정도면」이라는 것으로 결정했다라고한다.
또한 4MRT로 출력된 각 중간치 값을 가지고 있는 버퍼는 후에 말할 포스트프로세스등으로 저해상도판으로 변환되어 재사용된다。
  
     그럼 4MRT로 출력된 각 버퍼(G 버퍼)의 내용을 순서대로 보자

    Depth(심도)/ 스텐실 버퍼는 씬의 완성후의 Z값이 저장된다. 라이팅계산에서 좌표계의 위치정보가 필요할때는 이 Z값을 가지고 역산해서 구한다.

RT0의 Lighting Accumulation Buffer(LAB)는 입사광정보를 기록해두는버퍼이며 픽셀라이팅을 수행할때에도 사용된다。처음의 지오메트리・패스에서는 LAB에는 라이트맵이나, 후에 이야기할 Light Probe를 사용한 의사 대국조명의 결과, 환경광등을 적용한 결과가 출력된다。LAB의 α부분에는 HDR휘도값이 저장되어 있으며 그휘도레인지는0.0~2.0。「KILLZONE 2」의 HDR렌더링은 정수 32비트 버퍼를 사용한 의사 HDR 렌더링으로 되어있다。

 RT1은 지오메트리・패스에서 각 픽셀에서 카메라좌표계의 법선벡터 x,y가 저장된다. 법선맵의 적용결과등도 여기에 저장된다. 법선 벡터는 정규화 되어있으므로 (절대값=1)역산이 가능하기 때문에 z값은 저장되지 않는다. 구체적으로 말하자면「z=√(1-x^2-y^2)」로 구해진다(z의부호는 항상(+)이지만 손실되는 부분은 없다)。

   법선 벡터의 x, y 는 16비트 부동소수점(FP16)으로써 저장되며, 이때에 FP16x2를 32비트 정수버퍼로 저장하는 NVIDIA계 GPU의 특유명령인 unpack_4ubyte명령을 사용하고 있다

   RT2의 R과 G 에는 지오메트리・패스에서 화면좌표계의 움직임 벡터(Motion Vector)가 저장된다. RT2의 활용에 대해서는 후편의 모션블러 부분에서 다룰 것이다. RT2의 B와α에는 스펙큘러와 관련된 파라미터가 들어간다。B에는 어느정도 강도의 하아라이트를 낼것인가를 나타내는 계수값을 로그값「log2(n)/10.5」으로 저장된다(Specular Power)。α에는 어느정도의 스펙큘러 반사를 수행할것인가의 강도를 나타내는 스펙큘러 강도(Specular Intensity)가 저장된다。

 RT3의 RGB에는 오브젝트에 적용된 텍스처 컬러가 저장된다。RT3의 α는 미리 계산된 평행광원(태양광)으로부터의 정적인 그림자 렌더링 결과가 저장된다。

【Lighting Accumulation Buffer】
지오메트리・패스를 끝낸 직후의Lighting Accumulation Buffer。실질적으로는 정적인 라이팅만 수행된 상태. 테스트 화면이기메 텍스처는 굳이 적용 안함라이팅・패스를 끝낸 직후의Lighting Accumulation Buffer。동적인 라이팅까지만 수행된 상태. 테스트 화면이기에 텍스처는 굳이 적용안함. 음영의 차이나 그림자의 유무에 주목할것



■ 「KILLZONE 2」이 채택한 Deferred Shading 파이프라인이란?(3)
 ~ 라이팅・패스

Deferred Shading의 라이팅・패스는 처리적인 시점에서 표현하면 [광원을 렌더링한다]라는 이미지다 
  라이팅・패스에서는 1프레임당 100 이상의(경우에 따라 300이상도)동적광원으로부터의 라이팅, 10개이상의 그림자생성을 동반한 동적광원으로부터의 라이팅 설정을 수행하기 때문에 매우 무거운 부분이다.

   포워드 렌더링에서는 3D 오브젝트 기준으로「3D오브젝트에 어떤 빛이 닿고 있는가」라는 개념으로 라이팅을 수행하지만 Deferred Shading에서는 이미 완성된 2.5D적인 영상에 대해서 화상처리 비슷하게 포스트프로세스로써 광원을 렌더링한다. 예를들면 300개의 광원이 있으면 300회의 화면의 포스트프로세스를 수행한다。

   개념적인 이야기를 하자면 지오메트리 패스에서 그려진 입체적인 무채색의 모형상자에 대해서 속속 빛을 비추어 색을 입히는 공정이다.
무수히 많은 광원이 씬내의 3D 공간에 배치되어있어도 모든 광원이 무언가를 비추는 것은 아니다. 포워드 렌더링에서 [ 보이지 않는 오브젝트를 그리지 않는다 ]라는 최적화 수법이 있는것처럼 Deffered Shading에서는 영향을 주지않는 광원은 스킵 한다 라는 최적화를 수행한다。

   또, 영향을 주는 광원이라고 해도 화면내의 어느 픽셀을 비출지 어떨지에 대한 테스트를 수행하여 영향이 있는 픽셀에 대해서만 라이팅 연산을 수행한다. 점광원은 그 영향범위가 구체로 되어있으므로 빛이 도달하는 범위의 구체를 지오메트리・패스후에 생성이 끝난 씬의 심도(Z)값을 분석해나가며 별도의 심도(Z)버퍼에 렌더링 한다

   그림자 생성에서 스텐실섀도우 볼륨기법이라는 것이 있는데  이것과  비슷한 발상으로 빛영역(Light Volume)을 렌더링 하는 것이다. 렌더링한 Light Volume을 사용하는것으로 화면내의 어떤 픽셀이 그 광원의 영향하인가를 판정할 수 있으므로 남은것은 희망의 라이팅 계산을 하는것 뿐이다

【라이팅 ・패스】
시점에서 봤을때Light Volume의 후면보다더 전면에 있는 픽셀을 마크한다시점에서 봤을때Light Volume의 전면보다도 후면에 있는 픽셀이 라이팅대상이 된다고 판정한다


■ 「KILLZONE 2」가 채택한 Deferred Shading 파이프라인이란?(4)
~ 태양광(평행광원)라이팅에 관련된 특별처리와 그림자 생성

   동적광원은 이전에 말했던 Light Volume 방식으로 라이팅을 설정하지만, 문제는 전역에 내리비치는 평행광원(태양광)이다. 평행광원이 움직이지 않아도 동적 캐릭터는 움직이므로, 방향을 바꾸거나 자세를 바꾸거나 하면 음영은 변한다. 따라서 라이팅・패스에서의 라이팅설정은 필수불가결이다.

  하지만 생각해보면 태양광은 전역에 내리 비치므로 화면 전체가 Light Volume내에 들어오는것과 같은 원리이다. 그래서 개발팀은 유니크한 기술을 적용하고 있는데, 그것은 지오메트리・패스에서 생성한 RT3의 태양광으로부터의 정적인 그림자 정보이다. 이 RT3에 있는 그림자 부분은 태양광이 닿지 않는다 라고가정할수 있으므로 태양광의 라이팅 설정 범위 밖이다 라고 간주하여 라이팅・패스에서 스킵 해버리는 것이다。

【태양광(평행광원)라이팅】
지오메트리・패스 후에 RT3에 저장된 정적 그림자즉 이 부분은 태양광으로부터의 라이팅 설정 적용범위가 아니다라고 간주 할 수 있다 ( 붉게 마크한 부분)완성화면

「KILLZONE 2」의 그림자 생성은 뎁스 섀도우 기법과 정적인 그림자의 하이브리드 표현으로 되어있다
캐스케이드 된 4장의 섀도우 맵을 색깔로 나누어 가시화한 테스트 샷
 「KILLZONE 2」에서 그림자 생성은 RT3에 지오메트리・패스에서 렌더링하는 정적인 그림자와 동적 캐릭터용의 동적인 그림자 2개의 조합으로 표현되고 있다.

  또한, 동적 오브젝트라도 원거리에 있다거나 그림자가 드리워져있어도 드리워져 있는지 모르는 작은 오브젝트, 미치는 영향 범위가 작은 광원으로부터의 그림자에 대해ㅓ는 부하절감의 관점으로부터 동적 그림자 생성을 생략하여 수고를 덜고 있다(최적화)。

   동적인 그림자 생성에느 극히 일반적인「뎁스 섀도우」(섀도우 맵)기법을 채택하고 있으나 몇가지의 독자적인 개량을 하여 사용하고 있다。

  또한 뎁스 섀도우 기법의 자세한 사항이나 개량형에 대해서는 「3D게임 팬을 위한 Xbox 360 그래픽스 / 물리엔진강좌」를 참조할 것。

   독자적인 개량의 첫번째는 그림자 품질의 향상을 위해 시점과의 거리에 따라 4장의 섀도우맵을 캐스케이드 시켜서 이용하고 있다는 점이다.
1장당 섀도우맵 용의 뎁스 버퍼는 최대 16비트의 1,024 x 1,024 텍셀.


 2번째는 뎁스 섀도우 기법에서 자주 문제시되는 그림자에 엣지 점멸의 폐해이다. 시점이 움직일때에 섀도우맵용 텍스처가 시선벡터와 싱크로가 맞아 회전해버리는 것이 원인이다。

   보고있는 대상물이 움직이지 않아도 보고있는 측이 움직이는것으로 섀도우맵 내에 새겨진 그림자 영역의 그리는 방식이 변해버려, 이것이 최종적인 씬에서 그려진 그림자의 윤곽이 흔들리고 있던 것이다.

「KILLZONE 2」에서는 이것을 개량하기 위해 월드 좌표계에서 섀도우맵을 캐스케이드 시키는 방식을 사용했다. 이것에 의한 그림자의 윤곽의 진동이 진정되었지만, 섀도우맵의 이용효율이 일정하지 않게되어, 경우에 따라서는 그림자 해상도가 떨어지는 상황도 생길 가능성이 있다고 하고 있다。

【그림자 생성】
가장 구석(LEVEL3)은 그림자 생성 없음LEVEL2。정적인 그림자는 보인다LEVEL1。정적인 그림자와 동적인 그림자 양쪽이 그려지고 있다
가장 앞(LEVEL0)。여기도 정적인 그림자와 동적인 그림자 양쪽이 그려지고있다동적 생성된 그림자만 나타낸것정적 생성된 그림자만 나타낸것
완성화면대상물이 움직이지 않아도 섀도우맵내의 사용방식이 변한다섀도우맵을 월드 좌표계 기준으로 회전시키지 않고 캐스케이드 시키는 방식을 사용했다


■ 「KILLZONE 2」에서의 의사 글로벌 일루미네이션
~ Light Probe정보를 SPU에서 구면 텍스처로


Light Probe를 가시화한 화면
l=0、1、2、3… m=-l~+l에서 구면조화함수의 3차원 가시화 그림. 예를들면l=3의 4단까지 사용한다고 하면 총 16개의 구면조화함수를 사용하게 된다
   현 세대의 3D 게임 그래픽스에서 선진적인 스튜디오 들이 대부분 적용하고있는것이 의사적인 글로벌 일루미네이션(GI:Global Illumination:대국조명)이다。

   현실세계에서는 광원으로부터의 직접광에 의한 조명뿐만아니라, 조명을 받은 오브젝트 자체가 2차광원이 되거나 오브젝트끼리 서로 비춰주거나 하여 복잡한 조명효과를 내고 있다. 이것이 글로벌 일루미네이션이다. 특히 상호 반사에 착안한것이 라디오시티(Radiosity)라고 불린다。

   기본적으로 현재의 리얼타임 3D 그래픽스 파이프라인은「(차폐물을 고려하지 않는다)직접광에 의한 조명뿐」밖에 처리되고있지 않으므로 GI를 구현하려면은 몇가지 생각을 해야 한다. 단지 현행의 GPU에서는 GI를 리얼타임 처리 하는 능력은 아직 없으므로 사전계산을 동반하여 그럴듯하게 하는 의사 수법을 사용하는 것이 주류이다(2009년 당시)。

 「KILLZONE 2」에서는 본연재의「소닉・월드・어드벤처」(소닉WA)편에서 소개한 라이트 필드(Light Field)방식과 같은 부류의 기술을 채택하고 있다。「KILLZONE 2」에서도 소닉WA에서 말하는 GI 텍스처를 오프라인에서 렌더링하고 작성하여 라이트맵 화 시키고 그때 동시에 게임내 씬에 대해서 적당한 간격으로 Light Probe를 설치하고 있다。Light Probe란, 그 위치에 두어서 빛이 전방위로부터 어떻게 들어오고 있는가를 얻어내는 것。

   라이트 맵생성과 Light Probe의 계싼은 전부 정적광원(움직이지 않는광원)을 설치하여, 충분한 시간을 들여 상호 반사할때까지 고려한 대국 조명 계산을 수행한다. 그래서 각 Light Probe는 그 포인트에서 전방위로부터 오는 [ 복잡한 대국조명 계산 결과]의 빛을 얻을 수 있다。

   예를들면 천정에서 하얀 형광등이 있는 좁은 방이 있고, 그 방에 왼쪽에있는 벽은 빨갛고 방 중간에 Light Probe가 있다고 하면 그 Light Probe는 위에서 하얀 빛을 받아 왼쪽으로 부드러운 빨강(형광등으로부터의 빛을 받은 빨간 벽으로부터의 반사광)을 얻을수 있게 된다。

   리얼타임 렌더링시에는 이 Light Probe의 전방위로부터 광량정보를 기초로하여 그 씬 안을 돌아다니는 동적 캐릭터들의 라이팅 설정 정보로써 이용하는 것이다. 이로 인해 라이팅이 설정된 동적 캐릭터는 사전 계산한 대국조명의 결과인 라이트맵으로 스며들게 된다. 동적 캐릭터가 움직이면 다른 Light Probe로부터의 조명이 반영되므로 마치 그 씬의 간접광까지 고려된 것 같은 라이팅 설정이 되어 효과로써 마치 리얼타임으로 GI가 수행되는것 같이 보인다... 라는 것이다。

 「KILLZONE 2」에서는 1스테이지당 약 2,500개의 Light Probe를 사전 산출하여 설정하고 있으며 각 Light Probe는 구면조화함수의 l=2까지의 9개를( RGB분 3요소) KD 트리 데이터로 가지고 있다。

   구면조화함수에 대해서는 개념은 필자가 게재한 기사등을 참조 하면 좋겠지만, 간단히 말하면 전방위(방사상)의 에너지 분포를 근사화하여 표현할수 있는 편리한 함수이다. 가시화하면 오른쪽 그림 같이 된다. 개념적으로 예를들면 방사상의 수치분포를 몇가지의 계수치만으로 근사 재현을 할수있는 이른바 MPEG나 JPEG 같이 비가역 압축하는 메소드라는 것이다。

 「소닉 WA」에서는 이 Light Probe와 대응하는 정보를 8방향으로부터의 이산치(離散値)로써 가지고 있지만「KILLZONE 2」에서는 9개의 구면조화함수(의계수)로 가지고있다。

  실제 리얼타임 렌더링 시에는 근접하고있는 4개의 Light Probe를 읽어내어 구면조화함수로부터의 그 Light Probe 전방위광량을 디코딩하여 이것을 바탕으로 8x8 텍셀의 구면상 텍스처(구면좌표계의전방위 텍스처)를 작성하고 있다. 어디까지 가장가까운 4개의 Light Probe를 읽어내어 거기서부터 가중평균적으로 보간하고 있다。

【Light Probe】
근접한 4개의 Light Probe를 읽어내어 구면조화함수를 디코딩하고그 캐릭터를 밝히는 전방위로부터의 환경광을 산출이것을 8×8 텍셀의 구면상 텍스처로써 생성

   뭔가 무거운 처리같이보이지만「KILLZONE 2」에서는 이 처리를 SPU에서 수행하고 있다.
개발팀의 발표에 의하면 1프레임당 약 600개의 Light Probe를 읽어내고 있으며 일련의 이 처리의 부하는 1기의 SPU로 약 13% 정도라는 것。

   실제의 픽셀 셰이더에서의 픽셀 단위의 라이팅 설정에서는 각 픽셀로부터의 법선 벡터를 바탕으로 이 구면상 텍스처를 샘플링하여 그 값을 환경광처럼 다루어 라이팅을 설정한다。

   600개의 Light Probe를 읽어내는 것은 「KILLZONE 2」에서는 이 구면상 텍스처를 캐릭터의 부위(발, 허리, 팔 등)단위로 세세하게 수행하고있는것에도 기인하고 있다. 그 대신 상반신과 하반신은 다른 간접조명효과를 얻을 수 있으므로 리얼하게 보인다。

 「소닉 WA」에서는 캐릭터의 중심 오프셋 값을 정하여 거기서부터 라이트 필드를 적용하고 있다。「소닉 WA」는 캐릭터의 키가 그다지 큰 차이가 없어 전체적으로 캐릭터가 「덩어리」로써 존재하고 있기 때문에 세세하게 할 필요가 없었을 것이다。「KILLZONE 2」에서는 일어나 있거나 움츠리고 있거나 팔을 내 젓거나 하면 인간형의 캐릭터가 상하좌우로 변형하므로 이같은 구현이 필요했던 것이다。


【Light Probe -2 】
동적 캐릭터(오브젝트)를 하얀색으로 채색한 테스트 샷. 이 씬에서는 바닥만이 정적인 오브젝트이다동적 캐릭터(오브젝트)의 Light Probe에 의한 환경광과 태양광(평행광원)만 라이팅을 설정한 결과완성 프레임


■ 정리~ Deferred Shading은 PS3용?

유럽에서도 높은 평가를 받은「KILLZONE 2」이 일본에서도 드디어 4월 23일 발매된다(2009년)
 「KILLZONE 2」강좌의 전편에서는 Deferred Shading을 중심으로 설명하였다。Deferred Shading은 무언가 돌려서 하는 기법이라고 생각할수도 있지만 동적 캐릭터 수나 씬의복잡성의 좌우되지 않는 동적광원으로 확장성있는 라이팅 설정을 수행할수있는 것이 이점이다。

   간략한 설명을 하자면 예를들어 포워드 렌더링 에서는 100개의 캐릭터를 4개의 광원으로 비춘다고 했을때 100x 4 = 400번의 라이팅 계산이 필요하지만 Deferred Shading이라면 미리 100개의 지오메트리를 라이팅 설정 없이 렌더링하고 이후의 4개의 광원을 렌더링해서 라이팅을 설정하면 라이팅 계산은 4번으로 끝난다. 부하에 따라서 라이팅에 사용한 광원의 개수를 늘이거나 줄일 수도 있다。

   포워드 렌더링에서는 동적광원의 수가 변하는것만으로 셰이더내에서 참조하는 변수들이 변해버리기 때문에 같은 경향의 라이팅을 하는 셰이더라고해도 별도의 셰이더로 변환하지 않으면 안되는 현재의 번잡한 프로그래머블 셰이더 아키텍처에 영향을 주지 않는 것도 이점이다。

   다양하고 부유한 셰이더 그래픽스 표현을 수행하는 타이틀에 Deferred Shading을 적용하는 예가 늘어나고 있는 것은 이러하 이점이 커다랗게 작용하고 있는 것 같다。

 Deferred Shading을 채택한 3D 게임으로써는「Bionic Commando」(CAPCOM)、「S.T.A.L.K.E.R.」(GSC Game World)、「Tabula Rasa」(NC soft)등이 있으며 이후에도 구현 사례가 늘어날 것이라고 예상된다。

   참고로  Deferred Shading은 Xbox 360에서는 힘들다라는 의견도 있다。Xbox 360은 GPU에는 대역폭 부족을 커버할 목적으로 10MB의 EDRAM이 탑재되어있다。Xbox 360에서는 해상도가 높은 프레임, 혹은 MRT로 EDRAM용량의 10MB를 넘어선 대량출력을 동반한 렌더링을 할 경우에는 한번의 렌더링이 10MB의 EDRAM으로 처리되도록 분할해서 렌더링할 필요가 있다。

 Deferred Shading의 경우 지오메트리・패스에서 ㅗ화면 전역의 중간 치를 출력하게 된다.
예를들면 1,280 x 720의 프레임으로 4MRT를 하면 심도 버퍼를 포함하지 않는 상태로 14MB에 달해버려, 10MB를 가볍게 초과해버린다.  7MB x 2 로써 분할렌더링 한다고 해도 2분할째의렌더링시 1분할째의 렌더링한  결과는 클리어되버린다.
1분할째를 대비하면 메모리 버스 소비가 커져서 퍼포먼스가 떨어진다.
Xbox 360애서도  전혀 안되는 것은 아니지만 Deferred Shading은 PS3나 PC용 기법이라고 말할 수도 있겠다

 또 Deferred Shading에도 약점이 있다. 우선 지적되고있는것이 반투명 오브젝트를 좋은 효율로 처리하는 기술이 없다는 점이다。Deferred Shading에서는 반투명 오브젝트에 대해서는 포워드렌더링에서 그린다라는 것이 가장 심플한 해결방법이지만 반투명 렌더링이 많은 씬에서는 Deferred Shading의 메리트를 활용할수 없는 경우도 일어날 것이다. 그저 GPU의 성능면에서 핸디캡을 떠 맡고 있는 PS3에 있어서는 Deferred Shading은 유효한 수법에 하나라는 것은 틀림없다. 이후 PS3전용 타이틀을 중심으로 Deffered Shading에 채택이 증가할지도 모르겠다。

  

KILLZONE 2 (C) Sony Computer Entertainment Europe. Published by Sony Computer Entertainment Inc. Developed by Guerrilla.

(2009년 4월 17일)