Search Unity

GDC(Game Developers Conference) 2019에서 발표한 대로, 이제 Unity 패키지 관리자에서 Havok 피직스(Havok Physics)를 프리뷰 버전으로 이용하실 수 있습니다. 이제 모든 Unity 사용자가 현재 콘솔 세대의 인기 타이틀 중 절반 이상을 지원하는 물리 솔루션을 이용하여 더 개선된 물리 시뮬레이션을 구현할 수 있습니다.

데이터 분야 파트너십 구축

유니티는 데이터 지향 기술 스택(DOTS)을 통해 미래형 물리 엔진을 정의하는 과정에서 당사와 동일한 핵심 개념과 가치를 공유하는 파트너를 필요로 했습니다. 따라서 Havok과의 제휴를 통해 DOTS를 기반으로 C#으로만 작성된 상태 비보존형 Unity 피직스를 제공하여 고도로 최적화되고 성능이 뛰어난 시스템을 구축했습니다. 또한 더 복잡한 시뮬레이션을 구현하기 위해 상태를 보존하는(stateful) 물리 시스템을 필요로 하는 사용자도 있으므로, Unity에 Havok을 통합하여 하이엔드 시뮬레이션 요구사항에 맞추었습니다.

왜 하나의 시스템이 아닌 두 개의 시스템을 제공하는지 의문을 가지는 분도 있을 겁니다. 유니티는 여러 사용 사례에 따른 다양한 옵션을 제공하고자 합니다. 예를 들어 Unity 피직스만으로 충분한 사용자도 있겠지만, Havok 피직스의 이점과 개선된 워크플로를 원하는 사용자도 있습니다. 시스템 선택에 있어 절대적인 기준은 없습니다. 어떤 방법을 선택하든 콘텐츠를 처음부터 다시 작성하지 않고도 원하는 솔버로 전환할 수 있기 때문입니다.

Havok 피직스 통합

성능

Havok 피직스를 통합하는 과정에서 네이티브 C++로 작성된 클로즈드 소스(closed source)인 Havok 물리 엔진을 기반으로 Unity 피직스가 사용하는 것과 동일한 C# DOTS 프레임워크를 사용했습니다. Havok 피직스는 일반적인 게임 개발에 가장 최적화되어 있습니다. 또한 여러 해에 걸쳐 핵심 알고리즘이 개선되어 왔으며, 비활성 오브젝트를 수면 모드로 전환하는 것을 비롯한 다양한 자동 캐싱 전략을 통해 CPU 리소스가 필요한 곳에만 사용됩니다.

동작

Havok 피직스는 복잡한 씬과 많은 물리적 상호작용이 있는 매우 역동적인 게임의 성능 요구 사항을 처리하도록 설계된 강력한 물리 엔진입니다. Havok은 20년 넘게 업계의 여러 파트너와 협력하여 실시간 물리 시뮬레이션에 발생하는 가장 어려운 문제들을 해결하고, 더 나은 솔루션을 제공하고 있습니다.

따라서 물리적 바디의 안정적인 스태킹(stacking)뿐만 아니라 바디가 빠르게 움직일 때 아티팩트를 최소화하고, 특히 최적화되지 않은 충돌 지오메트리가 있는 경우 일반적으로 더 제어된 동작을 얻을 수 있게 되었습니다.

Havok 피직스의 안정적인 스태킹 기능을 보여주는 예시

Havok 피직스는 지능형 최적화를 수행하기 위해 다양한 상태 정보를 캐시하기 때문에 오픈 월드 게임과 같은 대규모 게임에서 우수한 성능을 보입니다. 또한 Havok 피직스는 우수한 마찰 모델을 통해 오브젝트가 서로 관통하는 문제 또는 오브젝트를 쌓아 올릴 때 발생하는 문제를 처리함으로써 더 큰 안정성을 제공합니다.

단일 프레임에서 정적/동적 리지드바디 간 상호 관통 문제를 해결하는 Unity 피직스(오른쪽)와 달리 여러 프레임에 걸쳐 자연스럽게 설정을 변경하는 Havok 피직스(왼쪽)

시각화 및 디버깅

Havok VDB(Visual Debugger, 비주얼 디버거) 애플리케이션은 Havok 피직스 시뮬레이션을 위한 강력한 디버깅 툴입니다. TCP/IP를 통해 애플리케이션에 VDB를 연결하면 어려운 동작, 성능 문제 및 충돌을 원격으로 진단할 수 있습니다. 연결 후에는 VDB 사용자가 해결하려는 문제에 맞게 활성화/비활성화할 수 있는 다양한 기능을 제공합니다. 설정이 완료되면, 애플리케이션에서 서버를 생성하여 연결된 VDB 클라이언트에 정보를 제공합니다.

Havok VDB UI

VDB는 Havok 피직스를 기반으로 하는 모든 게임에서 개발팀을 지원하는 필수 도구입니다. 원하는 모듈식 뷰어를 선택하여 활성화할 수 있으며, 사용자는 이를 통해 다음을 수행할 수 있습니다.

  • 일시 중지 및 이전 상호작용으로 시뮬레이션 되감기
  • 그래픽 및 텍스트로 성능 통계 확인
  • 물리 세계에서 리지드바디를 구성하는 콜라이더 조회
  • 바디 간 조인트 및 컨택트 조회
  • 시간의 흐름에 따른 바디의 모션 경로 시각화
  • 동적 바디의 활성화 및 비활성화 상태 확인
  • 즉시 최적화가 필요한 고비용 영역을 파악하기 위해 시뮬레이션 히트맵 조회
  • 물리 시뮬레이션과 직접 상호작용

또한 VDB 클라이언트는 검토 목적으로 시뮬레이션의 이전 스냅숏을 기록, 저장 및 로드할 수 있습니다. 이러한 스냅숏은 개발자가 복잡한 물리 시나리오를 디버깅하는 동안 외부 자원이 필요할 때 매우 유용하게 사용할 수 있습니다.

두 개의 물리 엔진, 하나의 데이터 포맷

앞서 설명한 것처럼 DOTS 피직스 개발을 시작했을 당시 주요 목표 중 하나는 모든 시뮬레이션 백 엔드에서 사용할 수 있는 통일된 하나의 데이터 표현을 만드는 것이었습니다. 통합된 에디터 데이터 레이아웃을 제공하면 개발자가 시뮬레이션 백 엔드에 구애받지 않고 툴, 게임플레이 코드 및 기타 시스템을 제작할 수 있습니다. 유니티는 모든 콘텐츠를 다시 작성하지 않고도 필요에 맞게 시뮬레이션 백 엔드를 사용하도록 사용자에게 권한을 부여하고자 했습니다. 아래에서 데이터 레이아웃 모델 다이어그램을 보실 수 있습니다.

DOTS의 물리 데이터 흐름

위 표를 보면 데이터는 작성(authoring)에서 시뮬레이션 시스템(simulation systems)으로 이동합니다. 루트 수준에서 시스템에 구애받지 않도록 작성 데이터를 추상화함으로써 양측 시뮬레이션 백 엔드에서 모두 동일한 툴과 사용자 경험을 빌드할 수 있었습니다. 그 다음 이 데이터를 전환 파이프라인을 통해 엔티티 데이터(Entity Data)로 보냅니다. 엔티티 데이터 버킷에는 PhysicsCollider, PhysicsVelocity, PhysicsMass, PhysicsDamping, PhysicsGravityFactor 및 PhysicsCustomTags와 같은 런타임 컴포넌트가 있습니다. 이들은 Build Physics World 시스템으로 전달됩니다. 이 시스템은 연속적인 액세스에 최적화된 데이터를 랜덤 액세스에 최적화된 데이터로 변환하는 두 번째 변환 단계 역할을 합니다. 이 시스템은 현재 시점에서 월드의 상태를 쿼리하는 데 사용되는 충돌 월드(Collision World)와 현재 시간 단계에서 물리를 시뮬레이션하는 데 필요한 모든 정보를 포함하는 동역학 월드(Dynamics World)를 생성합니다. 이렇게 월드를 분리함으로써 충돌 월드에서 쿼리 작업을 수행하는 동시에 Step Physics World에서 동역학 월드에 있는 데이터를 업데이트할 수 있으므로 스레드를 최대한 활용할 수 있습니다.

다이어그램에서 보듯 Unity 피직스와 Havok 피직스는 파이프라인 전반에 걸쳐 똑같은 데이터를 공유합니다. 따라서 통합된 콘텐츠 파이프라인뿐만 아니라 시스템에 구애받지 않는 데이터 프로토콜 및 API 표면을 활용할 수 있습니다. 따라서 서로 다른 두 백 엔드 간에 전환 과정이 매우 수월해집니다.

DOTS 피직스를 발전시켜 나가는 과정에서, 유니티는 다양한 사용 사례 요구를 충족하기 위해 모든 물리 시스템에서 동일한 제작 경험을 보장하는 광범위한 시뮬레이션 백 엔드를 제공하고자 노력하고 있습니다.

플레이 모드에서 물리 백 엔드 간 실시간 전환

Havok 피직스 시작하기

Unity에 통합된 Havok 피직스를 사용해보고 싶으시다면 Unity 패키지 관리자(Unity 2019.1 버전 이상)를 통해 프리뷰 패키지를 다운로드하실 수 있습니다. 또한 Unity용 Havok 피직스 기술 자료도 제공하고 있습니다.

Havok 피직스에 관한 의견을 공유하거나 문의 사항이 있는 경우, 또는 Havok 피직스를 사용해 제작한 작품을 공유하고 싶다면 DOTS 피직스 포럼을 방문하시기 바랍니다!

25 replies on “Unity에서 Havok 피직스 사용하기”

Regarding the smooth interpenetration in Havok: isn’t it pretty much trivial to implement in Unity physics too? I mean, PhysX has also had it for as long as I can remember…all it takes is to clamp the impulse to a user-defined maximum if the objects start the frame overlapped…

I’d delete the post, but it’s not an option.
So I’m replying to negate the previous post.

Okey, so am I understanding this correctly? Since the built in physics engine is so bad we will now have to pay to get a decent one in our projects, instead of improving the existing one?

This is a huge step in the wrong direction. On top of that, Unity will also become more expensive next year… I am very disappointed.

Hey Lex, when you say built-in are you referring to Unity Physics? PhysX? If you’re referring to Unity Physics are there situations or simulation effects that aren’t meeting your needs with the current functionality? Would be happy to know more about where Unity Physics might be falling short for your needs.

After knowing Havok Physic has a higher quality, better tools and faster performance than Unity Physic, I doubt anyone will use Unity Physic for serious users.

However, there are couple of important questions remains.

1. How much does Havok Physics cost?
2. How does it compare to PhysX, both features and performance-wise.

No one will jump on the wagon without knowing the answers to the questions above. And the answers are…

Hey Chris, great questions. We’re still working out the pricing details and I’ll make sure that gets communicated when they’re finalized. Regarding performance, I do have some breakdown of feature parity between the systems. Performance is another beast entirely since PhysX is not integrated with DOTS it’s a bit of apples vs oranges comparison. Happy to provide more details in the forum though if that would be useful for you.

I think we’d all find that information useful. Would you inform us where to find this thread ?
Thank You Shawn
(I tried to reply a moment ago, but the post isn’t showing.. `in case you see two posts)

Unity development team: having several programming languages for plethora of different use cases is unacceptable, costly and time consuming to maintain, and enforce just one language on everyone (C#). There is no point to keep multiple languages if in the end they do almost the same thing! Every choice of any other language but C# is wrong, period!
Also Unity development team: there is no right or wrong choice, our users have plethora of different use cases, so let’s add multiple physics engines! We have plenty of time and resources to maintain different physics which work mostly the same! Having choices is great!

Can we get some sort of chart or graph comparing the feature and performance differences between Havok, DOTS, and PhysX?

All these things outlined above sound great, but how do they actually compare to PhysX? Why would someone want to move their project from the built-in PhysX to Havok? What limitations of PhysX does Havok overcome, and vice versa?

None of these things are clear in the article.

Hey, these are great questions. Realistically speaking, you wouldn’t move from PhysX to Unity/Havok Physics unless you were also making the transition to our Data Oriented Technology Stack (DOTS). If you’re building a project on DOTS, then Unity/Havok are the currently available physics backends for DOTS-based projects. PhysX continues to exist for current MonoBehaviour based projects. Because of this difference in architecture, it’s more difficult to make an apples to apples comparison between PhysX performance and Unity/Havok. That being said, there are definitely comparisons we can make between Unity/Havok that are part of the first video in the post that outlines some key performance benefits Havok has over Unity Physics.

Pricing is the big question. Right now it seems our options are
* Physics engine that is unusable because it can’t even do stacking and items never come to rest
* An OK physics engine that nobody can afford

Exactly, a step backwards. Pricing should be free – as in paid by part of your subscription package if you use plus/pro. There should be 1 good physics engine.

I was wondering. With the new physics engines, can we have a high frequency physical simulation ? (I’m thinking 250hz to 500hz even 1000Hz maybe) ? I not that’s not usually needed for visual rendering, but for haptics it can be really useful

Hey Flonou, this isn’t currently possible though we are investigating having a system where the physics can simulate at a fixed rate that is independent from the normal update loop.

It would’ve been nice to get a direct comparison between both of the DOTS physics engines and PhysX, because even 6ms for that scene doesn’t sound too optimistic.

Maybe I’m just missing something and Unity Physics always had similar performance to PhysX, but that just reassures me that such a comparison is necessary.

Comments are closed.