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를 사용하지 않더라도 물리 엔진에 대한 추상화 클래스가 필요하다면 한번 쯤 참고해 보는 것도 좋을 듯 하다.