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. In the Entity Data bucket we have our runtime components such as PhysicsCollider, PhysicsVelocity, PhysicsMass, PhysicsDamping, PhysicsGravityFactor, and PhysicsCustomTags. This is then piped through our conversion pipeline into Entity Data. 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.

You can switch between either solver without having to reauthor all of your content completely.Īs you can see, the data flows from authoring through to the simulation systems. Ultimately, there is no right or wrong choice, as we illustrate later in this blog post. For some, Unity Physics will suffice, while others will want the benefits and enhanced workflows of Havok Physics. 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 that reason, we knew Havok would be the perfect solution to integrate into Unity for those high-end simulation needs. We also knew that some of you would have more complex simulation requirements, needing a stateful physics system.

Through our partnership with Havok, we were able to leverage DOTS to deliver the highly optimized, stateless, entirely C#, and performant Unity Physics.

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.

Unity havok physics sdk