꽃미남 프로그래머 김포프가 창립한 탑 프로그래머 양성 교육 기관 POCU 아카데미 오픈!
절찬리에 수강생 모집 중!
프로그래밍 언어 입문서가 아닌 프로그래밍 기초 개념 입문서
문과생, 비전공자를 위한 프로그래밍 입문책입니다.
jobGuid 꽃미남 프로그래머 "Pope Kim"님의 이론이나 수학에 치우치지 않고 실무에 곧바로 쓸 수 있는 실용적인 셰이더 프로그래밍 입문서 #겁나친절 jobGuid "1판의내용"에 "새로바뀐북미게임업계분위기"와 "비자관련정보", "1판을 기반으로 북미취업에 성공하신 분들의 생생한 경험담"을 담았습니다.
Posted by 김포프
게임데브포에버에 무슨 글을 올릴까 고민을 좀 해봤는데... 그래픽 전문자료들은 이미 다른 필자분들이 열심히 올리고 계셔서 요번에는 그냥 제 경험담을 올리도록 하지요.. (이런 글을 원하시는 분들도 꽤 계실듯...?)


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

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

디퍼드 라이팅
제가 요번에 적어드릴 경험담은 디퍼드(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!: 언제나 실제로 성능을 측정해볼 것....


댓글을 달아 주세요

  1. Favicon of https://gamedevforever.com 친절한티스 2012.02.01 09:53 신고  댓글주소  수정/삭제  댓글쓰기

    여기저기서 디퍼드 이야기 하니 무조건 좋은 건줄 아는 분들이 많긴 하더군요.

    • Favicon of https://gamedevforever.com 김포프 2012.02.01 10:14 신고  댓글주소  수정/삭제

      그 buzz word라고 하거든요.. 뭐라.. 그러지 한국말론... 그냥 유행어 같은거? 엔진 팔아먹는 마케팅 용어들..

      dx9 하드웨어에서는 포워드 렌더링을 쓰는게 더 나은 게임들이 거의 대부분인거 같아요.

  2. Favicon of http://dishdev.me/ Dish 2012.02.01 10:01  댓글주소  수정/삭제  댓글쓰기

    사례 제시하면서 말씀하시니 재밌네요 ㅎㅎ

  3. Favicon of https://gamedevforever.com 죠쉬 2012.02.01 10:04 신고  댓글주소  수정/삭제  댓글쓰기

    오, 재미있게 읽었습니다.
    내용에도 감명을 받았지만
    포프님 혈액형은 AA 일지도 모르겠다는 생각을 해봤습니다.
    하나하나 꼼꼼히 나열해가며 장단점 분석이라니!!!

  4. Favicon of https://gamedevforever.com 알콜코더 2012.02.01 10:27 신고  댓글주소  수정/삭제  댓글쓰기

    재밌고 좋은 내용 감사합니다. ^^
    저도 디퍼드 쓰면서, 반투명 때문에.. 고생 많이 했었죠.. ㅎㅎ

  5. Favicon of https://gamedevforever.com 대마왕J 2012.02.01 13:50 신고  댓글주소  수정/삭제  댓글쓰기

    엔진에서 디퍼드 지원해서 쓰는데... 고급 효과가 많이 지원해서 쓰려 하는데.. 언제나 갈등이라죠

    • Favicon of https://gamedevforever.com 김포프 2012.02.02 06:55 신고  댓글주소  수정/삭제

      어차피 PC쪽이니 AA는 무난하게 FXAA로 처리하실수 있을테고... 반투명 물체 처리만 걱정이겠네요..

      유니티 쓰지 않으시던가요? 유니티에서 디퍼드 쓰면 반투명 물체는 어떻게 처리해주나요? 그냥... 포워드로 해주나?

    • Favicon of https://gamedevforever.com 대마왕J 2012.02.02 12:45 신고  댓글주소  수정/삭제

      넹 포워드 처리해요. 건드릴 수 있는게 얼마 없는게 딱 제 수준... 라이팅 좀 실시간으로 군데군데 박아 볼라구요. 근데 디퍼드라고 해도 라이트가 커서 겹치면 그것도 느려지더라고요? 완전한 자유는 아닌 듯 .. 그래도 다행히 엔진이 전환이 자유로우니 실험을 좀 더 해봐도 될 것 같습니다. 어차피 반투명은 잘 안써요. 이펙트랑 물 외엔..

  6. Favicon of https://gamedevforever.com zinzza 2012.02.01 14:11 신고  댓글주소  수정/삭제  댓글쓰기

    팔아먹는 시기에... "디퍼드렌더링을 이용한 뛰어난 광원효과!" ... 라는 말이 박스에... 아... 90년대 스타일 ㅜㅜ

    • Favicon of https://gamedevforever.com 김포프 2012.02.02 06:56 신고  댓글주소  수정/삭제

      그쵸.. 사실 디퍼드 렌더링을 이용한다고 광원효과가 뛰어나지는건 아닌데요 ㅎㅎ.. 그냥 조명의 수를 많이 쓸수 있단것 뿐인지...

      그것도 자잘한 조명들... 화면 가득 채우는 조명들이 10개 되버리면 아마 느려서 못쓸껄요 ㅎㅎ

    • Favicon of https://gamedevforever.com 끼로 2012.02.02 09:57 신고  댓글주소  수정/삭제

      게다가 디퍼드에서는 2차감쇄를 못쓰기 때문에... 잘못 배치하면 더 어설퍼지기도 하는것 같아요 그리고 처음에 디퍼드렌더링에 익숙치 않으면 필요이상으로 라이트를 많이 배치하거나 아니면 너무 큰 라이트를 배치해버려서 디퍼드 효율을 떨어뜨려버리거나..

    • Favicon of https://gamedevforever.com zinzza 2012.02.02 20:28 신고  댓글주소  수정/삭제

      두분다 어렵게 설명하지 말아요-o-;
      2차감쇄니 디퍼드니 다 몰라요 ㅜㅜ

    • Favicon of https://gamedevforever.com 대마왕J 2012.02.02 21:09 신고  댓글주소  수정/삭제

      저도 디퍼드는 첨에 라이트를 무조건 많이 넣을 수 있는 건줄 알았다지요. 근데 어차피 많이 겹치면 픽셀처리때에 무거워지는건 마찬가지더군요. 포워드도 Vertex 라이트와 SH라이트를 잘 섞어쓰면 꽤 이쁘게 표현할 수 있는데 말이죠. 근데 2차 감쇄는 뭔가용

    • Favicon of https://gamedevforever.com 끼로 2012.02.02 23:10 신고  댓글주소  수정/삭제

      아아.. 라이트 계산 방식.. 이라고 해야 하려나요 디퍼드에서는 라이트 영향 범위가 딱 떨어지게 정해야 하기 때문에 1차 감쇄를 써서 라이트 하나가 영향을 끼칠 수 있는 범위가 정확하게 떨어지고 그래서 그걸 중심으로 보통 메쉬를 만들어서 그걸로 픽셀 처리를 하게 되는데 원래 라이트라는게 점점 영향을 덜 줄 뿐이지 막혀있지 않는한 멀어진다고 해도 빛은 영향을 주긴 주자나요.. 그걸 보통 2차감쇄로 표현을 한다고 하는데 저도 자세히는 몰라요....... 퐆프선생님이 자세히 설명해주실꺼에요..

    • Favicon of https://gamedevforever.com 대마왕J 2012.02.03 01:05 신고  댓글주소  수정/삭제

      즉 라이팅을 진짜로 처리 안하는 것이란 말씀이군요. 디퍼드는 근데 어차피 2D 라이팅 처리니까 2차 감쇄가 큰 의미가 없을 것 같은데...

    • Favicon of https://gamedevforever.com 김포프 2012.02.03 03:42 신고  댓글주소  수정/삭제

      응? 2차감쇄가 뭐여? .....