1. Screen Space Decals
in Warhammer 40,000: Space Marine
Pope Kim
Senior 3D Programmer
Square Enix / Eidos Montreal
Relic Entertainment / THQ Canada (past)
2. 작년 KGC 발표 이후….
스페이스마린의 렌더링 기법
데니엘 박사님과 2시간 공동발표
6. 작년 KGC 발표 이후….
여기까진 농담… (잠좀 깨셨죠? -_-)
스페이스마린의 렌더링 기법 - 2시간짜리
슬라이드
129장 = 1분에 한장하기에도 벅찼….
http://kblog.popekim.com/2011/11/blog-post.html
말도 엄청나게 빨리 해야했음
증거 동영상:
http://www.kocca.kr/knowledge/seminar/1775011_3306.html
(이라고 했지만 사실은 원래 말을 빨리 함 -_-)
8. 국내외 개발자들의 추가발표 요청 내용 2개
렐릭의 파티클 시스템
데니엘 박사님의 KGC 2012 발표
“모두가서 보세요!” 라고 하고 싶지만 어제 이미 발표 -_-
그리고 스크린 스페이스 데칼
이미 발표자 본인이 Siggraph 2012에서 발표했음
지금 KGC 2012에서 발표하는 것도 시그래프 발표에 기반
그리고 올해는 좀더 여유롭게 발표
시간도 1시간 뿐
슬라이드 수도 112장 밖(?)에 안됩니다…..
9. 올해는 시간이 좀 여유로우니 발표자 소개도…
이름: Pope Kim (김포프)
경력(시니어 3D 프로그래머)
스퀘어 에닉스(아이도스)
몬트리올 (2012 - )
렐릭 (THQ) (2008 - 2012)
캡콤 밴쿠버 (2006 - 2008)
기타 등등
34. 2. UV를 잘~ 계산하는 법
(-4.5, -3.2) (3.4, -3.2)
(0, 0)
(1, 1)
(-4.5, 4)
(3.4, 4)
35. 하지만 여전히 문제가…
1. 폴리곤 수를 늘리면 정점수가 늘어나니…
– 정점들을 훑는데(iterate) 시간이 더 걸림
– 메모리 사용량 증가 (콘솔에서 특히 치명적… 512MB 들어는 봤나
-_-)
2. 쓸데없이 래스터라이제이션 하는 픽셀이 늘어나니
성능저하
– 텍스처 가장자리(edge)가 완전투명해야함
– 메쉬가 복잡하면 UV 계산이 너무 어려움
37. 그래도 난 천재니까?....
그래서 이 모든 문제들을 해결하려고 Screen Space
Decal이란 기막힌 기법을 만들어 냈겠죠?
38. 그래도 난 천재니까?....
그래서 이 모든 문제들을 해결하려고 Screen Space
Decal이란 기막힌 기법을 만들어 냈겠죠?
그.럴.리.가….
39. 난 천재니까?....
그래서 이 모든 문제들을 해결하려고 Screen Space
Decal이란 기막힌 기법을 만들어 냈겠죠?
그.럴.리.가….
사실 이전 방법이 만들기 너무 복잡해보여서….
하지만 SSD가 저 문제들을 해결한건 사실..^_^
40. 스크린 스페이스 데칼 (SSD)
지난 1~2년간 다른 개발자들이 비슷한 기법을 소개했음
Deferred Decals (Jan Krassnigg, 2010)
Volume Decals (Emil Persson, 2011)
SSD는 그 전에 개발했으나 실제 알고리듬은 매우 비슷함.
(이름이 좀더 멋질뿐…. -_-)
따라서 알고리듬을 가볍게 살펴본 뒤
스페이스마린에서 SSD를 사용한 방법과 발견한
문제점들, 그리고 그 해결책에 더욱 초점을 둘것임
41. 스페이스마린에서 SSD를 쓴 곳들
파티클 효과(FX)에 국한하지 않음
말 그대로 화면의 절반이 SSD:
벽에 끈적하게 들러붙은 핏자국
벽에 조각한 석상
콘크리트 바닥이 탄 자국
오크들이 벽에 페인트로 낙서질 해 놓은것
바닥에 쌓여있는 돌더미들
총알구멍
폭발자국
......기타 등등등
특히 배경 아티스트들이 너무너무 좋아했어요~~~
44. 구현 디테일
1. SSD를 제외한 메쉬들을 화면에 그림
2. SSD 상자를 그림(rasterization)
3. 각 픽셀마다 장면깊이(scene depth)를 읽어옴
4. 그 깊이로부터 3D 위치를 계산함
5. 그 3D 위치가 SSD 상자 밖이면 레젝션(rejection)
6. 그렇지 않으면 데칼 텍스처를 그림
52. This 5. SSD 상자밖이면, 리젝션
slide has a 16:9 media window
밖
안
밖
53. 5. SSD 상자밖이면 리젝션
• 간단히 뷰공간의 위치를 SSD 상자의 물체공간으로 변환
• 위치가 0.5 보다 큰 픽셀은 상자 밖에 있는 것
position = mul(scenePosView, InvWorldView);
clip(0.5f - abs(position.xyz));
54. This 6. 상자안이면 데칼을 그림
slide has a 16:9 media window
// 데칼 텍스처의 UV
float2 uv = position.xz;
uv += 0.5f;
70. 아티스트에게 자유를….
아티스트는 *.ssdecal
파일을 만듬 (사실 그냥
XML 파일)
레벨 에디터에서,
SSD를 끌어다 놓음
이제부터 WYSIWYG.
각 인스턴스별로 수정도
가능
71. 문제점들 & 우리의 해결책
1. 알파 블렌딩
2. 움직이는 물체들
3. 옆면이 늘어나요…. ㅜ.ㅜ
4. 짤린(clipped) 데칼
5. 성능
72. 1. 알파블렌딩 (법선)
• 컴바이너 패스에서 투명한 물체를 그리는 건 큰 문제없음
• 법선(normal)을 혼합 해야하는 Gbuffer가 문제
– 첫 구현: 알파테스트 사용
– 거의 마지막 구현: Crytek의 Best Fit Normal 기법 + 알파블렌딩
– 하지만 3 개월 뒤, 우리가 Best Fit Normal을 구현한 코드에서 버그
발견. 이전에 쓰던 법선저장법과 동일했음.. -_-
– 그래도 법선 블렌딩이 이상하다고 불평하는 아티스트가 없었으니
시각적으로 문제가 없는 것… 그래서 그냥 그대로 뒀음…
– 수학적으론 틀림… 하지만 게임개발에선 아티스트가 왕. 그러니
틀리든가 말던가…. (올해도 디스 당할지도…. -_-)
73. 1. 알파블렌딩(Spec Power)
• Gbuffer의 알파채널에 Specular Power를 저장
• 일반적인 알파블렌딩 사용불가
– SSD 셰이더의 알파 출력(output)값은 RGB(법선) 혼합에 사용
– 해결책: Blend Factor!
AlphaBlendFunction = BlendFunction.Add;
AlphaSourceBlend = Blend.BlendFactor;
AlphaDestinationBlend = Blend.InverseSourceAlpha;
BlendFactor = ssd.SpecularPower / 255.0f;
74. 1. 알파 블렌딩(Spec Power)
This slide has a 16:9 media window
83. 3. 옆면이 늘어나요… ㅜ.ㅠ
• SSD 상자의 투영면이 완전히 충돌하는 메쉬안에
들어가지 않을 때 발생하는 문제
• 처음발견한 문제, 여러가지 시도를 한 문제
• 하지만 데칼상자의 투영방향과 Gbuffer의 법선방향이
이루는 각이 어느정도 커지면 그냥 단순히 리젝션
87. 3. 옆면이 늘어나요… ㅜ.ㅠ
• 단순 리젝션 외에 우리가 시도해본 방법들
– 데칼상자의 방위와 정점법선이 이루는 각이 커짐에 따라 데칼이
서서히 사라지게 함: 둥근 파이프등에서 정말 안이쁨 -_-
– 데칼상자의 방위와 Gbuffer 법선이 이루는 각이 커짐에 따라
데칼이 서서히 사라지게 함
• 이미 만들어놓은 데칼 텍스처들을 너무 흐리게 만들었음
• 노이즈가 많이 낀 gbuffer에서 아티스트들이 단순 리젝션을 더 선호했음
• 처음부터 이 방법을 썼으면 썼을지도… 여러분 게임에서 시도해 볼만한 가치는 있음
88. 4. 짤린(clipped) 데칼
• 배경아트 데칼에서는 별로 문제가 아님
– 이미 배경 아티스트들이 성능상의 이유로 얇은(thin) 데칼을 사용
• 파티클에서 큰 폭발이 일어날때 종종 발생하는 문제
– 카메라가 데칼상자 안에 들어가면
– 픽셀이 래스터라이제이션 조차 안되서 생기는 문제
93. 4. 짤린 데칼(해결책)
• 카메라와 데칼이 충돌하면
• 뒷면(backface)을 대신 그림. 하지만 깊이 테스트 방향을
뒤집어야 함
• 하.지.만… 성능이… 마구 떨어져요….
– 깊이 테스트를 뒤집으면 계층적 깊이(Hi-Z)또 꺼져요.. ㅜ.ㅠ
– 하지만 파티클 데칼에서만 문제가 되고, 이것에 대한 상상도못할
엄청난 해결책꼼수가 있음 (뒤를 보세요)
94. This 4. 짤린 데칼16:9 media window
slide has a (뒷면 그리기)
95. This 4. 짤린 데칼16:9 media window
slide has a (뒷면 그리기)
96. 5. 성능
• 어차피 리젝션할 픽셀이라면 래스터라이제이션 조차
안하는게 좋음
• 깊이 테스트 방향을 뒤집어서 Hi-Z도 끄는걸 피해야 함
• 간단히 말해 데칼을 매우 얇게 만들 것
– 배경아트 데칼은 매우 쉽게 해결가능 = 노가다.... -_-
– 파티클 데칼들은 노가다가 거의 불가능…
• 이런 방침을 따른 스페이스마린은 파티클 데칼이 완전히
미쳐 날뛰지 않는한 언제나 30+ FPS로 실행 ^_^
97. a 성능
This slide has5. 16:9 media window
이 데칼을 그리는 두가지 방법
98. a 성능
This slide has5. 16:9 media window
엄청 두껍게
99. a 성능
This slide has5. 16:9 media window
아니면 얇게
100. a 성능
This slide has5. 16:9 media window
픽셀셰이더를 이만큼 낭비
106. a 성능
This slide has5. 16:9 media window
이것!
오버레이로 숨겨요!
파티클로 발라요!
107. a 성능
This slide has5. 16:9 media window
이것!
오버레이로 숨겨요!
파티클로 발라요!
느려져도 눈치 못채는게 함정!
108. a 성능
This slide has5. 16:9 media window
이것!
오버레이로 숨겨요!
파티클로 발라요!
느려져도 눈치 못채는게 함정!
사실 이럴려고 한 건
아닌데…
덕분에 할일이 줄었..
109. Special Thanks
• 더이상 자기 직원이 아닌데도 발표를 허락해준 Relic
• 스페이스마린 렌더링 프로그래머들
• 아름다운 아트를 만들고, 렌더링 프로그래머를 맨날
괴롭혀준 아티스트들!
110. More Special Thanks
• 온갖 탄압을 받으면서도 꿋꿋이 게임을 만드시는 한국
현직 게임개발자분들과 지망생분들…
• 게임개발포에버 필자분들
111. 참조문헌
• ENGEL, W. 2009, Designing a Renderer for Multiple Lights –
The Light Pre-Pass Renderer. In ShaderX7: Advanced
Rendering Techniques, Charles River Media
• KAPLANYAN A. 2010, CryEngine 3: Reaching the Speed of
Light, Siggraph 2011
• KRASSNIGG, J. 2010. A Deferred Decal Rendering
Technique. In Game Engine Gems 1, Jones and Barlett
• PERSSON, E. 2011. Volume Decal. In GPU Pro 2, A K Peters