East Agent's Blog

하드 정리하다 동영상을 하나 발견...보니까 예전에 Nebula2로 만들었다고 어디서 줏어 온 동영상인데 따라 가보니 People Can Fly의 프로그래머가 만든 것.

PhysX and Nebula Device

내 하드의 날짜를 보니 2006년 3월. 이 시기라면 망갈로가 없을 때 만든 것인데...이건 중요한 이야기가 아니고, 동영상에서 중요한 것은 카트의 움직임이다.

ODE로는 이런 움직임이 힘들다.(파라미터들 조정하려면 꽤나 삽질이 필요하다) 만들기도 까다롭고. 예제도 충분하지 않고. 아마 그런 이유로 PhysX를 사용했을지도...그리고 이 시기라면 아마 Novdex가 아직 nVidia로 인수합병 되기 전일터...

반면에 PhysX는 소스는 없지만 샘플도 충분하고, (물리 엔진의)초보라도 코드 보고 만들 수 있을 정도고, 대부분의 경우에는 ODE보다 안정적인 동작을 보여준다.

Nebula2, Nebula3는 물리 엔진으로 ODE를 사용하고 있는데 이것은 순전히 RadonLabs의 정책 탓인듯. (그런 메일을 Floh와 주고 받은 적이 있다. PhysX는 소스 없어 안쓴다고)

서드파티의 미들웨어 혹은 라이브러리는 반드시 소스 코드가 있는 것을 사용한다는 것이 그 정책. (사실 이것은 굉장히 중요한 내용이다. 상업적인 게임 개발을 위해서는 반드시라고 할 만큼.)

하지만 최근에 nvidia 사이트를 보면 (PhysX는 Nvidia로 합병되었다) DCC툴(3dsmax와 Maya)의 플러그인도 제공하니 (ODE는  공식적으로 이런 것이 없다 -_- Mangalore용 3dsmax script가 있긴 하지만 업데이트 안된지 좀 되기도 했고) Nebula2 (혹은 Nebula3)에서 PhysX를 사용하기를 원한다면 Mangalore의 ODE wrapper 클래스의 ODE API들을 PhysX API로 대체하면 된다. 그렇게 어려운 일은 아닐듯...

만약 소스 코드가 진짜로 중요하다면 (물론 PhysX의 소스 코드도 구할 수는 있다. 돈이 들 뿐~) Bullet Physics를 고려해 보는 것도 좋다. DCC 플러그인은 이쪽은 Collada. 또 이쪽은 소니 엔터테인먼트가 밀고 있으니 오픈소스 프로젝트라고 하지만 프로젝트의 진행과 서포트에 대해서는 그리 걱정하지 않아도 된다.

물리 엔진 자체도 중요하지만 전체 프레임워크에서의 이 시스템에 대한 인터페이스 부분을 유심히 살펴 보는 것도 의미가 있다. 무슨 말인고 하니 Mangalore 게임 플레이 프레임워크에서 바로 물리 엔진의 API를 호출하는 방식이 아니라 (PhysicsProeprty에서 ODE의 API를 호출하지 않는다!) 물리 엔진에 대한 래퍼 클래스들을 따로 두고 Property 에서는 래퍼 클래스의 멤버 함수들을 호출한다는 점이다. 이렇게 추상화하면 좋은 점은 물리 엔진이 변경되어도 애플리케이션쪽은 변경이 필요 없다는 점이다.

그런데 사실 어려운 것은 이 추상화의 문제다. 게임의 다른 시스템에서 물리 엔진에 대한 접근 방식을 잘 알고 있어야지 제대로 된 추상화가 이루어진다. 당연히 물리 엔진을 사용한 다양한 게임들을 개발해 본 경험이 있다면 제대로 된 래퍼 클래스들의 설계가 이루어지겠지만 그렇지 않은 경우 추상화는 하나 마나한 일이 될 터. 이런 점에서 Nebula2 Mangalore의 물리 엔진에 대한 래퍼 클래스는 잘 설계되어진 인터페이스를 포함하고 있다. 그래서 Nebula Device를 사용하지 않더라도 물리 엔진에 대한 추상화 클래스가 필요하다면 한번 쯤 참고해 보는 것도 좋을 듯 하다.

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

콘솔 리듬 액션 게임의 히어로, 기타 히어로의 에어로스미스 편.

데모라서 몇 곡 되지 않는데 (5곡?) 그 중에서도 에어로스미스가 직접 부르는 노래는 두 곡뿐. -_-;

Dream On이 이렇게 어려울 줄은 몰랐다.(플레이가) 느린 곡이라서 처음부터 보통 난이도로 했는데 어느 정도 익숙해지지 않은 다음에는 보통 난이도도 무리.

곡목 리스트는 여기에서.

이번에는 특정 밴드라 그런지 캐릭터들도 에어로 스미스의 멤버들로 구성되어 있다. 캐릭터들의 특징과 액션들도 충실히 재현되어 있어 보인다. 진짜 놀란 것은 조 페리 형아의 기타 디테일... 이 형아가 부티나는 생김새만큼이나 들고 나오는 기타도 럭셔리한데 이번 기타히어로에서는 이러한 기타의 디테일까지 충실히 재현되어 있다.

좋아하는 몇 곡이 빠져 있긴 한데 Mama Kin이 이번 게임을 위해서 새로 녹음해서 들어가 있다는 이야기에 살짝 땡기는 중.

보컬 스티븐 타일러의 딸이 바로 리브 타일러...라는 사실을 아는 사람이 의외로 적다.

리브 타일러는 반지의 제왕에서 엘프, 아르웬으로 나온 그 처자. (입은 닯았다... ㅡ,.ㅡ)


개인적으로 좋아하는 Magic Touch는 빠졌 있다...

Sonic Unleashed - 역시 360의 데모판을 다운로드 받아서 플레이.

사실 이전의 Mirror's Edge와 함께 Global Illumination 계산을 통한 라이트맵의 적용을 눈으로 확인하기 위해서였지만 휴일날 꿈쩍도 않고 무조건 레고만을 외치며 이 블러 저 블럭 찾아 달라는 꼬마 때문에 레고 사역에서 벗어나기 위해서도 다운이 절실.

개인적으로는 Mirror's Edge의 라이트맵보다는 이쪽이 약간 더 좋아 보인다. 같은 하드웨어이지만 Mirror's Edge 쪽은 라이트맵의 해상도가 낮은게 눈으로 보인다. 그러고 보니 일전에 360에서는 부득이 텍스쳐 사이즈를 다운사이징할 수 밖에 없었다라는 이야기를 본 것이 생각난다.  PC판의 Mirror's Edge쪽은 다를지도.

소닉쪽의 G.I.에 대한 이야기는 "세가, 신작 「소닉 월드 어드벤쳐」의 라이팅 기법을 공개 "차세대 수준"의 영상미를 실현하는 글로벌 일루미네이션"에 잘 나와 있다. (사에바료님께 쌩큐~)

"세가, 신작 「소닉 월드 어드벤쳐」의 라이팅 기법을 공개 "차세대 수준"의 영상미를 실현하는 글로벌 일루미네이션" -
http://blog.naver.com/saebaryo/30035754180

위의 사진에서 보듯이 게임의 특징 때문에 소닉쪽이 좀더 고해상도의 라이트맵 사용이 가능한 탓일지도 모른다. 또 게임 플레이 역시 소닉쪽은 워낙에 빠르다 보니 눈에 잘 띄지 않을 수도...

CEDEC의 소닉 관련 글에서는 '라이트 필드'라고 이야기하는 부분이 흥미롭다. (유사한 내용을 예전에 ShaderX2에 "Hemisphere Lighting With Radiosity Maps"이라는 글에서도 찾아 볼 수 있다. MotoGP에서는 레이싱 트랙의 맵에 정보를 저장하고 플레이어가 다리 밑과 같이 그림자가 지는 곳을 지나가면 어둡게 처리했다고.)

버락 오바마 명쾌한 영어
이인석.고성희 엮어 옮김 / 리베르
나의 점수 : ?

점심 시간에 서점에 들렀다 오바마 대통령의 취임식 동영상을 못 봤던 터에 부록 CD에 수록이 되어 있는 것을 보고는 냅다 지른 책. 동영상(세 개 있습니다 ㅡㅡV)은 영문 자막이 있어 아이팟에 넣고 다니면서 보고 있습니다. 그냥 틈틈히 보면서 외고 있는 책(?) (워낙에 유명한지라 당선후 이 유사한 책이 봇물처럼 쏟아져 나왔죠. 이 책을 선택한 이유는 단지 지나가다 앞에 진열되어 있길래...ㅡㅡ;)

오바마 대통령은 연설 잘하기로 유명한데 (사실 미 대선이 한참일 때 어찌된 일인지 매케인의 TV 연설 등은 엄청 자주 봤는데 오바마는 한번도 못봤다) 동영상을 보니 취임식 때 연설문은 역시 명문이고,(물론 직접 작성했을리는 만무하지만 중요한 것은 명문이라는 것.) 특별히 연설을 잘한다는 느낌은 모르겠는데 목소리는 좋다. 액션은 좀 약한 편. 역시 톤인가...

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

먼저 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를 레이 트레이싱하는 프로젝트도 나오던데 이런 것이 보편화 되면 이 포스팅의 이야기도 다 닭질이긴 합니다. ㅡ,.ㅡ