Physics development status and next milestones - May 2025

Unity Engine
, , , ,
1

Hi, everyone! Following up on Unity’s roadmap presentation from GDC 2025 and our 2024 Physics Development Update, the Physics team at Unity is here to share a recap and more details about the latest news regarding the editor’s 3D physics solutions: Built-In Physics (PhysX), Unity Physics, and Havok Physics. For information about 2D Physics, check in with Unity’s 2D team.

What’s New

Several updates and quality-of-life improvements for Unity Physics are now available via Unity 6:

  • We released Incremental Dynamic and Incremental Static Broadphases via the Physics Step authoring component. When enabled, the bounding volume hierarchy inside the broadphase is no longer built from scratch every frame, but incrementally updated from one frame to the next. This can lead to drastic performance improvements for scenes with large numbers of rigid bodies of which only a very small subset changes between frames.

  • There’s a new Collider.BakeTransform function that provides the ability to arbitrarily scale or otherwise transform any collider at runtime efficiently. Also included is a new CompoundCollider.Update function that will allow modifying the shape or transformation of child colliders within a compound collider without having to recreate the entire compound collider from scratch. This will greatly reduce computation time for these dynamic collider cases.

  • Spring and damping parameters for motors are now supported for custom components through baking, and in the Unity Physics API and custom components. This allows you to tweak how a motor moves to reach its target. Use damping to adjust how much overshoot a motor may have when approaching a target, and use the spring parameter to adjust how bouncy it is.

  • An improved Collider Inspector and new functions/components make it easier to analyze, interact with, edit, and uniformly scale physics colliders at runtime.

  • User experience improvements include better ragdoll and joint behavior, improved debug displays, new demos within the PhysicsSamples reference project, and more.

  • The new CollisionWorld.Clone function allows cloning a collision world and deep copying of colliders for robust lag compensation, ensuring independent collision detection for Netcode physics queries over multiple frames.

  • An added “Provides Contacts” option within collider authoring components lets developers enable collision event reporting for rigid bodies.

  • The Physics Debug Display (previously limited to the Editor) can now be enabled in Player builds. This will help debugging physics behavior directly in-game if required.

  • Updated baking code for ConfigurableJoint components now supports motors on all axes, simplifying the creation of custom motorized joints and eliminating constraints for unlocked axes.

  • Added support for substepping to improve solver stability and simulation accuracy. Substepping segments the timestep by the substep count and runs the iterative solver for each of these substeps. Collision detection is only performed on the first substep. To use this feature, set the Substep Count greater than 1 in the PhysicsStep component. By default, the Substep Count is set to 1.

  • We’ve heard from many studios that it can be tedious to set up vehicle simulations within Entities-based projects. To address this, Unity has released an experimental Entities Vehicle Controller compatible with Havok Physics and Unity Physics. The controller will enable creators to quickly develop robust, vehicle-based games targeting low to medium levels of realism. Check out the linked Discussions page above or the package documentation for more information.

Catch the full details about these improvements and more over on the Unity Physics Changelog.

Physics Roadmap

Our roadmap remains stable and on-track for the coming year as we continue to invest in the following areas for Unity 6:

UnityPhysics_DirectSolver_2025-2

ECS Unity Physics: The Unity Physics team is working on a direct solver to address scenarios where traditional iterative solvers fall short – such as simulations involving high mass ratios, stiff joints, and long constraint chains. Unlike iterative solvers (which approximate solutions progressively) the direct solver computes accurate results immediately to enable stable and realistic simulations in cases that are currently challenging otherwise. By combining direct and iterative solvers in a hybrid system, Unity Physics will allow versatility for creating more complex and interactive experiences, from industrial simulations to intricate game mechanics like rope bridges or puzzles as demonstrated above.

All Physics: We’re developing a unified authoring workflow that will allow you to select your preferred physics backend via the Project Settings. Game productions can be unpredictable and sometimes need a different physics engine than what they started with. The need to change backends shouldn’t occur often, but productions have been finding it cumbersome when it does. With this workflow, you’ll be able to switch to the backend you need without having to redo your project.

The first physics backends to land in this feature will include Unity’s Built-In Physics integration (PhysX) and a new offering: Havok Physics for GameObjects. Access to Havok Physics has been included in Unity Pro for some time now for use via Unity’s Entity Component System. This support will soon expand to traditional GameObject users as well, enabling a broader range of productions to make use of one of the fastest, most robust collision detection and physical simulation technologies available today.

In the future, users will be able to further customize their physics setups by integrating custom or third-party solutions (such as PhysX 5 or MuJuCo) as additional physics backends. Further progress on backends and workflow consolidation will continue beyond Unity 6.

Built-In Physics: In our last roadmap update, we asked all of you for your thoughts on the potential deprecation of Unity Cloth. Many of you agree that while work could be done to improve the feature, it has still been helpful overall for your projects. We appreciate all your detailed insights and will no longer consider deprecating Unity Cloth. We’ll share details on next steps here in a future roadmap update.


Help us with your feedback!

We’ve been receiving amazing feedback from the community both online and at events like GDC 2025. Know that we are carefully reviewing your input as always for consideration towards our roadmap.

While we generally request feedback be submitted via the Unity Roadmap site, we’re currently in the process of updating how we display and gather feedback with this system. For the time being, let us know in the comments what physics-related feedback or suggestions you have for us. We’ll post an update once the roadmap site refresh is complete.

Thank you!

We’re excited to hear more from you as you learn and work with physics in Unity! Keep us posted on your physics creations, questions, and thoughts here in this thread / forum or over on the ECS/Physics channels of Unity’s Official Discord. Until next time!

— Ashley

26 Likes
Feedback Request: Deprecation of Unity Cloth
Physics development status and next milestones - May 2024
Thoughts on Unity Physics: Cloth, Vehicle Tools and ECS for All
Kinematic Entities jitter when following player
2

Great changes.
I have a question about the problem of floating-point precision in big-world scenarios: is this problem considered important \ any work underway to solve it?

5 Likes
3

How about implementing Geometry Queries for convex mesh colliders in PhysX?

3 Likes
5

I have been working with 2D physics for a long time now, and whenever I go back to 3D physics to patch an old game I kinda dread it for a couple of reasons.

The biggest one is the lack of support for Callbacks on Disable and similar callbacks on changing layers. Essentially 2D Physics raises OnCollision/TriggerExit calls when two things stops colliding for whatever reason, while 3D physics raises those calls when two still active objects that could collide if they overlapped stops overlapping.

This causes just infinite pain when scripting, because any kind of layer change or disabling of objects will mean that you can’t assume things like “Between two OnTriggerEnter calls with the same two objects, there will be an OnTriggerExit”, or other very natural assumptions.

Is there any chance you could go and fix things like that, and other workflow pains with 3D physics that’s not about stacking one million plates or making hyper-realistic chains, but just simple improvements of making callbacks do things that make sense at sensible times? My general experience with 3D physics is that when I have complained about design issues like this, I have been brushed off with “it’s by design”.

8 Likes
6

Are any of these features available for Unity Built-In physics, or are these capabilities specific to Unity Physics only?

7

I understand that improvements are in progress, but I want to highlight the critical importance of UUM-87199. This performance regression is currently blocking my upgrade path to Unity 6.x. I hope this issue remains a high priority. Thank you.

2 Likes
8

Does the unification of entities and go or the ability to swap physics engine mean other packages using physics query such as cinemachine’s deoccluder will be able to work against both game object and ECS colliders at the same time ?

1 Like
9

eventually yes.

6 Likes
10

Hi there, I had missed this thread until now and had been checking the May 2024 thead, thank you for the updates and news. My favourite line in that news:

Havok Physics for GameObjects

Very keen to get my hands on this. I’ve been trying to piece together when we can expect this to arrive. I understand you probably can’t give any definite ETA’s, but if there is there any info you can share on when we can expect that to land would be great, a loose estimate would be appreciated. As best I can tell by watching the Unite 2025 Roadamp video is that swappable physics engines is slated for 6.x, which I gather means 6.2. But I’m joining the dots a little here, swappable doesnt necessrily mean Havok.

edit: well with news of Havok being removed from Unity’s offering, there goes my hopes on that one.

2 Likes
DOTS development status and milestones + ECS for all (September 2024)
DOTS development status and milestones + ECS for all (September 2024)
11

This looks fantastic, anywhere to see or test it?

1 Like
12

Not yet, but we are working on making this scene available as a sample for the new solver technology we are developing.

5 Likes
13

I would like to know how Physics is going to work in ‘ECS for All’.
Both gameObject and Entity is going to use single physics backend or in different backend?.

Right now they cannot interact with each other.

1 Like
14

I want to belive they will use the same physics backend because every gameobject will basically be an Entity in Unity 7, but I can be orrendusly wrong.

2 Likes
16

How do you know about Unity 7?

17

Following Official discussions, Unity Devs streams and looking at the changes of this year for Unity 6.X. But anyway they can change everything at any moment so don’t take my word as 100% certain.

2 Likes
18

Has there been a update on the ‘physics backend’ option and what is the estimated Unity 6 version for that?

19

It seems like it is coming in Unity 6.5.

20

Thanks but it doesn’t look like that what I am referring to - I meant the “select your preferred physics backend via the Project Settings” mentioned in @ashley_unity’s post.

21

Both the new solver and the “select your preferred physics backend via the Project Settings” were announced to be part of Unity 6.4 at Unite 2025. I assume both have now been delayed to Unity 6.5.