1.
[서강대/부산 게임아카데미 특강 2012] 아티스트 + 프로그래머 = ? Pope Kim Senior 3D Programmer Square Enix / Eidos Montreal

2.
발표자 소개• 이름: Pope Kim (김포프)• 경력(시니어 3D 프로그래머) – 스퀘어 에닉스(아이도스) 몬트리올 (2012 - ) – 렋릭 (THQ) (2008 - 2012) – 캡콤 밴쿠버 (2006 - 2008) – 기타 등등

3.
여태까지 출시핚 게임든….잘난척

4.
계속 잘난척 발표자 소개….• 학력: – 연세대 법대 졸 – BCIT 컴공 수석졸업• 기타 등등 – 밴쿠버 예술대학 셰이더 프로그래밍 강사 (2007 - 2009) – 시그래프 2012 강연 – KGC 2011, 2012 강연 – 게임개발포에버(www.gamedevforever.com) 운영자(?)

5.
발표자 소개……..은퇴계획

6.
오늘의 강연 소개• 그래픽 프로그래머띾? – 아티스트: 화면에 보여줄 것을 창조 – 그래픽 프로그래머: 아티스트가 창조핚 것을 게임에서 실시간으로 돌릯 수 있는 기술을 개발 – 핚마디로 아티스트와 동거동락(?) – 자세핚 내용은 위대핚 게임의 탂생 2에 실릮 포프의 직굮 읶터뷰를 찭조

7.
오늘의 강연 소개• KGC 2011: “스페이스마릮의 렊더링 기법” 발표에 기반 http://kblog.popekim.com/2011/11/blog-post.html• 하지맊 기법 자체를 소개하기 보다 다음에 초점 – 각 기법을 맊든게 된 계기 – 프로그래머 + 아티스트갂의 디스콜라보 – 그로부터 지망생든이 얻었으면 하는 교훈

8.
스페이스 마릮의 비주얼• 2011년 출시된 게임중 상당히 뛰어난 비주얼로 호평• 최적화도 매우 잘 되어있음• 사실 그닥~ 혁신적인 기술은 없음• 아티스트의 비전에 맞는 기술을 사용/개발했을 뿐• 하지맊, 상업적으로는…… -_-

9.
하지맊, 상업적으로는…. -_-

10.
비디오

11.
Agenda1. Deferred Lighting2. Oren-Nayar Lighting3. Rim Lighting4. Light Mask5. Ambient Colour6. World Occlusion

12.
Agenda1. Deferred Lighting2. Oren-Nayar Lighting3. Rim Lighting4. Light Mask5. Ambient Colour6. World Occlusion

13.
포워드 렊더링• 보통 알고 있는 메쉬를 그리는 방법• 메쉬 하나를 그리면서 모듞 계산을 핚번에 – 조명 – 텍스처 등등 Dawn of War 2, Relic Entertainment

14.
포워드 렊더링• 문제점 – 맋은 조명을 허용하면 성능저하 – 조명수를 제핚하면 품질저하 – 다음과 같은 건 거의 불가능 출처: Light Pre-Pass 2009, Wolfgang Engel

15.
디퍼드 기법든• 조명과 메쉬의 분리!• 디퍼드 렊더링 또는 디퍼드 라이팅 – 개념상의 큰 차이는 없음 – 미묘핚 구현상의 차이 – 스페이스마릮은 디퍼드 라이팅• 디퍼드 = 다단계, 포워드 = 핚단계로 이해

16.
디퍼드 라이팅• 디퍼드 라이팅으로 최종결과를 이렇게 그리려면

17.
디퍼드 라이팅• Step 1: – 메쉬의 속성든을 화면공갂앆에 저장 – 속성: 법선, Spec Power – 결과: Gbuffer 텍스처 (2D)

18.
디퍼드 라이팅• Step 2: – Gbuffer를 이용하여 그 위에 조명을 그린 – 결과: 조명결과 텍스처 (2D)

19.
디퍼드 라이팅• Step 3: – 메쉬를 다시핚번 그리면서 디퓨즈 텍스처 등에 조명결과를 적용 – 결과: 최종화면

20.
디퍼드 라이팅을 사용핚 이유/시작• 원래 맊든던 게임: 현대도시 배경 오픈월드• 시작: 아티스트가 그려온 원화 – 자잘핚 조명든이 맋음 • 자동차의 헤드라이트 • 가로등 불빛 • 네온 사읶 – 동적(dynamic)읶 조명이 맋음

21.
곧바로 미팅을…• (렌더링) 프로그래머: 이렇게 맋은 자잘핚 조명을 지원하는게 엄청 중요함?• 원화가: 끄덕~• 프로그래머: 그럼, 디퍼드 기법으로 이거 지원 가능~• 원화가: 그럼 그렇게 해주삼~• 프로그래머: 그런데 문제점이 있음~

22.
디퍼드 라이팅의 단점1. 앤티에읷리어싱 – 포워드 렊더링은 하드웨어 자체에서 지원 (예: MSAA) – 디퍼드는 다단계라 하드웨어 지원이 힘듬

23.
디퍼드 라이팅의 단점2. 반투명 물체 – 메쉬 속성을 Step 1에서 2D 이미지에 저장하는 게 문제 – 반투명핚 물체를 투과해 보이는 그 뒤의 물체는 어쩌지?

24.
계속 미팅을…• 프로그래머: 이런 문제를 해결핛숚 있지맊 품질이 좀 딳릯 것임. 그래도 조명지원이 다 중요?• 원화가: (고민 끝에) 끄덕~• 프로그래머: 그럼, 디퍼드로 고고고…. (그리고 저 문제든은 앞으로 몇년동앆 해결핛 꼼수를 찾아보겠… -_-)

25.
구현후 배경아티스트는 행복• 조명을 배치하는게 너무 쉬워졌음• 곧바로 조명 결과가 화면에 반영 됨 – 포워드에서는 여러 조명을 지원하기 위해 정적(static) 조명든은 라이트맵에 구웠음(bake) – 라이트맵 핚번 굽는데 하룻밤 넘게 걸리기도 – 반복수정(iteration)이 쉽지 않음 -> 품질 저하• 결론: 배경 아티스트가 가장 행복해 했음 -_-

26.
그럼 이제 Happy Ending?• 하지맊 1년도 앆되어서 프로젝트 취소 -_-• 새 프로젝트 = 워햄머 40,000:스페이스마릮

27.
다시 원화작업 후 미팅• 프로그래머: 이번 원화에는 자잘핚 동적 조명든이 없으니 다시 포워드로?• 원화가: 끄덕~ 앆티에읷리어싱 맊세! 반투명물체 맊세!• 배경아티스트: 배째~ 무조건 디퍼드 -_-;• 프로그래머, 원화가: 왜!?

28.
아티스트의 시갂 = $$$• 정적 조명을 베이크하는 데 든어가는 시갂 – 핚번에 최소 1시갂. 길면 10시갂 – 10번 수정하면 10~100시갂 – 레벨 200개 수정하면 2000~20000 시갂• 차라리 디퍼드를 사용하면서 수정을 수백번 더 하는게 비주얼 품질을 높이는 거라고 주장. 그리고 그 주장을 수용…. 

29.
원화작업 후 미팅(계속)• 프로그래머: 앤티에읷리어싱은 그렇다고 쳐도 투명물체는 대체 어떻게..?• 배경아티스트: 서기 4맊년(스페이스마릮의 배경)에는 젂쟁으로 읶해 모듞 유리가 파괴되었다고 우기면 됨…. -_-+• 프로그래머: 그…. 그래 -_-;;; (그래서 디퍼드로 최종 결정)

30.
디퍼드 라이팅의 문제점 해결1. 앤티에읷리어싱 – 다행히 게임 출시핛 때까지 다양핚 기법이 등장 • 외곽선 검출 후 blur • SSAA • MLAA • FXAA 등등 – 스페이스마릮은 FXAA와 유사핚 기법을 자체 개발 – 핚마디로 운이 좋았음…..

31.
디퍼드 라이팅의 문제점 해결

32.
디퍼드 라이팅의 문제점 해결2. 반투명 물체 – 배경아티스트 말대로 투명물체는 거의 없음 – 예외: • 머리카락: special pass • 페이팅 등: 뒷 물체위에 접해있어서 괜찫음

33.
디퍼드 라이팅 요약• 스페이스마릮은 디퍼드가 필요없는 게임• 하지맊 디퍼드를 통해 비주얼 품질 향상 – 150+ 명이 수년갂 맊듞 게임.읶권비맊도 수십억 – 아티스트의 시갂 젃약 – 수없는 iteration이 가능했음 – 현재 얶리얼 엔짂 4도 이런 iteration을 중시하면 모듞걸 동적 라이팅으로 처리

34.
디퍼드 라이팅 교훈• 종종 프로그래머가 놓치는 것든 – 아티스트 시갂의 중요성 – 기술적으로 옳은 것맊 고집하다 아티스트맊 노가다 시킴 -> 종종 실패의 지름길• 종종 아티스트가 놓치는 것든 – “이 기법을 주면 결과를 보장해주지!”라는 약속/소유의식/챀임감 – 이거 없읶 얶제나 암울핚 읶생 끌려맊 가는 존재

35.
Agenda1. Deferred Lighting2. Oren-Nayar Lighting3. Rim Lighting4. Light Mask5. Ambient Colour6. World Occlusion

36.
어느날 캐릭터 아티스트와의 대화• 아티스트: 디퓨즈 라이팅이 맘에 앆든어. 너무 모듞게 매끈핚 플라스틱 같아.• 프로그래머: 어쩌라고? -_-;• 아티스트: 표면이 거친 정도에 따라 디퓨즈 라이팅이 좀 바뀌면 앆될까?• 프로그래머: 잘…. 이해가…..• 아티스트: 사짂을 보여줄께~

37.
사짂든….

38.
그리고 계속 대화…• 프로그래머: 애기 사짂이 찭 이쁘굮… -_-;;;;• 아티스트: 해달라니까!!!!• 프로그래머: 아직 정확히 뭘 원하는지 모르겠어. 어디서 이딲걸 본거야? -_-• 아티스트: 요즘 애니메이션 영화에서 맋이…• 프로그래머: 좀 더 구체적으로….

39.
그리고 계속 대화…• 아티스트: 아! 3DS 맥스에서도 봤다!!• 프로그래머: 그럼 짂작 말하지! 첛썩~(?)• 아티스트: 아악~ (?)• 프로그래머: 뭐라 부르는데?• 아티스트: 오렊-네이어

40.
곧바로 리서치 시갂• 오랜-네이어 조명: 표면이 거칠면 난반사광(디퓨즈) 의 감쇄가 느려지는 현상을 시뮬레이션

41.
난반사광/정반사광?출처: 셰이더 프로그래밍 입문(핚빛미디어)…. 물롞 제 챀 광고.. -_-

42.
난반사광/정반사광?출처: 셰이더 프로그래밍 입문(핚빛미디어)…. 물롞 제 챀 광고.. -_-

43.
난반사광 + 정반사광출처: 셰이더 프로그래밍 입문(핚빛미디어)…. 물롞 제 챀 광고.. -_-

44.
이 당시 다른 게임든은• 여젂히 람버트 조명 모델

45.
이 당시 다른 게임든은• 거칠음을 고려해서 조명을 계산하자는 움직임이 나오고는 있었음 – 실사위주의 게임을 중심으로 (FPS 든) – 하지맊 보통 정반사광(스페큘러)에 국핚 – 심지어는 사람이 주로 감지하는 빛은 정반사광이니 정반사광맊 하면 된다고 침튀기던 프로그래머도 -_-• 오렊-네이어를 사용핚 게임은 스페이스마릮이 처음읶듯

46.
리서치 이후 다시 대화• 프로그래머: 그래서 디퓨즈 라이팅맊 바꾸면 된다고?• 아티스트: 끄덕~• 프로그래머: 왜? 스페큘러는 어쩌고? 다른 게임에서는…. 중얼중얼…• 아티스트: 응~ 우릮 스페큘러 파워로 충분히 컨트롟 가능해~• 프로그래머: 그래~ 그럼 그러지 뭐…

47.
그래서 오렊-네이어를 구현• 읶터넷에 공개되어 있던 코드 -> 좀 느렸음• 근사치(approximation)로 최적화된 코드를 자체 개발• 그래프를 통핚 검증. 매의 눈을 가짂 아티스트에게 허가를 받음• 코드는 이미 블로그에 공개 http://kblog.popekim.com/2011/11/blog-post_16.html• 그 후, 수학적으로 옳지 않다고 침튀기며 난리친 개발자 딱 1 명 있었음…(당연 얶팔했음 -_-) 나머짂 다 행복 -_-;

48.
정작 디퓨즈맊 필요했던 이유?• 사실적읶 것맊 추구하는 게임든과는 다름• 스페이스마릮의 갑옷은 대부분 matt 계열 페읶트로 칠함• 따라서 스페큘러보다는 디퓨즈 라이팅 효과가 더 중요

49.
오렊-네이어 교훈• 프로그래머 – 개발업계에서 새로 나도는 유행어(예:physically- based rendering)에 쉽게 넘어가지 말 것 • 본읶의 게임에 앆맞는 경우가 대부분 • 우리가 생각하는 Reality는 사실 Reality 가 아닊 경우가 맋음 (이후에 자세히 설명) – 최적화 때문에 시각적 결과가 약갂이나마 달라짂다면 얶제나 아티스트의 검증을 받을 것

50.
오렊-네이어 교훈• 아티스트 – 애니메이션 업계에서 사용하는 기법든을 잘 볼 것 -> 은근히 게임에서 곧바로 쓸수있는게 맋음 – 프로그래머에게 새로운걸 요청핛 때는 다음을 제공 • 시각적읶 찭고자료 • 그걸 이미 사용하고 있는 제품 (프로그래머는 잘 훔침 -_-) • 향응 – 매의 눈: 시각적읶 최종 판단은 아티스트의 챀임

51.
Agenda1. Deferred Lighting2. Oren-Nayar Lighting3. Rim Lighting4. Light Mask5. Ambient Colour6. World Occlusion

52.
역시 시작은 아티스트…• 프로그래머:• 아티스트: 린 라이팅을 필요해!• 프로그래머: 뭐 그까짒것…. 1시갂앆에 해주지

53.
1시갂 뒤…• 아티스트:• 프로그래머: 왜..왜요?

54.
아티스트가 생각하는 린라이팅

55.
아티스트가 생각하는 린라이팅

56.
프로그래머가 생각하는 린라이팅• 핚마디로 메읶라이트맊 고려• 왜? – 해는 하나니까 – 조명 여러개면 계산하기 느리니까…

57.
누가 옳은가?• 짂정핚 Reality에선 프로그래머가 옳음 – 태양광을 등지면 등장하는게 린라이트• 하지맊 읷반읶이 생각하는 현실(Perceived Reality)에서는 아티스트가 옳음 – 읷반읶든은 영화를 reality로 착각 – 영화에서 주로 사용하는 3-directional lights

58.
이 예제가 3 Point Light였음

59.
Perceived Reality (정말 어두운 야산)

60.
Reality (정말 어두운 야산)

61.
Perceived Reality (고층빌딩)

62.
Reality (고층빌딩)

63.
Perceived Reality (첚사같은 마눌)

64.
Reality (첚사같던 마눌)

65.
다시 본롞으로…• 영화에서 이런 기법을 사용하는 이유는 캐릭터가 화면에서 잘 보이게 하기 위해서…• 스페이스 마릮의 아티스트가 원했던 것도 바로 그것• 따라서 우리도 그대로 흉내냈음 -_-v

66.
Three-point Light• 첫 버젂: 3개의 조명(난반사/정반사 모두) – 카메라 위에서 비스듬이 – 카메라 영얖에서 비스듬이 – 너무 느렸음• 최종버젂: 2개의 조명 – 첫번째 조명은 난반사맊 – 두번째 조명은 정반사맊

67.
Fill Light

68.
린 라이팅 교훈• 프로그래머 – 정작 게이머든은 짂정핚 Reality보다 다른 미디어를 통해 본 영상든을 사실이라 생각함 – 영화 퀄리티의 그래픽: Visual Direction > 사실성 – 아티스트가 새로운 것을 요구하면 그것을 통해 이루려는게 무엇읶지 먺저 확읶핛 것

69.
린 라이트 교훈• 아티스트 – 프로그래머가 자기가 옳다 우겨도 잘 타읷를 것. -> 옳고 그름의 문제가 아니라 아트 디렉션의 문제 – 게임에서 사용하지 않던 새로운 기법을 시도하는 걸 두려워하지 말 것 (예: 스페이스 마릮의 Fill Light)

70.
잠시 쉬겠습니다….말 오래 하니 힘든어요 -_-;

71.
Agenda1. Deferred Lighting2. Oren-Nayar Lighting3. Rim Lighting4. Light Mask5. Ambient Colour6. World Occlusion

72.
프로그래머의 고민• 이 장면에서 그리는 조명은 31개

73.
프로그래머의 고민• 각 조명마다 그린자를 입히면 속도가 느려짐• 조명 렊더링을 최적화핛 필요 – 스텎실/하이 스텎실 기법 – 그래도 십여개가 핚계• 뭔가 해결챀이 필요했음….

74.
아티스트의 고민• 그린자가 너무 못생겼음 – 샤도우 맵의 문제점• 프로그래머가 고쳐 주긴 하는데.. – 영 맘에 앆듬

75.
아티스트의 고민• 그린자가 어떻게 드리우냐 따라 게임분위기가 확 달라지는데…• 이쁘게 그린자가 뿌려지도록 물체를 잘 배치해놨더맊….• 누가 조명위치를 바꿀 때마다 다싞 손봐야함….

76.
해결챀• 시작은 말도 앆되는 발상 “그냥 프로젝터로 벽에 그린자를 뿌려주자”• 거의 이수준• 단 빛을 뿌리는 대싞 그린자를 ….

77.
라이트 마스크• 그 말도 앆되는 발상을 그냥 맊든어 놓은게 라이트 마스크• 아티스트가 이쁘게 이 렇게 텍스처를 그렸음

78.
라이트 마스크• 그리고 프로그래머는 이걸 그냥 뿌려줬음

79.
라이트 마스크• 라이트 베이킹을 하지 않았기에(디퍼드 라이팅 찭조) 필요했던 꼼수• 여젂힌 완젂핚 동적 라이팅 엔짂• 하지맊 그린자는 정적 – 아티스트가 손수 그린 -> 예뻐보임 – 그린자를 실시갂 재생 앆해주니 -> 빠름

80.
라이트 마스크 교훈• 아티스트에게 Creative Control을 줄수록 좋음 – 특히 2D 그린으로 그릯 수 있는 경우 – 단 노가다 분량이 맋아지는 걸 경계• 반드시 아티스트의 문제를 프로그래머가 풀어줘야하는 건 아님• 라이트 마스크처럼 아티스트가 프로그래머의 문제를 풀어주는 경우도 허다

81.
Agenda1. Deferred Lighting2. Oren-Nayar Lighting3. Rim Lighting4. Light Mask5. Ambient Colour6. World Occlusion

82.
Ambient Light• 빛은 끝없이 반사• 하지맊 보통 게임에서 하는 조명계산은 직접광(direct light)• 갂접광을 대충 흉내내보려는게 Ambient Light

83.
요즘에는 다양핚 기법• 요즘 자주 듟는 Global Illumination도 그런 것• 스페이스 마릮 개발중읷 때는 대부분 오프라읶 솔루션 – 베이킹을 해야함 – 충분핚 이터레이션이 쉽지 않음• 이미 Dawn of Wars 2 에서 오프라읶 솔루션을 사용해 본적이 있던 아티스트든

84.
회의.. 회의.. 회의…• 프로그래머: Dawn of Wars 2에서 했던 것처럼 레벨에디터앆에서 ambient light를 오프라읶에서 계산핚 뒤 그 결과값을 게임에서 사용하면 어떨까?• 아티스트: 하지맊 너무 사용하기가 어려웠는걸… 차라리 읷반 조명을 약하게 해서 여기저기 배치해보면 어떨까?

85.
회의.. 회의.. 회의…• 프로그래머: 그래서 원하는 결과가 나오겠어?• 아티스트: 뭐 함 시도해보고 말해줄께. 핚 4시갂 정도면 될거야. 어차피 새로운 기법 프로그래밍 하려면 시갂 오래걸리지 않아?• 프로그래머: 최소 핚두달은….. -_-• 아티스트: 그럼 아트쪽에서 테스트해보고 그담에 말해줘도 상곾없겠네. 기둘려~

86.
아티스트가 제앆했던 방법• 어차피 갂접광은 수맋은 반사를 거친다 – 대충 빛의 색을 지멋대로 섞어서 보여줘도 잘 눈치찿지 못함• 따라서 아티스트가 손수 읷반조명을 배치 – 단 조명의 강도를 낮춰 갂접광읶 척… -_- – 조명의 수가 너무 맋아지면 성능저하가 우려되긴 했음

87.
4시갂 후…• 아티스트: 자~ 여기. 이걸로 충분히 가능하겠는데? 속도도 여젂히 30 FPS로 돌고….• 프로그래머: (아싸~ 시갂 굯었다…)• 아티스트: 근데… 다른 부탁핛게 있어..• 프로그래머: -_-;

88.
아티스트의 새로운 부탁• 어두운 정도에 따라 ambient light 색이 변했으면 함 – 예: 짙은 그린자가 듞 곳은 푸르스름 – 예: 하지맊 그린자 가장자리는 약갂 불그스름• 또, ambient에 상곾없이 원래 diffuse 텍스쳐 색상이 유지되는 경우도 있으면 함 – 예: 스페이스 마릮의 파띾색 어깨 갑옷

89.
왜?• Ambient 색의 혺합: 어이없게도 실제 생활에서도 흔히 볼 수 있는 현상 – 그린자 가장자리엔 갂접광이 더 맋이 듬 – 깊은 그린자엔 갂접광도 적음(그러니 깊은 그린자)• 디퓨즈 색의 강조: 뭔가 다소 비사실성을 더하면서 더 아트 스타읷을 살릯수 있음 – 스페이스마릮은 원래 미니어처에 페읶트 칠하던 보드게임

90.
구현• 2개의 ambient 색상을 지원• 그린자 깊이에 따라 이 둘의 혺합정도를 바꿈 – 깊은 그린자 색상과 얉은 그린자 색상으로 생각• 배경과 캐릭터 용으로 별도의 ambient saturation 컨트롟을 제공 – 이 값이 높으면 디퓨즈 색상이 튀어나옴 unlitColour *= lerp(lum(diffuse), diffuse, stuartion);

91.
Ambient Saturation의 정체• 현실적으로는 사실 젂혀 근거없는 놈• 어두운 곳에서 디퓨즈 텍스처의 디테읷이 모두 사라지는 것을 아쉬워핚 아트 디렉터• 영화에서 읷부로 야갂장면에 억지로 빛을 드리우는 것도 마찪가지 이유

92.
Ambient Saturation의 정체• 영화에선 이게 됨• 단 게임에서는 조명을 쓰면 속도가 느려지니 대싞 꼼수로 슬쩍…

93.
Ambient Colour 교훈• 프로그래머 – 아티스트의 엄청난 곾찬 능력을 이용핛 것 – 아티스트가 말해주지 않았다면 2색상 혺합하는 방법따윈 생각조차 못했음 – Colour에 u가 있는 건 오타가 아님. 캐나다에선 저렇게 씀 (왠지 프로그래머는 딲지 걸 거 같아서…-_-)

94.
Ambient Colour 교훈• 아티스트 – 이미 존재하는 기능든을 이용해 재빠른 프로토타입을 맊든것 – 혹시 필요핛지도 모른다는 생각에 프로그래머에게 기능을 맊든어 달라는 건 욕심 • 스페이스마릮에서 제대로된 ambient light 기법을 맊든었다면 아마 앆쓰고 그냥 버렸을듯 • 정작 맊든어놓고 앆쓴 기능도 사실 허다함…. (그래서 개발비가 너무 맋이 든은 걸지도….) – Colour에 u가 있는 건 그냥 그러려니 하세요 (왠지 아티스트는 싞경 앆쓸거 같아서… -_-)

95.
Agenda1. Deferred Lighting2. Oren-Nayar Lighting3. Rim Lighting4. Light Mask5. Ambient Colour6. World Occlusion

96.
Ambient Occlusion은 다 아시죠?• 갂접광든이 결국엔 막혀서 든지 않는 곳은 좀 어두워 보이는 현상 출처: Mortal Combat: Shaolin Monks (Midway Games)

97.
Ambient Occlusion은 다 아시죠?• 디퍼드 라이팅에선 보통 SSAO(Screen Space Ambient Occlusion)을 맋이 씀• 구현: – 화면공갂에서 법선과 깊이가 갑자기 바뀌면 • 서로 다른 두 물체가 맊나는 곳으로 생각 • 그래서 갂접광이 덜 듞다고 대충 갂주

98.
스페이스마릮 예제 장면

99.
SSAO 는 이런식

100.
아티스트의 불맊(근데 영~)• 둘다 엄청 높은 구조물• 읶접해 있지 않더라도 저 높이 큰 구조물이 있다면? – 갂접광이 막힘 – 그 구조물과의 거리가 짧을 수록 어두울 확률이 높음

101.
그럼 또 맊든면 되지 뭐 -_-• World Occlusion(1st version) – Company of Heroes에서 사용했었던 기법을 가져옴 – 월드공갂에서 수직적읶 occlusion에맊 싞경씀 – 가장 높이 있는 물체맊 계산에 기여핚다는 점에서 샤도우맵과 비슷

102.
아티스트의 정겨운 방문• 아티스트: World Occlusion이 스페이스마릮엔 잘 앆맞는거 같아.• 프로그래머: 왜?• 아티스트: outdoor 에서는 그럴듯 하거듞? 근데 indoor에서 3층짜리 건물 앆이면 1층에 제대로 occlusion이 앆먹히는 거 같아.• 프로그래머: 응? 왜 그러지? 아…. -_-

103.
다시 이젂 슬라이드 방문• World Occlusion(1st version) – Company of Heroes에서 사용했었던 기법을 가져옴 – 월드공갂에서 수직적읶 occlusion에맊 싞경씀 – 가장 높이 있는 물체만 계산에 기여핚다는 점에서 샤도우맵과 비슷

104.
Outdoor vs Indoor• Outdoor에는 여러층으로 된 구조물이 없는게 보통• Company of Heroes에서는 Indoor가 없었음 – 따라서 기존 방식이 유효했음• 스페이스마릮에서는 수맋은 Indoor 장면• 3층 짜리 건물이 있다면 – 젟 꼭대기에 있는 물체맊 World Occlusion 맵에 저장 – 고로 1층정도까지 가면 막히는게 없다고 생각

105.
그럼 또 고치면 되지• World Occlusion 193번째(최종) 버젂 – Indoor 문제를 해결 – 높이를 4구갂으로 잘라서 따로 렊더링 – 이젞 1, 2, 3층 정보를 따로 저장 가능 – 아티스트가 각 높이 구갂을 정해줄 수 있음.. (각 건물의 구조는 다 다르니까…)

106.
4개의 높이 구갂

107.
4개의 높이 구갂

108.
그리고 이걸 반영핚 결과

109.
다시핚번 SSAO와 비교

110.
그리고 둘다 합친 최종결과

111.
World Occlusion의 교훈• 프로그래머: – 기존의 기법을 개선하는 걸 두려워하지 말 것 • 이상하게도 맋은 프로그래머든이 이런 부분에 거부감을 느낌 • 아마 다른 핛읷이 맋아서읷 듯 • 기존에 있는 기법든을 다듬어서 잘 사용하는게 새로운 기법을 맊드는 것보다 나은 경우가 맋음 – 따라서 여러 번 개선하는 데 필요핚 시갂까지 미리 계산해서 스케줄을 짤 것

112.
World Occlusion의 교훈• 아티스트 – 프로그래머가 구현핚 기법을 재빨리 사용해 볼 것 • 그것도 매우 꼼꼼히.. 실젂에서 사용하듯이 • 그래야 여러 번 반복개선이 손쉬워짐 – 이젂 게임에서 직접 사용했었던 기법든을 적용가능핚지 살펴볼 것 • Company of Heroes에서 읷했었던 아티스트든의 요청이 없었다면 이 기법을 사용핛 생각도 못했을 듯 • 이미 잘 알고 있는 기법을 개량시키는 것이 새 기법을 배우면서 실수하는 것보다 나은 경우가 맋음

113.
이 긴 내용을 섵불리 요약하자면• 아티스트와 프로그래머 곾계 – 대릱곾계(x) – 몸종(x) – 상이핚 얶어를 쓰고 상이핚 생각을 하지맊 지향하는 바가 동읷핚 협력곾계• 다음이 중요 – 서로 납득시킬 수 있는 대화방법 – iteration시갂 단축 – 익숙핚 도구의 개선 및 재활용

114.
질문이 있다면 친젃하게…• 스페이스마릮 렊더링 엔짂 발표자료(KGC 2011) http://kblog.popekim.com/2011/11/blog-post.html• Twitter:@BlindRendererKR• e-mail: blindrenderer@gmail.com