East Agent's Blog

AMD 그래픽 제품 그룹의 기술 마케팅 디렉터인 고프리 쳉(Godfrey Cheng)이 Bit-Tech와의 인터뷰에서 PhysX에 사망선고(?)를 했네요.

AMD says Physx will Die: 원문은 여기에서

Mirror's Edge PC delay down to PhysX 원문의 핵심은 아래로 nVidia의 GPU에서의 물리 기능을 사용하면 nVidia 칩에서만 돌아간다는 이야기입니다. 원문에서는 유사한 예로 과거 "FarCry"의 HDR이나 "Compan of Heroes"의 DX10 포팅을 이야기하고 있습니다.

(...)
Of course the let down is that those with ATI graphics will miss out,as PhysX acceleration on the GPU is still very much an Nvidia exclusiveproperty despite rumours of third party developers porting the API to ATI hardware persisting, although nothing concrete has yet materialised.
(...)

위의 기사 내용을 보니 과거 Novodex에서 Physx에 참여했던 Pierre Terdiman씨가 자신의 블로그에서 NVidia Physx 2.8.1의 발표에 대해서 포스팅한 내용이 떠오릅니다. (혹시 공격 사이트라는 경고가 나올 수도 있는데 무시하시길 -_-)

현재 Physx를 사용하고 있거나 혹은 예정인 경우에는 혼돈스러운 내용일 수도 있겠습니다. 물론 물리 계산에 하드웨어 가속을 이용하지 않는다면야 크게 신경 쓸 내용이 아닐 수도 있겠습니다만 앞으로의 트렌드를 본다면 너무 과감한(?) 결단이겠죠.

Physx 물리 엔진의 대안으로는 Bullet Physics Engine을 고려해 볼 수 있지만 물리 엔진을 대체하는 것만으로는 같은 일이 벌어지지 말라는 법이 없으므로 역시 불안합니다. 그래서 미들웨어 사용시에는 반드시 해당 도메인를 잘 파악한 다음 유연한 인터페이스를  설계하는 것이 중요합니다.(쉽게 이야기하면 래퍼 클래스를 작성하는 일입니다.)

물리 엔진의 경우 PAL과 같은 추상 레이어를 사용하는 것도 좋습니다. 아니면 Nebula3의 물리 엔진 레이어를 참고해서 필요한 추상 레이어를 작성하는 것도 좋습니다. (Nebula3의 물리 추상 레이어는 잘 작성되어 있다고 평가 받고 있는 것 중의 하나입니다. 현재 사용하고 있는 물리 엔진은 ODE입니다.)

이렇게 하면 사용하고 있는 미들웨어를 교체해야 하는 일이 발생하더라도 전체 애플리케이션이 경천동지할 일이 벌어지지는 않습니다. 전체를 엎어야 하는 것이 아니라 물리 엔진 래퍼 아래서만 변경하면 되니까 말입니다.

핵심은 인터페이스가 되는 래퍼 클래스를 잘 만드는 일입니다. 네, 이미 알다시피 잘 만드는 일이 어렵습니다. 그러니까 여기서 이야기하고 싶은 핵심은 무작정 만들기 보다는 기존에 다른 곳에서 작성한 것이나 사용하고 있는 예가 있다면 충분히 살펴 보고 작성하라는 것입니다. ^^