East Agent's Blog

아래 윤정님의 질문에 대한 생각입니다...

MotoGP는 바닥(트랙) 텍스쳐에 정보를 저장합니다. 이렇게 해도 충분한 이유는 오토바이 레이싱이니까 2차원으로 충분하기 때문이겠지요. (오토바이가 하늘을 나는 일은 없을테니까요)

소닉은 본문을 읽어 보면 3차원 격자에 저장한다고 나와 있습니다. Sonic Unleashed가 어떤 게임인지는 유튜브 등에서 찾아 보면 게임 플레이 동영상을 볼 수 있습니다. 점프해서 천방지축 사방으로 튀고 있으니 MotoGP처럼 2차원으로는 힘들고 3차원으로 처리하는 것이 맞겠군요.

본문에 보면 다음과 같이 설명하고 있습니다.

이러한 표현을 위해 사용되는 '라이트 필드'의 3차원 격자가 스테이지 전체에 대해서 일정한 분포를 가지게 되면 메모리 용량을 낭비하기 때문에, 음영이 복잡한 곳은 많게, 거의 변화하지 않는 부분에서는 적게...라는 식으로 배치하여 실용성을 높이고 있다. 

공간 구조를 위한 자료형으로 옥트리를 사용하지는 않는다는 이야기군요. 음영이 복잡한 곳과 변화가 적은 곳으로 구분한다고 하니까 공간을 광원의 개수에 따라 가중치를 두고 k-d tree 등으로 분할하지 않을까 생각됩니다. 얼마나 세분화할지는...글쎄요 일본 친구들이니까 휴러스틱한 방법으로 해를 구하지 않았을까요? ㅡㅡ;


캐릭터의 음영 변화라면 MSG4(본문은 여기)에서 사용했다는 ambient cube를 이용한 방법도 있습니다.

개발시 이용한 반구 라이트 설정 툴의 화면

이미지를 클릭해서 보면 큰 이미지로도 볼 수 있는데,  본문에서 이야기나는 반구 조명이라는 Hemisphere Lighting 같은 것은 조명 때릴 때의 알고리즘에 대한 이야기이고, 방법의 핵심은 아티스트의 노가다에 의해서 충실하게 재현되고 있다...뭐 이런 이야기죠. ㅡㅡ;

또 같은 글의 바로 아래 본문에 보면 '분리 프리 라이팅'이라는 흥미로운 방법도 나옵니다.

이 방법은 정점 단위의 라이트맵이라고 하는군요.

구체적으로는 장면의 디자이너가 설정한 분리 프리 라이팅 전용의 광원으로부터 라이팅 결과를 사전에 배경 폴리곤 모델의 각 정점의 별도 속성에 굽는(저장해 두는) 테크닉이다.

개발시 이용한 분리 프리 라이팅 설정 툴의 화면

 
역시 광원의 배치는 아티스트의 몫. 하지만 이번에는 라이트맵에 비해서 다음과 같은 장점이 있습니다.

또, 빛의 분포 해상도 자체가 정점 단위인 관계로 라이트 맵보다 대략적인 측면은 있지만, 그만큼 텍스쳐 메모리 소비가 압도적으로 적어지는 것이 메리트다. 덧붙여 배경 폴리곤의 각 정점에 라이팅 결과를 굽는 공정은 개발 단계가 아니고, 게임 기동 후 PS3 실기상의 런타임으로 수행한다. 이러한 동작 덕분에 동적인 장면 변화에도 대응할 수 있는 메리트도 있다

이 방법도 쉽지는 않은 것으로 알고 있습니다. 기술보다는 레벨 디자이너의 역량에 영향을 받는다고...알고 있습니다. (아직 이런 방법을 실제로 게임에 사용해 보진 않아서 말이죠~) 그래도 이 방법은 우선 런타임때 수행한다는 점에서 호감이 갑니다.

이 외에도 유사한 방법으로 지금 생각나는 것은 ShaderX에 소개된 (몇권인지는 기억이 잘) ambient field가 생각이 납니다 이 방법은 벽 등에 가까이 가면 상호 음영이 발생하는 방법에 대한 내용입니다.

음...윤정님 게임의 캐릭터들은 바닥에 붙어 있을텐데 MotoGP와 유사한 방법으로 해결하면 되지 않을까요?

제가 고민하는 문제는 라이트맵을 사용하면서 낮밤의 변화를 주는 방법인데요...그러면서도 레벨 제작시 베이킹을 거의 리얼 타임!으로 할 수 있는 방법을 찾고 있습니다. ㅡㅡ;;

주말에 새로 올라온 몇 가지 포스팅들을 보다 김윤정님의 최적화 고민이 생각이 나서 그 짐을 일부나마 덜 수 있을까 하는 마음에 관련된 포스트들을 소개합니다. ^^

사실 최적화는 애플리케이션단에서의 문제이기 때문에 일반적인 지침을 이야기한다고 해도 바로 적용하기 힘들거나 또 적용한 다음에 뚜렷한 개선을 볼 수 없는 경우도 허다합니다. 하지만 이런 아이디어들도 여러 가지를 접하다 보면 문제를 만든 사람이 프로그램에서 병목 현상이 발생하는 부분들에 대한 지도를 그리는데 도움이 될 수 있습니다. 그런 의미에서 바로 이 기본적인 가이드 라인의 의의를 찾을 수 있을 것입니다.

먼저 첫 번째로 소개할 글은 Sony Santa Monica, God of War 팀의 Christer Ericson씨(Realtime Collision Detection이라는 책의 저자로도 유명하죠)의 블로그 사이트에 올라온 파티클 렌더링의 최적화(Optimizing the rendering of a particle system)에 대한 글 입니다.

렌더링과 관련한 최적화의 문제는 결국 fillrate와 bandwith, 이 두 가지의 문제로 귀결이 되는데 이 포스트에서도 이들과 관련한 파티클 렌더링의 최적화에 대해서 A부터 Z까지 중요한 내용-이지만 아무도 알려 주지 않는-들이 잘 나와 있습니다.

포스팅에는 아래에 나온 11개 항목의 일반적인 항목과 2개의 비기가 언급이 되어 있습니다. (자세한 내용은 원문을 읽어 보길 권합니다.)

1. Use opaque particles.
2. Use richer particles.
3. Reduce dead space around cutout-alpha particles.
4. Cap total amount of particles.
5. Use frequency divider to reduce data duplication.
6. Reduce state changes.
7. Reduce the need for sorting.
8. Draw particles after AA-resolve.
9. Draw particles into a smaller-resolution buffer.
10. Use MSAA trick to run pixel shader less.
11. Generate particles “on chip.”

1. Compose particles front-to-back premultiplied-alpha style.
2. Group particles together into one particle entity.

윤정님 게임이라면 엔지니어분들이 위에 내용들을 파악한 다음 1,2,4,6부터 한번씩 시도해 보는 것도 좋겠군요. (이들 중 몇 가지는 지난 해 부산 ICON 2008의 "Nebula2 엔진에 사용된 그래픽 최적화 기법" 강연 에서도 소개가 되었습니다.)

그리고, 이런 포스팅들을 읽을 때 원문만 읽고 넘어 가지 말고 아래 커멘트들도 한번쯤 확인하는 습관을 가지면 좋습니다. 포스팅된 글에 대한 의견이나 개선점들이 올라오는 경우가 많기 때문입니다. 그 중에서는 본문 보다 값진 덧글을 찾는 경우도 꽤 있습니다. 위의 파티클 최적화 포스팅의 경우 Timothy Farrar의 덧글이 그러한 경우인데, 어라 Timothy Farrar씨의 블로그 가 링크가 되어 있군요. 어디 한번 볼까요. (역시나 짐작대로) 렌더링과 관련한 포스팅들이 대부분입니다. ^^

쭈욱 훑어 보니 "Resistance II's Graphic Engine"이라는 포스팅(081115 / R2)이 눈에 띕니다. 그렇지 않아도 최근에 Insomniac사와 Resistance II 개발에 관심이 많은데 좋은 포스트를 찾았군요. 아래는 ResistanceII의 렌더링 테크닉과 관련해서 Timothy Farrar씨가 언급한 내용들입니다.

1. Optimized the Particle/Blending Pass
2. HDR with proper Bleeding
3. Water Improvements
4. Shadowing
5. Lighting on Cutouts
6. Z Range Issuse / Multiple Passes

최적화와 관련한 내용은 1, 4, 5 가 해당이 되겠군요. 개인적으로는 Resistance II의 개발에도 사용되었음직한 Insomniac의 툴 프레임워크인 Nocturnal Initiative에 관심이 많습니다. (이전 포스트에서도 한번 언급한 적이 있습니다)

그런데 이 포스트는 Human Head Studio에서 근무하는 Brian Karis씨의 "The Latest Games"포스트를 보고 생각이 나서 올린 것이라고 합니다. 그럼 어디 또 링크되어 있는 Brian Karis씨의 글을 한번 찾아 볼까요. Brian Karis씨는 Pray로 유명한 Human Head Studio에서 그래픽 프로그래머로 일하고 계시는군요.

포스팅에는 제목이 이야기하는 바대로 최근에 나온 게임들에 나온 게임들에서 사용된 렌더링 기술들에 대한 내용을 담고 있습니다. 글의"Latest" 게임들은 바로 Dead Space, Mirrors Edge, Fallout 3의 세 게임입니다.

첫 번째 DeadSpace에서는 주로 동적 그림자와 관련한 이야기를 언급하고 있습니다. 아무래도 게임이 호러 장르이다 보니 라이트를 흔든다던가그림자를 이용한 임팩트 등이 게임 연출에서 중요한 요소이기 때문일 것입니다. 또 이 게임은 이전의 어떤 게임에서도 시도하지않았던 게임 내 UI 사용으로도 연구 가치가 있는 게임이기도 합니다.


다음으로 Mirrors Edge에서는 라이트맵 제작과 관련한 흥미로운 이야기가 나옵니다. Mirrors Edge 가 언리얼 엔진3를 사용한다는 이야기는 이미 잘 알려진 사실인데 렌더링된 장면은 언리얼 엔진3를 사용한 다른 여러 게임들과는 확연히 구분이 됩니다. 이는 Beast 라는 Illuminate Labs라는 써드파티의 미들웨어를 사용했기 때문입니다. 그리고 게임 내에서의 라이트맵은 렌더링 퀄리티를 희생하지 않기 위해서 (높은해상도의 라이트맵을 사용하기 위해서) 스트리밍된다고 합니다.(정확한 내용이리가보다는 유추입니다) 이 이야기가 사실이라면 비슷한고민을 요즘 하고 있기 때문에 매우 흥미로운 이야기입니다.
또 Illuminate Labs 사이트에는  Beast와 유사한기능을 가지고 있지만 스탠드얼론 프로그램이 아니라 Maya 플러그인으로 제공되는 또 다른 라이팅 솔루션인 Turtle이있습니다. 그런데 3DS Max에도 Turtle과 유사한 RTTGroup 이라는 툴이 있습니다. 둘의 차이점이라면 RTTGroup은 3dsmax의 라이트맵 기능을 이용한다는 것이고 Turtle은 라이팅 솔루션을 직접 제공한다는 점인데 이러한 사실로 보면 Turtle이 한수 위 같군요.

마지막으로는 Fallout3입니다. 세 가지를 이야이하고 있는데 첫 번째는 Light Shaft 두 번째는 Grass 그리고 마지막 세 번째는 부서진 건물 잔해를 위한 노말맵의 사용에 대한 내용입니다.

Nebula Philosophy - Nebula is an operating system for games - Nebula 엔진과 Mangalore 게임 프레임워크에 대한 꽤 오래된 글...

올리고 보니 생각나는 것 하나.

며칠 전에 A팀장이 게임 엔진 몇개에 대해서 물어왔다.

Orge, Irricht, Crystal Dynamics, Reality Factory, Nebula, Open Scene Graph...(한 10 여가지였던 것 같은데 다 기억나지는 않는다) 들 중에서 어떤 것이 좋냐고.

Crystal Dynamics는 보지 말것, Orge는 글쎄로, Reality Factory는 너무 낡았고, OSG도 잘...

추려내고 남은 것이 Irricht과 Nebula 두 가지인데, 내 대답이 뻔할 뻔자 Nebula이고.

T가 두 가지를 구분하는 방법은 Nebula에는 아키텍쳐가 있다는 것이고 Irricht은 그냥 렌더러라는 것. 틀린 것은 아닌데 너무 함축적이라 다소 이해가 난해하다.

Nebula의 경우 다년 간 실제 상용 게임들을 만들면서 부닥친 수 많은 문제점들에 대한 해결책이 엔진에 녹아 있다는 점이다. 그래서 엔진의 API를 보고 이것이 어떤 처리를 하는 것인지를 이해하는 것도 중요하지만 더 중요한 것은 왜 이렇게 해결하고 있는지에 대한 것을 이해하는 것이다. 그래서 RadonLabs라는 개발사의 히스토리를 이해하는 일이나 이제껏 개발한 게임들을 아는 일이 때로는 엔진을 이해하는데 많은 도움이 된다.

Irricht은 플랫폼 그래픽스 API의 래퍼 아닌가. 그 이상도 그 이하도 아닌. 이런 류의 미들웨어는 많다. 게임브리오도 여기에 속하고. Irricht은 그런 류의 미들웨어 중에서도 간결함에 있어서 상당히 좋은 평을 받는 것 중의 하나이다.

이렇게 보면 또 Nebula 쪽으로 편향된 것처럼 보일지 모르겠지만 둘 다 맞는 곳이 있다는 이야기다. Nebula처럼 자신의 아키텍쳐가 있는 것들은 이 아키텍쳐를 바꾸어야 하는 곳에서는 쥐약이다. 그런 쪽에는 차라리 Irricht이 더 나은 선택일 것이다.

하지만 시간이 좀 걸리더라도 게임 개발 전체에 대한 여러가지를 배우려면 Nebula를 권한다. 전문적인 개발에서 부닥친 여러 문제점에 대한 실용적인 해답도 그 속에 함께 있기 때문이다.

대충님의 블로그를 보다 잊었던 아이디어가 다시 떠올랐습니다.

개인적으로는 ShaderFX와 같은 아티스트를 위한 머티리얼 에디터에는 큰 관심이 없지만 3ds Max에서 사용자 정의형 Schematic Edtor의 구현은 그 방법이 참으로 궁금했습니다.

ShaderFX를 보면서 그것이 가능하다는 것은 알았지만 3ds Max의 Sample에도 마땅히 참조할 만한 것이 없어 궁금만 더 했는데 대충님이 블로그에 소개한 Schematic Material Editor 1.0 For 3DS MAX를 찾아 보니 오픈소스군요!

이 Schematic Editor의 구현이 궁금했던 이유는 이전에 Nebula2 3ds Max 플러그인을 만들 때 캐릭터의 애니미메이션 처리와 관련한 부분 때문입니다.

Unreal Engine 3에서 제공하는 기능 중에 Animation Tree라는 것이 있는데 이것을 본 다음 Nebula2 3ds Max Toolkit에서도 3ds Max 내에서 Schematic Editor를 이용하여 이런 기능을 제공하면 참 좋겠다고 생각했지만 사용자 Schematic Editor의 구현 방법 때문에 생각으로만 남겨 두었습니다.

이러한 시스템이 필요한 이유는 AI Programming Wisdom 2권의  Chris Hargrove가 기고한 "4.1 단순화된 애니메이션 선택"에 잘 나와 있는데요, 복잡한 애니메이션 개발을 위해서는 아티스트와 AI 프로그래머가 조작하기 쉬운 방법이 필요한 것이 주요한 이유입니다.

그래서 처음 Unreal Engine3의 이 애니메이션 트리를 봤을 때 Schematic Editor로 3ds Max 내에서 구현할 수 있겠구나라는 아이디어가 딱 떠올랐는데 이게 엉뚱하게 Schematic Editor에 대한 정보를 도통 찾을 수가 없는 겁니다.

하지만 지금 생각하는 아이디어는 이전과는 조금 다릅니다. 3ds Max에서 플러그인으로 익스포트하는 것이 아니라 아티스트가 만든 애니메이션을 엔진의 스크립트 형태로 바꾼 다음 메쉬 및 애니메이션 정보와 함께 FBX로  저장하고 엔진에서는 이 FBX 파일을 임포트 시켜서 사용하는 방법입니다.

실제 구현은 Schematic Editor의 노드를 스크립트 형태로 변환하는 것이 요지인데 이것은 AI Programming Wisdom 2권의  Chris Hargrove가 기고한 "4.1 단순화된 애니메이션 선택"만 잘 이해하면 어렵지 않게 구현할 수 있습니다.

그런데 왜 FBX냐구요? 그건 다음에요~ ^^

Nebula2 엔진의 스크립트 시스템에 대한 다이어그램


아래 내용은 Nebula2의 스크립트 시스템의 함수 바인딩 방법에 대한 것이다.


우선 스크립트 시스템의 가장 기본적이면서도 중요한 처리는 게임 엔진의 클래스 객체의 멤버 함수를 호출하는 일이다.

위의 그림은 이에 대해서 Nebula2 엔진의 스크립트 시스템에서의 메카니즘을 나타낸 다이어그램이다. 설명은 다음과 같다.

1) 게임 엔진의 클래스들 중에서 스크립트(맨 아래쪽)에서 엔진의 API를 호출할 수 있도록 하려면 nRoot 클래스를 상속받아야 한다.

2) 스크립트 언어에 독립적인 소통 방법이 필요하다. 바꾸어서 이야기하면 어떤 스크립트 언어(Tcl, Python, Lua, Ruby 등...)를 사용하던지 간에 같은 방법으로 게임 엔진의 API를 호출하는 방법이 필요하다. (스크립트 언어가 바뀌는 경우 모든 관련 시스템을 다 바꾸어야 한다면 곤란하지 않은가)

3) 스크립트 서버는 게임 엔진과 스크립트 사이의 중간에서 상호 소통을 위한 동시 통역사의 역할을 한다.

4) 함수 호출에 대한 처리는 nCmd 클래스로 처리한다. 함수 호출을 위해 알아야 할 내용은 리턴값, 각 인자의 개수, 인자별 데이터형(type), 함수 포인터가 있다. nCmd 클래스 객체의 인스턴스는 이 정보를 가진다. nRoot 클래스를 상속한 클래스는 스크립트 인터페이스 함수의 개수에 따라 복수개의 nCmd 클래스를 가진다. 스크립트 인터페이스 함수란 nRoot 클래스를 상속한 클래스의 멤버 함수 중에서 스크립트 코드에서 호출할 수 있도록 만든 함수를 말한다.

5) 멤버 함수의 인자의 실제 값은 nArg 클래스에 저장된다.

6) 원으로 그래진 도형들은 색상을 주의 깊게 볼 것. nRoot 클래스의 멤버 함수들 중에서 스크립트 인터페이스를 가지는 멤버함수들은 이에 대응하는 각각의 nCmd 클래스가 있고, nCmd 클래스는 대응하는 멤버 함수가 가지는 인자의 개수만큼 nArg 클래스의 인스턴스를 가진다.

7) 그러면, 왜 nArg 클래스를 사용해서 인자를 처리할까라는 의문이 생긴다.(이런 의문이 저절로 생겨야 한다 -_-)

8) 대부분의 스크립트 언어에서는 데이터의 형 검사가 엄격하지 않다. 설사 데이터형을 구분한다고 하더라도 C++과는 다른 것이 보통이다. 이를 위한 universal[1]한 데이터형이 필요한데 이것이 바로 nArg 클래스이다.





[1] universal - 적절히 번역할만한 단어가 떠오르지 않는군요...-_-;

@ Property와 Reflection, 그리고 이를 다시 툴 프로그래밍에까지 연결시키는 설명이 뒤따르는데 시간 관계상 주말에는 여기까지 옮깁니다.

@@ 요점만 간추렸는데 Nebula2 스크립트 시스템을 코드를 찾아 보면서 이해하려니 힘들다는 분들에게는 조금이나마 도움이 되었을려나요. ^^

아래 포스트 올린 김에 하나 더.

원래 비슷한 주제로 묶어서 공부하면 효과가 배가 되는데, 그런 의미에서 이번에는 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의 프리젠테이션 자료나 아니면 다른 변형된 방법들에 대한 링크된 내용들이 가볍게 쓱쓱 이해될 겁니다...아마도 ^^