2012년 2월 1일 수요일

새로운 기법 != 새 장난감

게임데브포에버에 무슨 글을 올릴까 고민을 좀 해봤는데... 그래픽 전문자료들은 이미 다른 필자분들이 열심히 올리고 계셔서 요번에는 그냥 제 경험담을 올리도록 하지요.. (이런 글을 원하시는 분들도 꽤 계실듯...?)


제가 이리도 오래 쉰내나도록(?) 게임 업계에 머무르는 이유 중 하나가 언제나 새로운 것들을 시도해 볼 기회가 충분하기 때문입니다. 특히나 그래픽 프로그래밍 쪽은 하루가 멀다하고 계속 발전하는 분야라서 마약처럼 매우 짜릿하죠. (마약이라고 좀 언급해두면 한국 정부에서 게임개발 셧다운제를 해주지 않을까하는 생각에...그럼 한국 게임개발자 분들도 정시퇴근 하실 수 있습니다. 회사 매출이 높으면 일찍 퇴근!)

근데 가끔은 이런 짜릿함에 눈이 멀어 게임을 망치는 경우도 좀 있습니다. 아직 검증되지 않은 새로운 기법을 동원할 때 그에 부수하는 단점들을 간과하는 경우가 허다하거든요. 심지어는 그런 단점들이 이미 잘 알려져 있더라도 장점보다 단점을 더 크다고 착각하는 경우도 문제입니다. (보통 이미 그 기법을 사용해서 게임을 출시한 개발자들이 하는 이야길 듣는게 검증인데.... 그 개발자들이 컨퍼런스에서 발표를 할 때는 당연히 단점보단 장점을 부각시키는게 일반적이라지요.)

디퍼드 라이팅
제가 요번에 적어드릴 경험담은 디퍼드(deferred) 렌더링에 대해서 입니다. 이미 아시는 분들은 아시겠지만 스페이스마린은 자체 개발한 디퍼드 라이팅(deferred lighting) 엔진을 씁니다. 뭐 찾아보면 좀 더 있겠지만 제가 당장 생각하는 퍼드 라이팅 렌더러의 장단점은 다음과 같습니다. (제가 생각하는 중요도 순서로...)

장점:

  1. 포워드(forward) 렌더링에 비해 사용할 수 있는 광원의 수가 많다. (예, '물체당 광원 3개' 라는 제한이 없어짐)
  2. 대부분의 조명을 동적으로 처리함으로 아티스트들의 작업시간이 빨라진다.
  3. 화면공간에서 행하는 후처리(post-processing) 기법들을 사용하기 쉽다. (예, SSAO, Screen Space Decal 등)

단점:
  1. (반)투명한 물체 처리가 골아프다.
  2. 하드웨어 자체적으로 앤티에일리어싱(anti-aliansing)을 처리하기 힘들다.
  3. 메모리를 좀 더 많이 잡아먹는다. (화면 해상도 크기의 렌더타겟들이 여러 개 필요)

스페이스 마린에서 디퍼드를 사용한 이유

원래 시작은...
스페이스 마린에서 디퍼드 렌더링을 사용한 이유는 사실 역사적인 이유가 강합니다. 스페이스 마린을 만들기 전에 Grand Theft Auto 류의 오픈월드 게임을 제작하고 있었는데 이 때 (2008년 중순) 다음과 같이 디퍼드 라이팅 엔진을 판단했었습니다.
  • 오픈월드 게임이니 광원의 수가 꽤 많겠군? 디퍼드가 좋겠어. (장점 #1)
  • 아무래도 밤낮이 바뀌는 효과가 있어야 하니 동적 조명이 좋겠는걸? (장점 #2)
  • 근데 배경이 도시니까 투명한 물체가 꽤 필요하겠는데? (단점 #1).... 으음... 뭐 투명한 물체는 디퍼드 말고 따로 포워드로 그려줘야겠군.. (어쩔수 없는그럴듯한 해결책)
  • 근데 앤티에일리어싱은 어쩌지? (단점 #2) 아직 1~2년 남았으니 나중에 고민해보지 뭐...(대충 책임 회피 -_-)
근데 이 게임이 한 6개월 만에 취소됩니다. 게임 자체에 문제는 아니었고 THQ가 구조 조정을 하면서 그 당시 스페이스 마린 게임을 개발중이던 THQ 호주 스튜디오를 문을 닫았죠. 워낙 렐릭이 워햄머 40,000 게임을 잘 만드는 회사로 유명했던지라 저희쪽에서 대신 해달라고.... 

그래서 처음부터 다시 스페이스마린을 만들었습니다. -_- (THQ 호주에서 만들어 놨던건 하나도 안썼죠.. 저희가 원하는 방향과 너무나 달라서...)

그리고 다시 결정을 내리기엔...
자, 그럼 이번엔 스페이스마린을 만들기로 했으니 다시 한 번 렌더링 엔진에 대해 고민해볼 차례인데... 이 때 (2009년) 저희의 생각은 이랬습니다.
  • 과연 광원의 수가 많을까? (장점 #1이 시들해짐)
  • 밤낮이 바뀌는 효과도 없는데? (장점 #2도 시들해짐)
  • 그런데... 아티스트들이 이미 디퍼드 라이팅에 맛을 들여서(iteration 시간이 매우 빨라졌어요... 모든게 동적 조명이니) 매우 원함... (장점 #2가 다시 살아남)
  • 또한 디퍼드에 기반해서 구현한 Screen Space Decal을 역시 아티스트들이 너무 좋아함 (장점 #3)
  • 서기 40,000년엔 투명한 유리창 따윈 이미 다 뽀개지고 없으니.. 투명한 물체는 그닥 문제가 안될 거야.. (단점 #1이 좀 완화됨)
  • 근데 앤티에일리어싱은 어쩌지? (단점 #2)요즘들어 이 분야에 대한 좀 발전이 있으니(Kill Zone 2가 SSAA를 대충 사용할 때..) 좀더 기다려보지.. (여전히 책임 회피... -_-)
  • 그럼 딱히 디퍼드를 할 이유가 없지 않아?..... 응... 없지.... 근데 이미 만들어 놓은거 다시 포워드로 돌리는 데 드는 시간과 비용이 과연 값어치가 있을까?......... 없군...... 
그래서 결국 디퍼드로 그냥 가기로 했죠. 최소한 아티스트들이 작업을 빨리할 수 있으니까 비주얼 품질이 높아질거라 생각했거든요. 그리고 그건 현실이 되었죠. 아티스트들이 여러번 손 대니까 확실히 스페이스마린의 비주얼 퀄리티도 상승.



그래서 단점은 어케 극복을?
그리고 시간은 흐르고 흘러서 2011년 9월 스페이스 마린을 출시했죠. 그렇다면 저 단점들은 어떻게 극복 했을까요?

투명한 물체
"서기 4만년엔 모든 유리들이 뽀작나서 더이상 투명한 물체가 없습니다 -_-;" 는 저희가 장난처럼 한 말이었는데... 사실 저희 게임에서 투명한 물체가 거의 없습니다. 종류따라 다음과 같이 처리했어요.
  1. 알파테스트: 반투명 블렌딩을 하기 보다 대부분의 물체는 완전투명 아니면 완전 안투명의 두가지로 처리했습니다. 이러면 디퍼드를 사용할 수 있죠.
  2. Screen Space Decal(SSD): 다른 물체의 표면에 찰싹 붙은 반투명한 물체는 SSD로 처리했습니다. SSD에 대한 자세한 내용은 위에 링크 걸어드린 발표자료를 참조하시길. 역시 깊이버퍼를 업데이트할 필요가 없는 놈들이라 디퍼드에 무난히 사용가능
  3. 특수 쉐이더: 머리카락에만 쓴 쉐이더인데 딱히 깊이 버퍼를 업데이트 하지 않고 머리통에 있는 법선 조명 정보를 대충 가져다가 씁니다. 즉 디퍼드도 포워드도 아닌 이상한 꼼수를 썼죠.
  4. 파티클: 파티클은 여전히 포워드로 했습니다. 워낙 투명하니... 저희 파티클 시스템은 또 워낙 빨라놔서.. (파티클 질을 저렇게 해도 콘솔에서 2.75 ms 밖에 안걸림)
이래서 투명한 물체는 해결... 사실 이걸 해결할 수 있던 가장 큰 원인은 아티스트들의 워크플로우를 뚜렷하게 정했다는 거에요. 뭐는 안되고 뭐는 되고를 확실히 알려줬고.. 안되는게 있으면 그걸 성취할 수 있는 다른 방법을 제시했고요.

앤티에일리어싱
그럼 앤티에일리어싱은 어떻게 해결을 했을까요? 사실 운이 좋았죠... -_-

다행히도 게임을 출시할 때쯤 해서 MLAA(God of War 3, The Saboteur)와 FXAA라는 기법들이 이미 개발되었었고... 저희도 FXAA에서 영감을 받아서 그것보다 한 0.1ms 정도 빠른 자체 기법을 개발했습니다. 한 0.8ms 걸렸죠. FXAA라고 해봐야 화면의 색상(또는 조도)을 대충 분석해서 갑자기 픽셀값이 변하는 부분을 적당히 블렌딩 해주는 기법이거든요.

콘솔에서 사용하는 FXAA 기법은 사실 좀 화면에 흐릿해진다는 단점이 있습니다. (PC버전과 달라요) 그래도 스페이스 마린의 비주얼은 만화스럽기보단 사실적에 좀 더 가까워서... 약간 흐릿해져도 큰 문제가 없었죠. (만화처럼 색이 강렬하고 짜잘한 디테일들이 막 들어가있으면 이렇게 흐릿해지는게 문제가 많아요.) 그래서 운좋게 대충 무사히 해결... 

지금와서 생각하는데 타사의 개발자들이 이런 기법들을 개발해 놓지 않았다면, 거기에서 영감을 받지도 못했을거고... 그러면 스페이스마린은 앨리어싱 때문에 꽤 타격을 받았을 거 같아요. 그렇다고 Gears of Wars 3처럼 아예 앤티 엘리어싱을 꺼버릴수도 없는거고... 운이 좋았죠. 책임회피는 했지만 운이 좋은.... -_-v

그렇다고 다 우리처럼 운이 좋을리는 없지?



그리고 스페이스마린을 출시한 뒤, 다른 회사의 게임을 좀 도와줬습니다. 몇 년전에 출시했던 게임의 후속작인데요. 따라서 그래픽 쪽으로는 특별히 손봐줄게 없겠다고 생각했죠. 어차피 컨텐츠만 좀 바꾸면 되니까. 그래픽 쪽은 좀 빠르게 만들어주거나 눈사탕 몇 개만 슬쩍 추가...?

근데 ... 아.뿔.사... -_- 소스코드를 열어보니... 포워드로 잘돌던 그래픽 엔진을 디퍼드로 바꿔버렸더군요..... 과연 왜 그랬는지 마땅히 말해주는 개발자들이 없어서.. 혼자 장단점을 따져봤습니다.
  • 광원의 수가 전 게임에 비해 늘었니? 아니... 거의 똑같은데... (장점 #1 실패 -_-)
  • 그럼 아티스트들의 작업시간은? 그림자를 오프라인에서 baking 하지 않으니 빨라짐... (장점 #2).... 근데 그림자 품질이 오프라인 처리할 때보다 저하되서 다시 baking을 시작하고 있음.. (결국 장점 #2 실패 -_-)
  • 화면공간에서 하는 후처리 기법은? 저번 게임하고 그닥 달라진게 없음... SSAO 정도 추가했나? (미약한 장점 #3)
  • 반투명한 물체는? 화면의 절반... -_- 여전히 포워드로 처리함... 한 10 ms 걸림... 쿨럭 -_- (심각한 단점 #1)
  • 앤티에일리어싱은? 아직 구현 안했었음...  스페이스마린에서 사용한 AA를 구현해줬으니 게임자체의 색상이 화려한 편이라 흐릿함이 눈에 거슬림.... 이걸 제대로 고치려면 PC버전에서 쓰는 FXAA를 써서 3ms낭비하거나... 아니면 깊이 및 법선 비교까지 해야함. 이러면 2.6 ms 정도 걸림.... (단점 #2)

아무리 생각해도 디퍼드로 갈 이유가 없는 게임이더군요. 아직도 정확한 이유는 모릅니다. 왜 디퍼드로 가기로 결정했는지.... '이론상으로' 포워드보다 낫다고 생각했고... 새로운 기법에 대한 짜릿함 때문에 그렇게 결정해버린 게 아닌지.. 생각만 할뿐..... 처음 게임이 더 비주얼이 좋을 거 같아요......버럭!

대충 정리
글만 주저리주저리 길게 쓰는 놈이라.. 대충 이 일화의 교훈(?)을 정리.
  1. 새로운 기법을 도입하기 전에는 반드시 장/단점을 반드시 따져볼 것. 특히 단점을 위주로...
  2. 그 기법을 이용해서 게임을 출시한 사람들이 발표하는 장/단점은 언제나 장점에 치우쳐 있음. 단점의 심각함을 2배로 곱해서 생각할 것...
  3. 그 기법을 이용해 컨텐츠를 제작할 아티스트 및 디자이너들을 프로토타입 과정에 포함시킬 것. 그 개발자들의 피드백이 좋지 않으면 그 보다 큰 단점이 없음.
  4. measure, measure and measure!: 언제나 실제로 성능을 측정해볼 것....



댓글 11개:

  1. 잘 읽었습니다.
    단점위주로... 뼈 저리게 느껴고 있습니다. 아주 큰 시행착오를 격은적이 있어서요 ^^

    답글삭제
    답글
    1. 흐... 이런 것들은 좀 겪은 사람들이 진작 공유해주면 좀 실수를 덜 할텐데요 ^_^...

      삭제
  2. 성능 측정에 대해 궁금한데요..

    주로 어떤방식 또는 툴을 사용해서 측정을 하시나요? 그냥 그때그때 만들어서 쓰시는지..

    답글삭제
    답글
    1. xbox360나 PS3는 마소와 소니에서 성능측정 툴을 주죠. 라이브러리 하나만 링크해주면 자체툴에서 자세한 성능을 확인해볼수 있고, 그 라이브러리 링크안해줘도 대략적인 측정은 가능합니다.

      PC쪽은 좀 이야기가 다른데요. 스페이스마린 같은 경우엔 PC성능이 콘솔보다 높았으므로 콘솔용으로만 취적화하면 PC쪽은 그냥 거의 먹어줬어요. 그게 아닌 경우는 자체적으로 프로파일을 측정해주는 코드를 넣어줬어야 했죠. (뭐 스톱와치의 개념임 사실...)

      전 써본적 없지만 이 외에도 V-Tune같은 상용 PC 프로파일 툴도 있긴 합니다.

      삭제
    2. 윈도우즈용 공짜 툴로 xperf가 있다는군요 매우 쓸만하다는걸요?

      삭제
  3. 이번에 이직하면서 도와주셨다는 다른 회사의 게임과 같은 상황을 겪고 있습니다 ㅠㅠ
    시간 괜찮으실때 댓글이나 메신저로 조언부탁드려봐도 될까요?

    답글삭제
    답글
    1. 아무래도 자세한 이야길 하려면 msn이나 이메일이 낫겠죠? 이메일/MSN 주소 둘다 popekim 앳 쥐메일 닷컴입니다.. 편한 곳으로 연락주세요~

      삭제
  4. 좋은글 잘봤습니다. 질문이 하나 있는데요.. 제가 그래픽 아티스트라서 디퍼드와 포워드의 개념설명은 어느정도 알것 같은데, 이것이 상용엔진에서는 어떻게 적용되는것인가요? 예를 들어 언리얼3 같은경우 이것이 기본적으로 포워드라고 말해야 하는건지 디퍼드 렌더러를 쓴다고 이해해야 하는지 아니면 프로그래머에 따라 유연하게 수정이 가능한것인지가 궁금하네요
    무식한 아티스트라 너무 기초적인 질문인가요?? ;;;

    답글삭제
    답글
    1. 원래 언리얼3엔진은 포워드 엔진이었습니다.. 근데 2011년에 디퍼드를 지원하기 시작했죠.. 프로그래머가 자유롭게 포워드와 디퍼드 중에 맘대로 선택할수 있습니다.

      유니티도 마찬가지입니다. 포워드/디퍼드 선택 가능.. 근데 아마 디퍼드는 상용버전 only 피처일겁니다.. ^^ 엔진 자체에서 지원을 안해준다면 프로그래머가 맘대로 디퍼드를 구현하기에는 조금 벅찰겁니다.. 엔진소스코드도 다 받아오지 않는다면요...

      삭제
    2. 작성자가 댓글을 삭제했습니다.

      삭제
    3. 아~~~ 그렇군요~~!! 빠른 답변 정말 감사드립니다^^

      삭제