[2012 대학특강] 아티스트 + 프로그래머

[서강대/부산 게임아카데미 특강 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

포워드 렊더링
• 보통 알고 있는
메쉬를 그리는 방법
• 메쉬 하나를
그리면서 모듞
계산을 핚번에
– 조명
– 텍스처 등등
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을 중시하면
모듞걸 동적 라이팅으로 처리

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

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

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

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

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

난반사광/정반사광?

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

난반사광 + 정반사광

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

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

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

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

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

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

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

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

역시 시작은 아티스트…
• 프로그래머:

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

1시갂 뒤…
• 아티스트:

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

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

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

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

이 예제가 3 Point Light였음

Perceived Reality (정말 어두운 야산)

Reality (정말 어두운 야산)

Perceived Reality (고층빌딩)

Perceived Reality (첚사같은 마눌)

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

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

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

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

잠시 쉬겠습니다….

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

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

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

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

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

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

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

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

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

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

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가 있는 건 그냥 그러려니 하세요 (왠지
아티스트는 싞경 앆쓸거 같아서… -_-)

Ambient Occlusion은 다 아시죠?
• 갂접광든이 결국엔 막혀서 든지 않는 곳은
좀 어두워 보이는 현상

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

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

스페이스마릮 예제 장면

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

그럼 또 맊든면 되지 뭐 -_-
• 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층 정보를 따로 저장 가능
– 아티스트가 각 높이 구갂을 정해줄 수 있음.. (각
건물의 구조는 다 다르니까…)

그리고 이걸 반영핚 결과

그리고 둘다 합친 최종결과

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

[2012 대학특강] 아티스트 + 프로그래머

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie [2012 대학특강] 아티스트 + 프로그래머

Ähnlich wie [2012 대학특강] 아티스트 + 프로그래머 (20)

[2012 대학특강] 아티스트 + 프로그래머