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와 유사한 방법으로 해결하면 되지 않을까요?

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

아래 포스트에서 라이트맵 이야기가 나온 김에 게임을 위한 라이팅 솔루션 미들웨어들을 한번 정리해 봅니다.

먼저 DCC툴을 이용한 라이트맵 솔루션으로는 다음의 두 가지가 있습니다.

• RTTGroup - 3dsmax, The Witcher에 사용
  
• Turtle - Maya, Tomb Raiders - Under world에 사용

DCC 툴을 이용한 라이트맵 베이킹 솔루션의 경우 스튜디오의 아트 파이프라인과 각각의 작업 그룹에 대한 고려도 필요합니다. 레벨을 DCC 툴에서 모델링하고 텍스쳐링하는 그룹과 게임의 레벨을 디자인하는 그룹이 분리되어 있는 경우 라이트맵의 베이킹은 아트 그룹에서 처리하게 됩니다. 그런데 레벨 디자인 그룹에서 레벨 디자인에 대한 변경에 따라 수시로 라이트맵을 다시 베이킹해야 하는 일이 발생하게 됩니다. 작업의 비효율성이나 시간적 부하는 말할 필요도 없거니와 그룹간의 불화로 번지는 일도 일어납니다. 이런 이유로 DCC툴의 라이트맵 베이킹을 사용하고자 한다면 나름의 세심한 주의(?)가 필요합니다.

라이트맵 솔루션이긴 하지만 DCC 툴이 아닌 오프라인 툴로는 Beast가 있습니다.

• Beast - Mirros's Edge에 사용

앞의 DCC툴을 이용한 솔루션들은 콘솔 등의 스테이지 개념이 있는 게임의 제작에는 적합할지 모르겠지만 MMO 게임과 같이 규모가 큰 레벨이 필요한 곳에서는 Beast와 같이 제공하는 SDK를 이용하여 월드 에디터와 같은 인하우스 툴의 마지막 쿠킹 과정에 포함시키는 쪽이 생산성을 높이는 데에는 훨씬 더 좋습니다. 개인적으로도 상당히 관심이 있어 문의를 해 보았는데 가격이 장벽이군요. OTL 부가세를 포함하면 대략 큰 것 한장 생각하셔야 합니다. 베이킹에 이 가격이면 선뜻 구매하긴 힘든 가격이죠. (물론 '그 정도쯤이야'라고 생각하시는 분들도 계시겠습니다만...)

그런데 이상의 방법들은 베이킹(프리 프로세싱)을 하는 솔루션이기 때문에 계산에 따른 시간이 필요하다는 단점이 있습니다. 레벨 에디팅이 반복적인 작업인 것을 생각하면 전체 개발 시간에서 상당 부분을 차지한다는 것을 감안해야 합니다. (Beast의 경우  Incredibuild를 통한 분산 처리가 가능하긴 합니다)

이런 이유로 런타임 때 처리할 수 있는 방법이 있다면 생산성 향상에 도움이 될 것입니다. 최근에는 프로세스의 발전에 힘입어 이런 솔루션들도 등장하고 있는데 그 중 하나로 Lightsprint가 있습니다.

비슷한 솔루션으로 Fantasy Lab의 Radium SDK가 있는데 어쩐지 최근에 변경된 Fantasy Lab의 사이트에서는 볼 수가 없군요. (이 솔루션이 Lightsprint보다 훨씬 더 관심이 갔는데 말입니다.)

...다소 시간적인 여유가 있다면 NHN의 오픈 소스 프로젝트 중에 분산 컴퓨팅 프로젝트인 coord 프로젝트를 이용해서 GI 프로세싱 솔루션을 한번 시도해 보는 것도 좋을텐데...라고 생각만 하고 있습니다... ^^; (혹 관심 있으신 분??)


ps.1 최근에 뜯어 보고 있는 게임인 Fallout3의 경우에는 라이트맵이 보이지 않습니다. 물론 리얼타임 G.I.도 없습니다. 작년 최우수 게임 수상에 빛나는 게임이죠. 그래서 훌륭한 게임과 라이트맵은 큰 상관 관계가 없다고 말할지 모르겠습니다만 우리 대부분은 이와 같은 위대한 게임을 만들지 못하기 때문에 라이트맵이라도 만들어야 하는 것이 아닌가 하는 다소 역설적인 생각도 해 봅니다...네, 웃자고 한 이야기예요 ㅡㅡ;

ps.2 물론 아래 포스트한 글에서 팀스위니 형님이 이야기대로 소프트웨어 렌더링의 시대가 오거나 최근에 32 코어 머신 등으로 Quake4를 레이 트레이싱하는 프로젝트도 나오던데 이런 것이 보편화 되면 이 포스팅의 이야기도 다 닭질이긴 합니다. ㅡ,.ㅡ

Conan; Hyborian Adventures, the making of - interview

Age of Conan의 수석 레벨 디자이너인 Chris B. Jensen씨의 Conan의 레벨 제작에 관한 인터뷰 내용.

Quake 시리즈와 Unreal의 레벨 에디팅에 익숙하다고 하니 Conan의 레벨 에디팅에도 Radiant를 사용했다는 것은 이해는 되지만 팀 전체의 작업 효율을 생각한다면 글쎄요...라고 생각되었는데 아니나 다를까 역시 에디팅의 대부분은 3dsmax에서 했다고.

라이트맵의 작업 역시 3dsmax를 이용했다는데, 기술적인 내용들이 좀 자세하게 나왔으면 도움이 되었을텐데, 아티스트라 그런지 그런 내용까지 기대하기는 무리.

3dsmax의 라이트맵 베이킹은 나름 편리한데다 품질도 훌륭하지만 오브젝트당 라이트맵을 베이킹하기 때문에 레벨 맵의 경우 적절한 크기로 여러 개의 맥스 오브젝트로 구분해 주지 않으면 훌륭한 품질을 기대하기가 힘들다. (3dsmax에서의 라이트맵 베이킹과 관련한 이야기는 내용은 이전 RTTGroup 포스팅을 참고)

라이트맵의 사용은 정적인 경우에는 라이팅 품질을 위한 훌륭한 선택일 수 있지만 동적인 장면에는 적합하지 않다. Conan의 경우 semi-dynamic이라고 (내부적으로)지칭한 방법을 사용한다고. 메탈 기어 솔리드4에서는 정점에다 라이트값을 런타임때 베이킹해서 사용하는 방법과 비교해 볼만하다. 개인적으로는 생산성의 관점에서 후자의 방법이 더 낫다고 판단.

도움이 될만한 기술적인 내용을 포함하고 있지는 않지만 MMO 타이틀의 레벨 제작에 관한 이야기는 드물다는 점을 고려하면 읽어 보는 것도 나쁘지 않다.

월드 에디터 툴인 Genesis에 대한 이야기가 좀 많이 나왔으면 하는데 이 부분은 거의 없다는 점이 다소 아쉽다. (아래는 Genesis)

하드코어 XML 개발자를 위한 하드코어 XML 에디터로부터 트랙백

Nebula의 경우 이전에 Mangalore 게임 프레임워크부터 현재 Nebula3까지 엔진의 여러 모듈에서 다양한 용도로 XML을 사용하고 있습니다.

이러한 이유로 일전에 팀 프로그래머 한분이 XML 편집에 괜찮은 에디터에 대한 소개를 부탁했는데 '난 vim'이라는 다소 쌩뚱맞은 답변을 에코했던 기억이 납니다. ^^;;

RadonLabs에서도 XML의 편집이 잦은 이유을 따로 에디터를 구입해서 사용하는 것으로 알고 있습니다. (이름이 생각이 나질 않는군요 ㅡㅡ;)

오늘 우연히 haje01님의 블로그를 발견했는데, 블로그를 발견한 것도 반가운 일이었지만 딱 대문에 이런 좋은 포스트가 실려 있어 매우 기뻤습니다.

Lua와 XML의 게임에서의 응용에 관한한 NHN이 역삼에서 분당으로 자리를 옮긴 시간보다도 더한 공력을 지니신 분이시니(응??), 추천에는 별다른 이의가 필요 없을 듯 합니다. haje01님이 소개한 XML 에디터는 http://www.oxygenxml.com/입니다.

연휴가 끝나면 팀에도 소개해 주어야 겠습니다.

http://gyuha.tistory.com/225

티스토리에는 이런 플러그인(?)이 지원이 되는데, 이글루는 -_-;;

진짜 이글루는 10덕들을 위한 블로그라는 항간의 소문이 맞나요??? 네??

오래되어서 그냥 쓰고 있기는 한데 최근에 이것저것 불편한 점이 자꾸 걸립니다.

예를 들어 전에는 구글독에서 편집한 걸을 바로 포스팅하는 것이 가능했는데 언젠가부터 안되더군요. -_-;

그리고 맥에서는 파이어폭스에서 ScribeFire을 사용해서 포스팅하는데 (http://kimsama.blogspot.com) 이글루는 -_-;;

구글독에서 편집한 다음 카피해 넣으면 랜덤하게 띄워쓰기가 깨어지는 버그는 또 뭔지... -_-;;

MS Live Writer도 한번 테스트해 봐야겠습니다...맥에서 될란가... ㅡㅡ;

컴포넌트 기반의 게임 객체(Entity) 구현을 위해서는 프로퍼티 클래스가 필연적으로 필요합니다.

우연히 방준영님의 블로그에서 재미있는 -Visual C++에서 기본으로 지원하는 것- 포스트를 찾아서 소개합니다.

C++로 프로퍼티 구현하기 1부

Nebula에서는 Attribute로 구현이 되어 있는 부분입니다. 요지는 컴포넌트 기반의 게임 객체가 메타 객체라는 것인데 이들 객체의 데이터 처리를 위해서도 메타 데이터의 형태가 필요하다는 것입니다.

이 부분과 관련해서 Nebula3 Sep 2008 버전에서는 Model 모듈의 클래스의 관련 코드가 너저분하게 처리되어 있었는데 이번 April 2009 버전에서 말끔히 코드가 정리된 것을 볼 수 있습니다.


ps. 방준영님의 블로그는 최근에 gcc 사용과 관련해서 구글링하다 #include_next 관련된 포스트를 보고 처음 알았는데 최근에 블로그를 이전하셨더군요.(위의 C++ 프로퍼티 블로그) 그런데 이전한 블로그에 상당히 재미 있는(이라고 쓰지만 읽기는 다소 거북한, 본문과 덧글 모두...) 논쟁이 있군요. 논점과 관련해서는 제 전문 분야가 아니라 지식이 충분하지도 못하고 또 관심 있는 주제도 아니라 의견을 말하기는 힘들지만, 오픈 소스와 관련한 내용의 포스트와 덧글들은 곱씹어 볼 내용들이었습니다.