Search Unity

As announced at Game Developers Conference (GDC) 2019, Havok Physics is now available as a Preview package in the Unity Package Manager. This means that all Unity users can get their hands on the same physics solution that powers many of the top titles of this console generation and brings a wealth of enhancements for your physics simulation needs.

Partnership forged in data

When we first set out to define what the future of physics would look like with our Data-Oriented Technology Stack (DOTS), we sought a partner that shared the same core concepts and values as us. Through our partnership with Havok, we were able to leverage DOTS to deliver the highly optimized, stateless, entirely C#, and performant Unity Physics. We also knew that some of you would have more complex simulation requirements, needing a stateful physics system. For that reason, we knew Havok would be the perfect solution to integrate into Unity for those high-end simulation needs.

Some of you might be asking, “Ok, but why did you make two systems instead of just one?” We know that our users have a plethora of different use cases, and we wanted to give everyone a choice based on what their needs are. For some, Unity Physics will suffice, while others will want the benefits and enhanced workflows of Havok Physics. Ultimately, there is no right or wrong choice, as we illustrate later in this blog post. You can switch between either solver without having to reauthor all of your content completely.

Havok Physics integration


The Havok Physics integration in Unity is written using the same C# DOTS framework as Unity Physics, and is backed by the closed-source, proprietary Havok Physics engine, written in native C++. Havok Physics is heavily optimized for typical game use cases. Core algorithms have been refined over many years, and various automatic caching strategies (including sleeping of inactive objects) mean that CPU resources are spent only where needed.


Havok Physics is a robust physics engine designed to handle the performance demands of the most dynamic games, which often include complex scenes with lots of physical interaction. By working with partners across the industry for over 20 years, Havok has encountered and solved, and continues to iterate on, many of the hardest problems facing real-time physics simulation.

This investment results in stable stacking of physics bodies, minimal artifacts when you have fast-moving bodies, and generally more controlled behavior, especially when given non-optimized collision geometry.

Example demonstrating the stable stacking functionality of Havok Physics.

Because Havok Physics caches different state information to perform intelligent optimizations, it can achieve superior performance in large-scale (e.g., open-world) games. Havok Physics also offers greater stability by handling interpenetrating objects and endless stacks with an advanced friction model.

Unity Physics (right) attempts to resolve the static/dynamic interpenetrating rigidbodies in a single frame, while Havok Physics (left) can smoothly resolve the setup over a number of frames.

Visualization and debugging

The Havok Visual Debugger (VDB) application is a robust debugging tool for Havok Physics simulations. Connecting over TCP/IP to your application, it allows you to diagnose difficult behavior, performance problems, or crashes remotely. While connected, your application exposes a host of capabilities for the VDB user to turn on/off based on the problem they are trying to solve. If configured, your application creates a server offering information to connected VDB clients.

The Havok Visual Debugger UI

The Visual Debugger has been an essential tool for the development teams on every game powered by Havok Physics. The modular viewers can be selectively enabled and allow users to:

  • Pause and scrub back to see previous interactions in the simulation
  • Examine performance statistics both graphically and textually
  • View the Colliders that make up the rigidbodies in the physics world
  • View the Joints and Contacts between bodies
  • Visualize the motion paths of bodies over time
  • See the (de)activation status of dynamic bodies
  • See a heatmap of the simulation to pinpoint expensive areas requiring optimization immediately
  • Interact with the physics simulation directly

The VDB client can also record, save, and load previous snapshots of a simulation for review. These snapshots have been an invaluable resource when developers need external support to help debug complex physics scenarios.

Two physics engines, one data format

As we described earlier, one of the key goals when we started working on the DOTS Physics initiative was to have a single data representation that could be used across any simulation back-end. By providing a unified editor data layout, developers can author tooling, gameplay code, and other systems that are agnostic to the simulation back-end. We wanted to give control back to you, the creators, to use the simulation back-end that suits your needs without having to reauthor all of your content. The following diagram illustrates the data layout model.

Flow of physics data in DOTS

As you can see, the data flows from authoring through to the simulation systems. At the root level, we abstract our authoring data to be system agnostic, which allows us to build the same tools and user experience across both simulation back-ends. This is then piped through our conversion pipeline into Entity Data. In the Entity Data bucket we have our runtime components such as PhysicsCollider, PhysicsVelocity, PhysicsMass, PhysicsDamping, PhysicsGravityFactor, and PhysicsCustomTags. These are passed into the Build Physics World system, which acts as a second conversion step to convert data optimized for contiguous access into data that is optimized for random access. This system produces a Collision World, which is used for querying the state of the world at the current point in time, and a Dynamics World, which holds all the information needed to simulate physics for the current time step. By separating these worlds, we can perform query operations on the Collision World at the same time the Step Physics World is updating the data held in the Dynamics World, allowing for maximum thread utilization.

As indicated in the diagram, both Unity Physics and Havok Physics share the same data throughout the pipeline. As such, you benefit from not only a unified content pipeline, but also a data protocol and API surface that is system agnostic. Moving between the two different back-ends is an effortless process.

As we move forward with DOTS Physics, we envision a future where Unity can offer a wide array of simulation back-ends to meet various use cases while maintaining a unified authoring experience across all of these physics systems.

Live switching between physics back-ends while in Play mode

Getting started with Havok Physics

If you’re still with us, you’re probably thinking, “Alright! Enough with the technical jargon – how can I get this?” The good news is you can download the Havok Physics integration as a Preview package via the Unity Package Manager (Unity 2019.1 and later). You can also read through the Havok Physics for Unity documentation.

If you’d like to engage with the team, raise any issues, or show us the cool things you’re creating with Havok Physics, drop by our new DOTS Physics forum!

25 replies on “Havok Physics in Unity”

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.