All about productivity - since 2003
by kimsama
아래 포스트 올린 김에 하나 더.
원래 비슷한 주제로 묶어서 공부하면 효과가 배가 되는데, 그런 의미에서 이번에는 Deferred Shading 관련한 내용(기초적인 내용으로 )을 정리해 보았습니다.
Deferred Shading에 대해서 잘 모르는 분들은 우선 이전 포스트 내용을 한번 쓰윽 흝어만 보고 GPG6의 "Fast Per-Pixel Lighting with Many Lights" 를 먼저 읽어 볼 것을 권합니다. GPG6의 이 글의 내용은 Deferred Shading 사용시 이 방법의 단점을 극복할 수 있는 다양한 기법들을 소개하는 것이 본 내용지만 글 앞부분에는 Deferred Shading에 대한 내용이 잘 정리가 되어 있어 다른 글에 소개된 내용보다 훨씬 이해가 쉽고 빠릅니다. 다음으로 GPU Gem 2의 "Deferred Shading in STALKER" 와 GPU Gems3의 "Deferred Shading in Tabula Rasa"에 소개된 를 읽으시면 실제 게임에 적용된 사례들이므로 실제 적용시 이 방법의 장단점에 대한 감을 잡을 수 있습니다.
(순서대로 보시길)
1) Game Programming Gems 6, Fast Per-Pixel Lighting with Many Lights
2) GPU Gems 2, "Deferred Shading in STALKER"
3) GPU Gems 3, "Deferred Shading in Tabula Rasa"
구글에서 Deferred Shading으로 검색만 해보아도 굉장히 다양한 자료들이 나와서 어느 것부터 봐야 할 지 당황스러울 수도 있습니다만, 이 순서로 정리하시면 어렵지 않게 가닥은 잡을 수 있습니다.
그리고 마지막으로 정리 차원에서 실제 예제로 구동되는 샘플을 하나 보면 더욱 좋겠죠. ^^
http://www.defragdev.com/
이제 여기까지 보셨다면 이전 포스트의 내용 중에서 Kill Zone2의 프리젠테이션 자료나 아니면 다른 변형된 방법들에 대한 링크된 내용들이 가볍게 쓱쓱 이해될 겁니다...아마도 ^^
# by | 2008/10/30 11:03 | Development | 트랙백 | 핑백(2) | 덧글(1)
Nebula2 도큐먼트
Nebula Device 관련 문서입니다.
일전에 언급한 6월 경에 진행했었던 게임산업진흥원 게임아카데미의 'Open source Game engine - Nebula Device' 직무 교육 과정에서 사용되었던 문서의 일부입니다.
돌이켜 보니 Nebula 커뮤니티 활동도 어언 8년째더군요. 그래서 그 동안 정리해 둔 글이나 블로그에 올린 글들, 자료들을 틈틈히 정리하고 있습니다.
아직 정리가 미흡해서 다듬을 부분이 많은 알파 버전 정도로 생각해 주시기 바랍니다. 앞으로 정리되는대로 새로운 버전들도 공개할 예정입니다.
그리고, 보시고 도움이 되셨다고 생각하시면 아래 사이트의 광고들을 한번씩 클릭해 주시면 고맙겠습니다.
http://kimsama.blogspot.com
구글에서 협찬 받은 광고비는 어려운 이웃들을 위해서 사용할 예정입니다. ^^
(혹 문서 중에 ???로 깨어진 글자가 있을 수 있습니다. Google Doc에서 한글을 이탤릭체로 변경한 다음 문서를 pdf 포맷으로 변환할 때 발생하는 버그입니다. 이 버그 외에 발견하신 오탈자가 있으면 알려 주시면 고맙겠습니다)
보시고 의문나는 점에 대한 질문이나 기타 의견들 열렬히 환영합니다. 트랙백도 좋고 메일 보내시고자 하는 분들은 kimsama에뜨hotmail.com으로 보내 주시면 됩니다.
문서의 모든 저작권은 저에게 있으며 무단전재 및 복사를 금지합니다.
# by | 2008/08/26 19:10 | Nebula Device | 트랙백 | 핑백(2) | 덧글(12)
아시는 다른 Nebula 관련 페이지를 있으면 알려 주세요.
# by | 2008/08/25 22:38 | Nebula Device | 트랙백 | 덧글(1)
이 단순해진다면 좋겠지만 실상은 더욱 복잡해진 것이 현실입니다. 예를 들어 그래픽 하드웨어가 발달하면서 더욱더 실제와 같은 렌더링을 원하게 되었는데 이렇게 요구되는 렌더링 연산을 위해서는 더욱 많은 수의 데이터와 이에 대한 처리가 필요해졌습니다. 처리해야 할 일들의 종류도 많아졌고 더욱 복잡해졌다는 말입니다. 처리해야 할 데이터가 더욱 많아졌다는 사실은 이를 위해 요구되는 개발자의 수도 더욱 많아 졌다는 것을 의미하며 이것은 다시 개발비의 상승으로 연결 됩니다. 이렇게 보면 오히려 하드웨어의 발달이 프로덕션 파이프라인(Production Pipeline)을 더욱 복잡하게 만들고 있다는 것을 알 수 있습니다. 그래서 과거 어느 때보다도 효율적인 개발을 위한 툴의 중요성이 부각되는 때인것 같습니다.| 현명한 프로그래머의 우선순위(Smart Coder Priorities) 제가 개발자들과 하기 꺼려하는 이야기중에는 다음과 같은 것들이 있습니다. "이봐 밥, UberGameSoft사 일은 잘 되어 가는가?" "이봐 톰, 잘 되고 말고. 나는 멋진 HDR 시스템을 구현하고 있는 중이고, 짐(Jim)은 굉장한 물리 엔진을 구현하고 있고, 프랭크는 놀라운 포스트-프로세싱 효과를 구현했지." "훌륭하군, 그럼 자네들은 이제 게임을 구현할 차례겠군." "그렇긴 한데 말야, 아직도 전체 익스포트 파이프라인에 문제가 있어, 리소스들을 게임 내로 삽입하는데 애를 먹고 있다네." 이 시점에서 보통 저는 그들을 향해 낄낄거리며 다음 블로그를 포스팅할 준비를 합니다. 그런데 말입니다... 우리 같은 엔지니어가 가지고 놀기 좋아하는 멋지거나 혹은 괴짜스러울 만큼 훌륭한 것들이 많이 있습니다. 또 이런 것들 중 몇몇은 GDC에서도 돋보이는 훌륭한 발표거리가 되기도 합니다. 그러나 이 모든 것들이 이제 이야기할 것에 비하면 전혀 중요하지 않습니다. 이것은 바로 게임을 출시하는데 필요한 것들입니다. 이제는 팀 크기는 50~150명에 이르고 개발 기간은 2년에서 4년이 소요되고 있습니다. 이것은 큰 예산입니다. 우리가 진행하는 프로젝트에는 모두가 효율적으로 일할 수 있다는 것을 확신하게 할 만한 현명한 프로그래머가 필요합니다. 이 현명한 프로그래머란 바로 툴 프로그래머입니다. 네, '툴' 말입니다. 무슨 지저분한 소리를 하는 것 처럼 저를 쳐다보지 마십시오. 문제는 우리 중 대다수가 여전히 베드룸 해커(게으른 프로그래머라는 뜻인듯)라는 것입니다. 숨길 필요는 없습니다 - 솔직한 것이 좋잖아요. 하지만 그만큼 두려운 단어를 떠올릴 수 있어야 합니다. 바로 '관리'라는 단어 말입니다. 하지만 우리는 평균 이상으로 똑똑하다고 자부할 수 있기 때문에 PHB 관리 말고도 훌륭한 관리 방법을 사용할 수 있습니다. 그리고 그것은 데이터에 대한 관리가 아닐 뿐만 아니라 사람에 대한 관리도 아닙니다. 자신이 하는 일을 좋아하고 또 자신과 함께 일하는 사람들을 좋아하는 사람들의 경우 그들 자신도 스스로 잘 관리하는 것이 일반적입니다. 문제는 그들 사이에 데이터가 끼어 들어 그들이 같은 데이터에 연관되는 일이 만들어지는 것입니다. 이제 명백하게도 그것은 증거가 충분하지 않습니다. 그런데 사람들은 의존 관계가 명확한 것만을 다룰 수 있다는 것입니다. 마치 여러분이 캐릭터가 리깅(rigging)이 제대로 되어 있어야지 애니메이션을 할 수 있는 것 처럼 말입니다. 문제는 바로 의존관계가 명확하지 않다는 것입니다. 프로그래머인 우리는 그 시스템을 작성한 사람들이기 때문에 우리에게는 그 문제가 명확합니다. 안타까운 것은, 시스템을 만드는 가장 쉬운 방법이라는 것이 필요한 모든 데이타를 한 번에 다 준비한 다음에 전부 다 후처리 작업(post-processing)용 큰 깔때기에 쑤셔 넣고 거기에서 DVD를 떠서 시장에 내 놓는 것입니다. 물론 이런 짓을 했다가는 망하는 것은 불보듯 뻔한 일일 것입니다. 이렇게 하는 대신에 우리는 의존 고리들에 대해서 심사숙고 해 보아야 합니다. 그리고 어떻게 한 작업자가 변경한 것이 다른 사람의 작업에 영향을 끼치지 않도록 할 것인지와 관련된 것들을 동시에 작업하더라도 (서로) 망치지 않도록 함으로써 사람들이 동시에 작업할 수 있는 방법에 대해서 심사 숙고해 보아야 합니다. 이것은 프로그래머가 안고 있는 또 다른 큰 고민거리인 병렬 처리(parallel processing)와 거의 흡사한 문제입니다. 우리 모두는 병렬 처리가 매우 그리고 굉장히 어렵다는 것을 잘 알고 있습니다. 그래서 우리가 가장 현명한 프로그래머를 그 문제의 해결에 투입하는 것 처럼 툴도 마찬가지입니다. 심지어는 이것은 더욱 큰 병렬 처리에 대한 도전입니다. 게다가 이 문제의 경우에는 다른 병렬 처리의 주제-예를 들어 '물리 연산을 더 빠르게 하는 것'-처럼 잘 정의되어 있지도 않습니다. 왜냐하면 게임을 시작한 후 절반이 지나서도 실제로 (프로젝트가)어디로 가고 있는지가 분명하지 않기 때문입니다. 그래서 저는 이 문제들에 대한 것들이 머리 속에 정리되면 더 많은 포스팅을 할 생각입니다. 그러나 제가 가장 지적하고 싶은 것은 예전 처럼 그래픽스 기술을 가진 천재 프로그래머가 모든 문제를 해결하던 시대는 갔다는 것입니다. 쉐이더는 그렇게 작성하기 어려운 기술이 아닙니다. HDR은 자세하게 설명된 책이 있으면 충분히 해결할 수 있는 문제이고 그림자는 다소 고통스러울지 모르겠지만 그렇다고 근본적으로 게임을 만들거나 혹은 게임 자체가 만들어지는 것을 방해할만큼 큰 문제는 아닙니다. 하지만 훌륭한 리소스 관리의 문제는 다른 한편으로 출시와 파산의 차이점을 의미할 수도 있습니다. 그것은 새로운 형태의 천재 프로그래머가 관심을 집중해야 할 필요가 있는 것입니다. |
위의 글은 이제는 컨텐츠 양의 증가와 더불어 개발이 더욱 복잡해졌기 때문에 필요한 개발자의 수도 늘어났고 개발자의 수가 증가하면 당연히 이에 대한 관리도 힘들어 지지만 이보다 더 큰 문제는 개발자와 개발자 사이의 처리 프로세스가 복잡해지기 때문에 필연적으로 개발이 지연될 수 밖에 없는데 이를 해결하기 위한 가장 중요한 방법이 툴이므로 툴의 중요성이 그 어느 때보다 두드러지는 때다라는 정도로 요약할 수 있겠습니다.
그런데 대개의 경우 툴 작업을 시키면 얼굴에서 미소가 사라지는 것이 보통인 것 같습니다 - 툴 이야기 꺼내면 툴툴 거리죠. ^^ 그리고 경력이 많을 수록 이런 현상은 더욱 두드러지는 것이 보통입니다. Tom이 자신의 포스트에서도 툴 이야기를 할 때 dirty word라고 언급한 것으로 보아 그쪽도 우리와 거의 차이가 없어 보이는 것은 매한가지인듯 합니다. 하지만 툴의 중요성을 실감하고 또 작업에 있어 효율적인 방법을 찾는다면 현명한 프로그래머와 성공적인 - 동시에 즐거운 - 게임 개발이라는 두 마리 토끼를 동시에 잡을 수도 있습니다. 그래서 툴 프로그래밍을 할 때 참고할 만한 몇 가지에 대해서 시간이 나는대로 지면에 옮겨 볼까 합니다.
(계속)
# by | 2008/06/03 19:02 | Development | 트랙백 | 핑백(3) | 덧글(3)
# by | 2008/04/13 23:29 | 트랙백 | 덧글(1)
멀티 코어 프로그래밍
서론
현재 출시된 대부분의 신형 CPU들은 두 개 이상의 CPU를 내장한 멀티 코어 CPU가 주종을 이루고 있다. 이는 단일 코어에서 더 이상 코어 클럭을 이용해서 성능을 올리는 방법으로는 한계에 도달한 것이 그 이유이다. 이렇게 복수개의 코어를 사용하는 CPU의 등장은 게임 개발에도 큰 영향을 미치고 있는데 이는 PC 플랫폼에서보다 XBOX360[1], PS3[2] 등과 같은 비디오 게임 콘솔 플랫폼에서 더욱 두드러진다. 마이크로소프트사의 XBox360은 내부에3개의CPU가 각각2개의 하드웨어 쓰레드를 가지고 있어 총6개의 하드웨어 쓰레드가 작동하도록 되어 있으며Sony Computer Entertainment의PlayStation3는 하나의 코어에8개의SPE가 있는 형태로 구성이 되어 있다.
이러한 하드웨어 환경에서는 실제 하드웨어가 제공하는 최대한의 성능을 끌어내기 위해서는 제공하는 코어들을 이용해서 멀티 쓰레드를 사용하는 구조로 게임 엔진을 구성을 해야 한다.
이 글에서는 게임 엔진에서 멀티 코어 프로그래밍을 응용할 수 있는 부분에 대해서 살펴 보고 멀티 코어 프로그래밍의 모델, 그리고 멀티 코어를 이용하는 게임 엔진 설계시 고려해 야 할 점에 살펴 보게 된다.
멀티 코어 프로그래밍 모델
멀티 코어를 이용한 게임 프로그래밍은 사실 새로운 개념은 아니다. 이미CPU와GPU 두 개의 코어를 이용해서 프로그래밍하고 있으므로 실제로는 게임 프로그래밍의 경우 멀티 코어 프로그래밍을 하고 있다고 볼 수 있다. 여기에서는CPU의 멀티 코어에 대해서 살펴 보게 될 것이다. 우선 멀티 코어는 게임에 다양하게 이용할 수 있는데 예를 들어 게임 내의 길찾기에 응용하는 방법이 있다.
하나의 코어에서는 길찾기에 사용되는 네비게이션 메쉬를 읽어 들이고 길찾기를 위한 프리프로세싱을 수행하면서 동시에 응용 프로그램의 다른 코어에서는 이를 이용해서 계산된 결과를 가지고 게임의 길찾기를 수행하는데 사용할 수 있다.
길찾기의 또 다른 예로 동시에 여러 개의 에이전트에서 길찾기를 요청하는 경우에 게임 전체 프레임이 떨어지는 경우가 발생할 수도 있는데, 이러한 경우에 외부 스케쥴러를 이용하는 방법이 있다. 외부 스케쥴러에서 길찾기를 수행할 때 임의의 길찾기 요구에 대한 응답 시간이 매우 긴 경우가 발생할 수도 있는데 이 때 해당 프레임의 응답을 기다린 후에 처리하게 되면 프레임 드랍이 발생하게 되지만 다른 코어에서 외부 스케쥴러를 실행하여 길찾기를 수행하게 되면 프레임에 지장을 주지 않고 실행할 수 있게 된다.
그 외 아래 그림에 나와 있는 예로 애니메이션에 사용하는 방법도 있다.
그림에서 물리엔진, 애니메이션 엔진은 개별 서브 시스템으로 별도의 쓰레드로 작동된다. 
이 외에도 멀티 쓰레드를 게임에 이용하는 방법으로는 물리 시뮬레이션이나 렌더링 시스템 등을 별도의 분리된 쓰레드를 이용해서 처리함으로써 병렬 처리의 이점을 취하는 동시에 각 서브 시스템 간의 의존성을 최소화 시키도록 설계하는데 이용하는 방법도 있다.
멀티 코어 게임 엔진 디자인
멀티 쓰레드를 이용하는 경우 다양한 이점이 있지만 이를 게임 엔진을 개발하는 것은 어려운데 그 이유는 다른 응용 프로그램과 비교할 때 게임 엔진은 인공지능, 물리 시뮬레이션, 네트워킹, 애니메이션, 렌더링 시스템등과 같은 다양한 서브 시스템으로 구성이 되어 있어며 이들 서브 시스템은 서로 결합되어 작동되는 것이 일반적이므로 훨씬 복잡한 구조를 가지고 있다. 즉, 서브 시스템 간의 의존도가 높아서 멀티 쓰레드를 이용해서 병렬 처리하는 것이 어렵다. 또 다른 이유로는 게임 엔진이 이벤트 중심의 애플리케이션이라는 점이다. 게임은 사용자의 입력이나 네트워크를 통해 전송되는 패킷, 게임 내에 정의된 시나리오, 물리 시뮬레이션 등에 의해서 수시로 변경되며 서로 상호작용해서 작동되는 것이 보통이다. 이러한 이벤트들은 여러 개의 서브 시스템에서 처리하여 그 결과를 이용하게 되는데 이렇게 각 서브 시스템간에 데이터 정보를 공유해야 하는 경우 서브 시스템들을 독립적으로 병렬 처리하는 것이 어렵다.
그리고 게임은 실시간으로 작동되어야 하는데 게임 엔진은 매 프레임을 순차적으로 처리해서 렌더링 하는데 현재의 프레임은 이전 프레임에 의존적이기 때문에 프레임들을 병렬 처리할 수가 없다는 것도 게임 엔진에 병렬 처리를 이용하기가 어려운 이유 중의 하나이다.
이러한 문제점들을 해결하기 위해서 게임 엔진의 병렬 처리를 위한 여러 가지 멀티 쓰레드 모델들이 있는데 이들 모델 중에서 현재 가장 많이 사용되고 있는 모델로는 아래에 나와 있는 [3]비동기 함수 병렬 모델 (Asynchronous parallel model)이 있다.
<비동기 함수 병렬 모델(Asynchronous parallel model)>
이 모델은 게임 루프를 가지지 않으며 각각의 서브 시스템들이 고유의 수행을 하고 가장 최근에 갱신된 결과를 서로 공유해서 데이터간 동기화를 수행하는 것이 특징이다.
그림의 렌더링 과정을 보면 렌더링시 실제 물리 갱신 서브 시스템의 결과를 기다려서 사용하는 것이 아니라 이전 물리 연산 결과를 사용하므로 렌더링 서브 시스템과 물리 시뮬레이션 서브 시스템의 분리와 병렬화가 용이하며 다른 모델들에 비해 더 많은 병렬화가 가능하여 프로세서의 개수가 적은 경우에도 쓰레드 스케쥴링에 의해서 안정적인 성능 향상을 할 수 있다는 장점이 있다. 대신에 각각의 서브 시스템 작업 간에 타이밍에 의한 문제가 발생할 수 있다는 단점이 있다.
이러한 비동기화 함수 병렬화 모델은 각각의 동시 작업 간에 동기화가 적은 경우 효율적이며 전체 응용 프로그램에서 직렬화된 부분이 많아도 성능에 영향을 받지 않는다. 따라서 이 모델을 사용해서 성능을 극대화시키기 위해서는 가능한 동시에 많은 작업을 수행하는 것이 중요하며 또한 서브 시스템 간의 타이밍을 맞추기 위한 작업의 크기가 균등해야 한다.
멀티 쓰레드를 위해 고려해야 할 게임 엔진의 또 다른 측면 중 하나로 게임 엔진에서의 객체 관리 시스템을 들 수 있다. 기존의 보편적인 게임 객체(Game Entity) 정의 방법은 상속을 이용한 정의가 주로 사용되었는데 이러한 방법은 상위 계층에 대부분의 기능들이 포함되는데다 개발이 진행되면서 객체의 종류가 변동됨에 따라 빈번한 설계 변경이 발생하고 변경하는 일 또한 힘들다. 
이러한 문제를 해결하는 좋은 방법 중에 하나는 [4]구성요소(Component)를 이용해서 객체를 구축하는 것으로 이 방법을 사용하면 새로운 게임 객체들을 추가하고 관리하는 일이 쉬울 뿐만 아니라 게임 객체를 각 서브 시스템별 구성요소로 구분하여 멀티 쓰레드 모델을 적용하기가 용이하다는 이점도 있다.
<구성 요소 기반 객체 정의>
위의 그림은 일반적인 네트워크 게임의 플레이어 게임 객체를 구성 요소에 기반하여 정의한 것이다. 플레이어 객체는 게임에서 사용자가 선택한 모델이므로 화면에 렌더링 되기 때문에Rendering 컴포넌트를 가지며 사용자의 입력을 받으므로Mouse Input 컴포넌트도 가진다. 또 게임 내의 다른 객체들과 충돌 등에 반응하여 상호 작용하기 위해서Actor Physics 컴포넌트가 필요하며, 네트워크 플레이를 위해서 패킷 등을 주고 받는 처리를 담당하는Network 컴포넌트와 애니메이션 처리를 위한Animation 컴포넌트도 정의되어야 한다.
이와 같이 구성 요소를 기반으로 객체를 정의하게 되면 새로운 게임 객체를 추가할 때 객체의 구성 요소를 정의하는 방법으로 추가하기 때문에 추가가 용이할 뿐 만 아니라 구성 요소를 멀티 쓰레드의 서브 시스템으로 구분되므로 멀티 쓰레드를 이용하는 데에도 용이하다.
그리고 이러한 구성 요소에 기반한 객체 시스템을 정의할 때 각 구성 요소 간의 의존도를 최소화 시키면서 객체간 필요한 데이터를 주고 받기 위해서 메시지 전달 방식을 사용하게 되는데 이렇게 메시지를 이용하여 구성 요소(서브 시스템)간에 데이터를 주고 받는 방식은 멀티 쓰레드를 이용한 프로그래밍 방식에 적합하다는 또 다른 이점이 있다.
결론
이 글을 쓰는 시점에서는PC 플랫폼의 경우 두 개의 코어를 가진 모델이 주종을 이루고 있는데 이러한 PC 플랫폼에서는CPU 타입의 차이 등으로 인해 멀티 코어 프로그래밍의 효과가 미미할지 모르지만 앞으로4개, 8개의 코어를 가진CPU가 등장하는 경우에는 코어를 어떻게 이용하느냐에 따라 성능 향상의 차이가 달라지게 되므로 향후에는 멀티 코어를 이용한 프로그래밍은 매우 중요한 기술이 될 것으로 예상된다.
참고 자료
[1]XBox360, Microsoft, http://www.xbox.com
[2]PlayStatin3, Sony Computer Entertainment, http://www.playstation.com
[3] Multithreaded Game Engine Architectures, Gamasutra,
http://www.gamasutra.com/view/feature/1830/multithreaded_game_engine_.php?print=1
[4] Component Based Object Management, Bjarne Rene, Circle Studio Ltd, Game Programming Gems 5
하고 싶은 이야기는 이겁니다. 병렬 처리를 하게 되면 기본적으로 race conditioning과 같은 문제들을 해결해야 하는데, 멀티 코어를 고려해서 엔진을 설계할 때 구성요소 기반의 아키텍쳐를 가지고 가면 구성요소기반의 아키텍쳐가 가지는 고유의 장점 외에도 멀티코어에도 유리하다 것을 이야기하고 싶었던 겁니다. 컴포넌트들로 모듈간 디커플링 시키는 아키텍쳐 구조가 병렬 처리에서의 약점들도 커버해 주더라...이런 것을 이야기하고 싶었던 거죠. ^^; 최근에 Nebula3에서의 멀티 코어 시스템에 대한 글도 있으니 참고로 읽어 보시길 권합니다.
# by | 2008/03/27 12:11 | MultiCore | 트랙백 | 덧글(2)
