영어라 힘들다.. 영어 실력이 한계.. 4 쪽 읽는데 1시간이라니,,
게임 엔진의 정의가 나온다. 그런데, 요약만 하려한다. 영어가 약하니.
-> 재사용될 수 있는 물리적 현상을 집구성한 코드, 일종의 계산기. 일반적인 물리 현상만을 다루며 어떠한 현상을 시연하는지에 대한 정보는 알 수 없다. 이는 추가적인 데이터를 넘김으로써 엔진에 알려야 한다.
-> 사용상의 이점 : 시간을 줄여준다. (투자를 한다면) 점점 더 정교해진다. 또한 만일 어떤 게임은 물과 물체의 상호작용만을 코딩하였고, 다른 게임은 물체와 물체간 및 기체간의 상호작용만을 코딩하였다고 했을 때, 이들 모두가 상호작용해야 하는(물체-물-기체) 게임을 만들어야 할 필요가 있을 때 그 상호작용현상을 합하는 것은 무척이나 어려워질 수 있다(잘못하면 물에 가라앉은 옷이 바람처럼 휘날릴 수도 있다).
-> 사용상의 단점 : 계산량이 엄청나기에 성능을 고려해야 한다. 요새 PC의 성능은 좋아지고 있어 큰 문제가 없으나, 소규모 기기(모바일 폰과 같은)에서도 동작해야 한다면 이는 무시할 수 없다. 가격도 비싸다.
-> 물리엔진을 구축하는 접근에 따른 차이도 존재한단다.
1. 물체의 타입
완전한 강체를 흉내내는 엔진과 mass-aggregate 방식으로 불리는 엔진간의 차이도 존재한다. 전자의 경우, 물체 자체를 하나의 강체로 간주하므로 이동과 회전 등을 고려하면 된다. 그러나 후자의 경우는 모든 물체를 작은 질점들의 집합으로 간주하여 물리적 법칙을 흉내내므로 회전을 고려할 필요까지는 없다. 단지 각 연결된 질점간의 선형적 상호작용을 계산하여 전체적인 상호작용을 모사한다. 그러나 각각 장단점이 존재한다. 후자의 경우, 전자보다 구현이 간단하지만 완전한 강체를 모사할 수 없기 때문에 이를 수정하는 부가적인 코드가 들어가기도 한다. 따라서 강체 방식을 기반으로 하여 mass-aggregate 방식을 확장하는 방식을 사용하기도 한다고 한다.
2. 충돌 해결
첫번째 방식은 'iterative approach'라 불리며, 충돌들을 하나하나 처리하는 방식이다. 무척 빠르게 처리될 수 있으며, 각각의 충돌은 그 자체를 해결하는 데에만 집중한다. 따라서 한 충돌이 다른 충돌에 영향을 미치는 경우를 처리하지 못하는 단점이 존재한다. 그러나 가장 구현이 쉽다.
두번째 방식은 더 현실에 가깝게 물리현상을 같은 시점에 처리한다. 다른 충돌들 사이의 상호작용을 정확하게 계산함으로써 충돌에 대한 처리를 한다. 전자의 방식의 단점이 여기엔 없다. 'Jacobian-based' 접근이라 불린다. 그러나 지나치게 시간을 많이 소모하고 복잡하다. 불행히도 이러한 실제적인 계산을 수행하다 보면 몇몇의 수식은 해를 구할 수가 없을 수 있으며 이 때는 개발자가 이를 보완하기 위해 추가적인 코드를 작성해야 할 때도 있다. 대부분의 물리 미들웨어 패키지는 이러한 접근을 사용하며 각각은 파생되는 불일치를 다루고 수식을 해결하기 위한 자체의 기술이 탑재되어 있다.
셋째 방식은 충돌과 물체간의 제약을 바탕으로(?) 새로운 수식을 적용한다. 느낌 상 물체 충돌 처리를 위해 독자적인 처리 수식을 만들어 쓰는 것 같다. 뉴턴의 법칙을 쓰는 것이 아니라 그들 자신의 법칙을 사용하는 것이다. 이러한 수식은 매 프레임마다 달라질 수 있다. 'reduced coordinate approach'라 불린다. 수식 만드는데 굉장히 오래 걸린다. 몇몇의 물리 시스템은 이 방식으로 만들어졌으며 정말로 정확한 시뮬레이션을 만들어내기 위해 엔지니어링 소프트웨어에서 흔하게 사용된다. 그러나 무척 느리다. 고로 정확도보다는 속도와 반응신뢰도를 핵심으로 하는 게임에서는 적합하지 않다.
3. 충격력과 힘
충격력 방식으로 충돌을 해결하는 경우가 존재한다고 한다. 매우 짧은 시간에 주어진 힘으로 물체의 속도를 변화시킨다. 즉, 일순간에 힘을 가하여 물체의 상호작용을 처리하는 방식으로 생각된다.
힘의 개념으로 충돌을 해결하는 경우도 존재하는데, 이 때는 구현이 더욱 복잡해진다. 이 경우에선 매 프레임마다 힘을 지속적으로 가하며 물체의 상호작용을 해결하는데 충격력을 사용하는 경우보다 안정적이라고 한다.
댓글 없음:
댓글 쓰기