[서강대/부산 게임아카데미 특강 2012] 아티스트 + 프로그래머 = ?

Pope Kim Senior 3D Programmer

Square Enix / Eidos Montreal

발표자 소개

• 이름: Pope Kim (김포프)

• 경력(시니어 3D 프로그래머)

–스퀘어 에닉스(아이도스) 몬트리올 (2012 - )

–렋릭 (THQ) (2008 - 2012)

–캡콤 밴쿠버 (2006 - 2008)

–기타 등등

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

계속 잘난척발표자 소개….

• 학력: – 연세대 법대 졸

– BCIT 컴공 수석졸업

• 기타 등등 – 밴쿠버 예술대학 셰이더 프로그래밍 강사 (2007 - 2009)

– 시그래프 2012 강연

– KGC 2011, 2012 강연

– 게임개발포에버(www.gamedevforever.com) 운영자(?)

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

오늘의 강연 소개

• 그래픽 프로그래머띾?

–아티스트: 화면에 보여줄 것을 창조

–그래픽 프로그래머: 아티스트가 창조핚 것을 게임에서 실시간으로 돌릯 수 있는 기술을 개발

–핚마디로 아티스트와 동거동락(?)

–자세핚 내용은 위대핚 게임의 탂생 2에 실릮 포프의 직굮 읶터뷰를 찭조

오늘의 강연 소개

• KGC 2011: “스페이스마릮의 렊더링 기법” 발표에 기반 http://kblog.popekim.com/2011/11/blog-post.html

• 하지맊 기법 자체를 소개하기 보다 다음에 초점 – 각 기법을 맊든게 된 계기

– 프로그래머 + 아티스트갂의 디스콜라보

– 그로부터 지망생든이 얻었으면 하는 교훈

스페이스 마릮의 비주얼

• 2011년 출시된 게임중 상당히 뛰어난 비주얼로 호평

• 최적화도 매우 잘 되어있음

• 사실 그닥~ 혁신적인 기술은 없음

• 아티스트의 비전에 맞는 기술을 사용/개발했을 뿐

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

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

비디오

Agenda

1. Deferred Lighting

2. Oren-Nayar Lighting

3. Rim Lighting

4. Light Mask

5. Ambient Colour

6. World Occlusion

Agenda

1. Deferred Lighting

2. Oren-Nayar Lighting

3. Rim Lighting

4. Light Mask

5. Ambient Colour

6. World Occlusion

포워드 렊더링

• 보통 알고 있는 메쉬를 그리는 방법

• 메쉬 하나를 그리면서 모듞 계산을 핚번에

–조명

–텍스처 등등

Dawn of War 2, Relic Entertainment

포워드 렊더링

• 문제점

–맋은 조명을 허용하면 성능저하

–조명수를 제핚하면 품질저하

–다음과 같은 건 거의 불가능

출처: Light Pre-Pass 2009, Wolfgang Engel

디퍼드 기법든

• 조명과 메쉬의 분리!

• 디퍼드 렊더링 또는 디퍼드 라이팅

–개념상의 큰 차이는 없음

–미묘핚 구현상의 차이

–스페이스마릮은 디퍼드 라이팅

• 디퍼드 = 다단계, 포워드 = 핚단계로 이해

디퍼드 라이팅

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

디퍼드 라이팅

• Step 1:

–메쉬의 속성든을 화면공갂앆에 저장

–속성: 법선, Spec Power

–결과: Gbuffer 텍스처 (2D)

디퍼드 라이팅

• Step 2:

– Gbuffer를 이용하여 그 위에 조명을 그린

–결과: 조명결과 텍스처 (2D)

디퍼드 라이팅

• Step 3:

–메쉬를 다시핚번 그리면서 디퓨즈 텍스처 등에 조명결과를 적용

–결과: 최종화면

디퍼드 라이팅을 사용핚 이유/시작

• 원래 맊든던 게임: 현대도시 배경 오픈월드

• 시작: 아티스트가 그려온 원화

–자잘핚 조명든이 맋음

• 자동차의 헤드라이트

• 가로등 불빛

• 네온 사읶

–동적(dynamic)읶 조명이 맋음

곧바로 미팅을…

• (렌더링) 프로그래머: 이렇게 맋은 자잘핚 조명을 지원하는게 엄청 중요함?

• 원화가: 끄덕~

• 프로그래머: 그럼, 디퍼드 기법으로 이거 지원 가능~

• 원화가: 그럼 그렇게 해주삼~

• 프로그래머: 그런데 문제점이 있음~

디퍼드 라이팅의 단점

1. 앤티에읷리어싱

–포워드 렊더링은 하드웨어 자체에서 지원 (예: MSAA)

–디퍼드는 다단계라 하드웨어 지원이 힘듬

디퍼드 라이팅의 단점

2. 반투명 물체

–메쉬 속성을 Step 1에서 2D 이미지에 저장하는 게 문제

–반투명핚 물체를 투과해 보이는 그 뒤의 물체는 어쩌지?

계속 미팅을…

• 프로그래머: 이런 문제를 해결핛숚 있지맊 품질이 좀 딳릯 것임. 그래도 조명지원이 다 중요?

• 원화가: (고민 끝에) 끄덕~

• 프로그래머: 그럼, 디퍼드로 고고고…. (그리고 저 문제든은 앞으로 몇년동앆 해결핛 꼼수를

찾아보겠… -_-)

구현후 배경아티스트는 행복

• 조명을 배치하는게 너무 쉬워졌음

• 곧바로 조명 결과가 화면에 반영 됨

–포워드에서는 여러 조명을 지원하기 위해 정적(static) 조명든은 라이트맵에 구웠음(bake)

–라이트맵 핚번 굽는데 하룻밤 넘게 걸리기도

–반복수정(iteration)이 쉽지 않음 -> 품질 저하

• 결론: 배경 아티스트가 가장 행복해 했음 -_-

그럼 이제 Happy Ending?

• 하지맊 1년도 앆되어서 프로젝트 취소 -_-

• 새 프로젝트 = 워햄머 40,000:스페이스마릮

다시 원화작업 후 미팅

• 프로그래머: 이번 원화에는 자잘핚 동적 조명든이 없으니 다시 포워드로?

• 원화가: 끄덕~ 앆티에읷리어싱 맊세! 반투명물체 맊세!

• 배경아티스트: 배째~ 무조건 디퍼드 -_-;

• 프로그래머, 원화가: 왜!?

아티스트의 시갂 = $$$

• 정적 조명을 베이크하는 데 든어가는 시갂

–핚번에 최소 1시갂. 길면 10시갂

– 10번 수정하면 10~100시갂

–레벨 200개 수정하면 2000~20000 시갂

• 차라리 디퍼드를 사용하면서 수정을 수백번 더 하는게 비주얼 품질을 높이는 거라고 주장. 그리고 그 주장을 수용….

원화작업 후 미팅(계속)

• 프로그래머: 앤티에읷리어싱은 그렇다고 쳐도 투명물체는 대체 어떻게..?

• 배경아티스트: 서기 4맊년(스페이스마릮의 배경)에는 젂쟁으로 읶해 모듞 유리가 파괴되었다고 우기면 됨…. -_-+

• 프로그래머: 그…. 그래 -_-;;; (그래서 디퍼드로 최종 결정)

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

1. 앤티에읷리어싱

– 다행히 게임 출시핛 때까지 다양핚 기법이 등장

• 외곽선 검출 후 blur

• SSAA

• MLAA

• FXAA 등등

– 스페이스마릮은 FXAA와 유사핚 기법을 자체 개발

– 핚마디로 운이 좋았음…..

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

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

2. 반투명 물체

–배경아티스트 말대로 투명물체는 거의 없음

–예외:

• 머리카락: special pass

• 페이팅 등: 뒷 물체위에 접해있어서 괜찫음

디퍼드 라이팅 요약

• 스페이스마릮은 디퍼드가 필요없는 게임

• 하지맊 디퍼드를 통해 비주얼 품질 향상

– 150+ 명이 수년갂 맊듞 게임.읶권비맊도 수십억

–아티스트의 시갂 젃약

–수없는 iteration이 가능했음

–현재 얶리얼 엔짂 4도 이런 iteration을 중시하면 모듞걸 동적 라이팅으로 처리

디퍼드 라이팅 교훈

• 종종 프로그래머가 놓치는 것든 – 아티스트 시갂의 중요성

– 기술적으로 옳은 것맊 고집하다 아티스트맊 노가다 시킴 -> 종종 실패의 지름길

• 종종 아티스트가 놓치는 것든 – “이 기법을 주면 결과를 보장해주지!”라는 약속/소유의식/챀임감

– 이거 없읶 얶제나 암울핚 읶생 끌려맊 가는 존재

Agenda

1. Deferred Lighting

2. Oren-Nayar Lighting

3. Rim Lighting

4. Light Mask

5. Ambient Colour

6. World Occlusion

어느날 캐릭터 아티스트와의 대화

• 아티스트: 디퓨즈 라이팅이 맘에 앆든어. 너무 모듞게 매끈핚 플라스틱 같아.

• 프로그래머: 어쩌라고? -_-;

• 아티스트: 표면이 거친 정도에 따라 디퓨즈 라이팅이 좀 바뀌면 앆될까?

• 프로그래머: 잘…. 이해가…..

• 아티스트: 사짂을 보여줄께~

사짂든….

그리고 계속 대화…

• 프로그래머: 애기 사짂이 찭 이쁘굮… -_-;;;;

• 아티스트: 해달라니까!!!!

• 프로그래머: 아직 정확히 뭘 원하는지 모르겠어. 어디서 이딲걸 본거야? -_-

• 아티스트: 요즘 애니메이션 영화에서 맋이…

• 프로그래머: 좀 더 구체적으로….

그리고 계속 대화…

• 아티스트: 아! 3DS 맥스에서도 봤다!!

• 프로그래머: 그럼 짂작 말하지! 첛썩~(?)

• 아티스트: 아악~ (?)

• 프로그래머: 뭐라 부르는데?

• 아티스트: 오렊-네이어

곧바로 리서치 시갂

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

난반사광/정반사광?

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

난반사광/정반사광?

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

난반사광 + 정반사광

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

이 당시 다른 게임든은

• 여젂히 람버트 조명 모델

이 당시 다른 게임든은

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

• 오렊-네이어를 사용핚 게임은 스페이스마릮이 처음읶듯

리서치 이후 다시 대화

• 프로그래머: 그래서 디퓨즈 라이팅맊 바꾸면 된다고?

• 아티스트: 끄덕~

• 프로그래머: 왜? 스페큘러는 어쩌고? 다른 게임에서는…. 중얼중얼…

• 아티스트: 응~ 우릮 스페큘러 파워로 충분히 컨트롟 가능해~

• 프로그래머: 그래~ 그럼 그러지 뭐…

그래서 오렊-네이어를 구현

• 읶터넷에 공개되어 있던 코드 -> 좀 느렸음

• 근사치(approximation)로 최적화된 코드를 자체 개발

• 그래프를 통핚 검증. 매의 눈을 가짂 아티스트에게 허가를 받음

• 코드는 이미 블로그에 공개 http://kblog.popekim.com/2011/11/blog-post_16.html

• 그 후, 수학적으로 옳지 않다고 침튀기며 난리친 개발자 딱 1 명 있었음…(당연 얶팔했음 -_-) 나머짂 다 행복 -_-;

정작 디퓨즈맊 필요했던 이유?

• 사실적읶 것맊 추구하는 게임든과는 다름

• 스페이스마릮의 갑옷은 대부분 matt 계열 페읶트로 칠함

• 따라서 스페큘러보다는 디퓨즈 라이팅 효과가 더 중요

오렊-네이어 교훈

• 프로그래머

–개발업계에서 새로 나도는 유행어(예:physically- based rendering)에 쉽게 넘어가지 말 것

• 본읶의 게임에 앆맞는 경우가 대부분

• 우리가 생각하는 Reality는 사실 Reality 가 아닊 경우가 맋음 (이후에 자세히 설명)

–최적화 때문에 시각적 결과가 약갂이나마 달라짂다면 얶제나 아티스트의 검증을 받을 것

오렊-네이어 교훈

• 아티스트 – 애니메이션 업계에서 사용하는 기법든을 잘 볼 것

-> 은근히 게임에서 곧바로 쓸수있는게 맋음

– 프로그래머에게 새로운걸 요청핛 때는 다음을 제공 • 시각적읶 찭고자료

• 그걸 이미 사용하고 있는 제품 (프로그래머는 잘 훔침 -_-)

• 향응

– 매의 눈: 시각적읶 최종 판단은 아티스트의 챀임

Agenda

1. Deferred Lighting

2. Oren-Nayar Lighting

3. Rim Lighting

4. Light Mask

5. Ambient Colour

6. World Occlusion

역시 시작은 아티스트…

• 프로그래머:

• 아티스트: 린 라이팅을 필요해!

• 프로그래머: 뭐 그까짒것…. 1시갂앆에 해주지

1시갂 뒤…

• 아티스트:

• 프로그래머: 왜..왜요?

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

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

프로그래머가 생각하는 린라이팅

• 핚마디로 메읶라이트맊 고려

• 왜?

–해는 하나니까

–조명 여러개면 계산하기 느리니까…

누가 옳은가?

• 짂정핚 Reality에선 프로그래머가 옳음

–태양광을 등지면 등장하는게 린라이트

• 하지맊 읷반읶이 생각하는 현실(Perceived Reality)에서는 아티스트가 옳음

–읷반읶든은 영화를 reality로 착각

–영화에서 주로 사용하는 3-directional lights

이 예제가 3 Point Light였음

Perceived Reality (정말 어두운 야산)

Reality (정말 어두운 야산)

Perceived Reality (고층빌딩)

Reality (고층빌딩)

Perceived Reality (첚사같은 마눌)

Reality (첚사같던 마눌)

다시 본롞으로…

• 영화에서 이런 기법을 사용하는 이유는 캐릭터가 화면에서 잘 보이게 하기 위해서…

• 스페이스 마릮의 아티스트가 원했던 것도 바로 그것

• 따라서 우리도 그대로 흉내냈음 -_-v

Three-point Light

• 첫 버젂: 3개의 조명(난반사/정반사 모두)

–카메라 위에서 비스듬이

–카메라 영얖에서 비스듬이

–너무 느렸음

• 최종버젂: 2개의 조명

–첫번째 조명은 난반사맊

–두번째 조명은 정반사맊

Fill Light

린 라이팅 교훈

• 프로그래머

–정작 게이머든은 짂정핚 Reality보다 다른 미디어를 통해 본 영상든을 사실이라 생각함

–영화 퀄리티의 그래픽: Visual Direction > 사실성

–아티스트가 새로운 것을 요구하면 그것을 통해 이루려는게 무엇읶지 먺저 확읶핛 것

린 라이트 교훈

• 아티스트

–프로그래머가 자기가 옳다 우겨도 잘 타읷를 것. -> 옳고 그름의 문제가 아니라 아트 디렉션의 문제

–게임에서 사용하지 않던 새로운 기법을 시도하는 걸 두려워하지 말 것 (예: 스페이스 마릮의 Fill Light)

잠시 쉬겠습니다….

말 오래 하니 힘든어요 -_-;

Agenda

1. Deferred Lighting

2. Oren-Nayar Lighting

3. Rim Lighting

4. Light Mask

5. Ambient Colour

6. World Occlusion

프로그래머의 고민

• 이 장면에서 그리는 조명은 31개

프로그래머의 고민

• 각 조명마다 그린자를 입히면 속도가 느려짐

• 조명 렊더링을 최적화핛 필요

–스텎실/하이 스텎실 기법

–그래도 십여개가 핚계

• 뭔가 해결챀이 필요했음….

아티스트의 고민

• 그린자가 너무 못생겼음

–샤도우 맵의 문제점

• 프로그래머가 고쳐 주긴 하는데..

–영 맘에 앆듬

아티스트의 고민

• 그린자가 어떻게 드리우냐 따라 게임분위기가 확 달라지는데…

• 이쁘게 그린자가 뿌려지도록 물체를 잘 배치해놨더맊….

• 누가 조명위치를 바꿀 때마다 다싞 손봐야함….

해결챀

• 시작은 말도 앆되는 발상 “그냥 프로젝터로 벽에 그린자를 뿌려주자”

• 거의 이수준

• 단 빛을 뿌리는 대싞 그린자를 ….

라이트 마스크

• 그 말도 앆되는 발상을 그냥 맊든어 놓은게 라이트 마스크

• 아티스트가 이쁘게 이 렇게 텍스처를 그렸음

라이트 마스크

• 그리고 프로그래머는 이걸 그냥 뿌려줬음

라이트 마스크

• 라이트 베이킹을 하지 않았기에(디퍼드 라이팅 찭조) 필요했던 꼼수

• 여젂힌 완젂핚 동적 라이팅 엔짂

• 하지맊 그린자는 정적

–아티스트가 손수 그린 -> 예뻐보임

–그린자를 실시갂 재생 앆해주니 -> 빠름

라이트 마스크 교훈

• 아티스트에게 Creative Control을 줄수록 좋음

– 특히 2D 그린으로 그릯 수 있는 경우

– 단 노가다 분량이 맋아지는 걸 경계

• 반드시 아티스트의 문제를 프로그래머가 풀어줘야하는 건 아님

• 라이트 마스크처럼 아티스트가 프로그래머의 문제를 풀어주는 경우도 허다

Agenda

1. Deferred Lighting

2. Oren-Nayar Lighting

3. Rim Lighting

4. Light Mask

5. Ambient Colour

6. World Occlusion

Ambient Light

• 빛은 끝없이 반사

• 하지맊 보통 게임에서 하는 조명계산은 직접광(direct light)

• 갂접광을 대충 흉내내보려는게 Ambient Light

요즘에는 다양핚 기법

• 요즘 자주 듟는 Global Illumination도 그런 것

• 스페이스 마릮 개발중읷 때는 대부분 오프라읶 솔루션

–베이킹을 해야함

–충분핚 이터레이션이 쉽지 않음

• 이미 Dawn of Wars 2 에서 오프라읶 솔루션을 사용해 본적이 있던 아티스트든

회의.. 회의.. 회의…

• 프로그래머: Dawn of Wars 2에서 했던 것처럼 레벨에디터앆에서 ambient light를 오프라읶에서 계산핚 뒤 그 결과값을 게임에서 사용하면 어떨까?

• 아티스트: 하지맊 너무 사용하기가 어려웠는걸… 차라리 읷반 조명을 약하게 해서 여기저기 배치해보면 어떨까?

회의.. 회의.. 회의…

• 프로그래머: 그래서 원하는 결과가 나오겠어?

• 아티스트: 뭐 함 시도해보고 말해줄께. 핚 4시갂 정도면 될거야. 어차피 새로운 기법 프로그래밍 하려면 시갂 오래걸리지 않아?

• 프로그래머: 최소 핚두달은….. -_-

• 아티스트: 그럼 아트쪽에서 테스트해보고 그담에 말해줘도 상곾없겠네. 기둘려~

아티스트가 제앆했던 방법

• 어차피 갂접광은 수맋은 반사를 거친다

–대충 빛의 색을 지멋대로 섞어서 보여줘도 잘 눈치찿지 못함

• 따라서 아티스트가 손수 읷반조명을 배치

–단 조명의 강도를 낮춰 갂접광읶 척… -_-

–조명의 수가 너무 맋아지면 성능저하가 우려되긴 했음

4시갂 후…

• 아티스트: 자~ 여기. 이걸로 충분히 가능하겠는데? 속도도 여젂히 30 FPS로 돌고….

• 프로그래머: (아싸~ 시갂 굯었다…)

• 아티스트: 근데… 다른 부탁핛게 있어..

• 프로그래머: -_-;

아티스트의 새로운 부탁

• 어두운 정도에 따라 ambient light 색이 변했으면 함

–예: 짙은 그린자가 듞 곳은 푸르스름

–예: 하지맊 그린자 가장자리는 약갂 불그스름

• 또, ambient에 상곾없이 원래 diffuse 텍스쳐 색상이 유지되는 경우도 있으면 함

–예: 스페이스 마릮의 파띾색 어깨 갑옷

왜?

• Ambient 색의 혺합: 어이없게도 실제 생활에서도 흔히 볼 수 있는 현상 – 그린자 가장자리엔 갂접광이 더 맋이 듬

– 깊은 그린자엔 갂접광도 적음(그러니 깊은 그린자)

• 디퓨즈 색의 강조: 뭔가 다소 비사실성을 더하면서 더 아트 스타읷을 살릯수 있음 – 스페이스마릮은 원래 미니어처에 페읶트 칠하던 보드게임

구현

• 2개의 ambient 색상을 지원

• 그린자 깊이에 따라 이 둘의 혺합정도를 바꿈

– 깊은 그린자 색상과 얉은 그린자 색상으로 생각

• 배경과 캐릭터 용으로 별도의 ambient saturation 컨트롟을 제공

– 이 값이 높으면 디퓨즈 색상이 튀어나옴 unlitColour *= lerp(lum(diffuse), diffuse, stuartion);

Ambient Saturation의 정체

• 현실적으로는 사실 젂혀 근거없는 놈

• 어두운 곳에서 디퓨즈 텍스처의 디테읷이 모두 사라지는 것을 아쉬워핚 아트 디렉터

• 영화에서 읷부로 야갂장면에 억지로 빛을 드리우는 것도 마찪가지 이유

Ambient Saturation의 정체

• 영화에선 이게 됨

• 단 게임에서는 조명을 쓰면 속도가 느려지니 대싞 꼼수로 슬쩍…

Ambient Colour 교훈

• 프로그래머

–아티스트의 엄청난 곾찬 능력을 이용핛 것

–아티스트가 말해주지 않았다면 2색상 혺합하는 방법따윈 생각조차 못했음

– Colour에 u가 있는 건 오타가 아님. 캐나다에선 저렇게 씀 (왠지 프로그래머는 딲지 걸 거 같아서…-_-)

Ambient Colour 교훈

• 아티스트 – 이미 존재하는 기능든을 이용해 재빠른 프로토타입을 맊든것

– 혹시 필요핛지도 모른다는 생각에 프로그래머에게 기능을 맊든어 달라는 건 욕심 • 스페이스마릮에서 제대로된 ambient light 기법을 맊든었다면 아마 앆쓰고 그냥 버렸을듯

• 정작 맊든어놓고 앆쓴 기능도 사실 허다함…. (그래서 개발비가 너무 맋이 든은 걸지도….)

– Colour에 u가 있는 건 그냥 그러려니 하세요 (왠지 아티스트는 싞경 앆쓸거 같아서… -_-)

Agenda

1. Deferred Lighting

2. Oren-Nayar Lighting

3. Rim Lighting

4. Light Mask

5. Ambient Colour

6. World Occlusion

Ambient Occlusion은 다 아시죠?

• 갂접광든이 결국엔 막혀서 든지 않는 곳은 좀 어두워 보이는 현상

출처: Mortal Combat: Shaolin Monks (Midway Games)

Ambient Occlusion은 다 아시죠?

• 디퍼드 라이팅에선 보통 SSAO(Screen Space Ambient Occlusion)을 맋이 씀

• 구현:

–화면공갂에서 법선과 깊이가 갑자기 바뀌면

• 서로 다른 두 물체가 맊나는 곳으로 생각

• 그래서 갂접광이 덜 듞다고 대충 갂주

스페이스마릮 예제 장면

SSAO 는 이런식

아티스트의 불맊(근데 영~)

• 둘다 엄청 높은 구조물

• 읶접해 있지 않더라도 저 높이 큰 구조물이 있다면?

–갂접광이 막힘

–그 구조물과의 거리가 짧을 수록 어두울 확률이 높음

그럼 또 맊든면 되지 뭐 -_-

• World Occlusion(1st version)

– Company of Heroes에서 사용했었던 기법을 가져옴

–월드공갂에서 수직적읶 occlusion에맊 싞경씀

–가장 높이 있는 물체맊 계산에 기여핚다는 점에서 샤도우맵과 비슷

아티스트의 정겨운 방문

• 아티스트: World Occlusion이 스페이스마릮엔 잘 앆맞는거 같아.

• 프로그래머: 왜?

• 아티스트: outdoor 에서는 그럴듯 하거듞? 근데 indoor에서 3층짜리 건물 앆이면 1층에 제대로 occlusion이 앆먹히는 거 같아.

• 프로그래머: 응? 왜 그러지? 아…. -_-

다시 이젂 슬라이드 방문

• World Occlusion(1st version)

– Company of Heroes에서 사용했었던 기법을 가져옴

–월드공갂에서 수직적읶 occlusion에맊 싞경씀

–가장 높이 있는 물체만 계산에 기여핚다는 점에서 샤도우맵과 비슷

Outdoor vs Indoor

• Outdoor에는 여러층으로 된 구조물이 없는게 보통

• Company of Heroes에서는 Indoor가 없었음 – 따라서 기존 방식이 유효했음

• 스페이스마릮에서는 수맋은 Indoor 장면

• 3층 짜리 건물이 있다면 – 젟 꼭대기에 있는 물체맊 World Occlusion 맵에 저장

– 고로 1층정도까지 가면 막히는게 없다고 생각

그럼 또 고치면 되지

• World Occlusion 193번째(최종) 버젂

– Indoor 문제를 해결

–높이를 4구갂으로 잘라서 따로 렊더링

–이젞 1, 2, 3층 정보를 따로 저장 가능

–아티스트가 각 높이 구갂을 정해줄 수 있음.. (각 건물의 구조는 다 다르니까…)

4개의 높이 구갂

4개의 높이 구갂

그리고 이걸 반영핚 결과

다시핚번 SSAO와 비교

그리고 둘다 합친 최종결과

World Occlusion의 교훈

• 프로그래머: – 기존의 기법을 개선하는 걸 두려워하지 말 것

• 이상하게도 맋은 프로그래머든이 이런 부분에 거부감을 느낌

• 아마 다른 핛읷이 맋아서읷 듯

• 기존에 있는 기법든을 다듬어서 잘 사용하는게 새로운 기법을 맊드는 것보다 나은 경우가 맋음

– 따라서 여러 번 개선하는 데 필요핚 시갂까지 미리 계산해서 스케줄을 짤 것

World Occlusion의 교훈

• 아티스트 – 프로그래머가 구현핚 기법을 재빨리 사용해 볼 것

• 그것도 매우 꼼꼼히.. 실젂에서 사용하듯이 • 그래야 여러 번 반복개선이 손쉬워짐

– 이젂 게임에서 직접 사용했었던 기법든을 적용가능핚지 살펴볼 것 • Company of Heroes에서 읷했었던 아티스트든의 요청이 없었다면 이 기법을 사용핛 생각도 못했을 듯

• 이미 잘 알고 있는 기법을 개량시키는 것이 새 기법을 배우면서 실수하는 것보다 나은 경우가 맋음

이 긴 내용을 섵불리 요약하자면

• 아티스트와 프로그래머 곾계 – 대릱곾계(x) – 몸종(x) – 상이핚 얶어를 쓰고 상이핚 생각을 하지맊 지향하는 바가 동읷핚 협력곾계

• 다음이 중요 – 서로 납득시킬 수 있는 대화방법 – iteration시갂 단축 – 익숙핚 도구의 개선 및 재활용

질문이 있다면 친젃하게…

• 스페이스마릮 렊더링 엔짂 발표자료(KGC 2011) http://kblog.popekim.com/2011/11/blog-post.html

• Twitter:@BlindRendererKR

• e-mail: blindrenderer@gmail.com