Thank you for sharing! However, everything in this post seems related to Unity Physics / ECS / DOTS. There’s nothing about 2D Physics / 3D Physics / PhysX / Box2D / GameObjects.
Is PhysX included in this authoring workflow, so those using PhysX could switch to another physics backend without any further changes in their project?
Hi, everyone! I’m Ashley, product manager for Physics and DOTS Entities at Unity.
We recently shared roadmap updates for DOTS and Physics over on the main ECS forum, but I wanted to make sure to highlight the physics updates here for you all. While the Physics team is part of Unity’s Data-Oriented Tech Stack (DOTS) group, we take care of most physics-related features – including the 3D physics integration (PhysX) and the physics options for projects using DOTS: Unity Physics and Havok Physics.
What’s New
In short, we’ve released several updates and bug fixes over the past year for Unity Physics, and you’ll be able to benefit from them all in Unity 6 Preview. These updates include:
An improved Collider Inspector and new functions/components to make it easier to analyze, interact with, edit, and uniformly scale physics colliders at runtime.
User experience improvements like better ragdoll and joint behavior, improved debug displays, and more.
Catch the full details about these updates 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:
All physics users: 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.
All physics users: As part of streamlining our physics workflows, we are considering the deprecation of Unity Cloth in a future version of Unity. If your studio/company is using Cloth, please let us know in the comments so we can get in touch about your experience with the feature.
DOTS physics users: A new update to the Unity Physics broadphase is being worked on. You’ll be able to change it to operate incrementally using the PhysicsStepAuthoring component (see parameters Incremental Dynamic Broadphase and Incremental Static Broadphase), and the PhysicsStep Entities components. When the feature is enabled, the bounding volume hierarchy inside the broadphase – used for spatial acceleration during collision detection and for collider queries such as ray and collider casts – 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. Changes to rigid body transformations or colliders are rare. This feature can be enabled for dynamic bodies and static bodies separately, which makes it applicable to large and mostly static worlds with massive numbers of static rigid bodies and a reasonable number of dynamic bodies. By default, this feature will be disabled.
DOTS physics users: Also coming up for Unity Physics is a new Collider.BakeTransform function that provides the ability to arbitrarily scale or otherwise transform any collider at runtime efficiently. There will also be 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.
DOTS physics users: Additionally, 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.
Help us with your feedback!
We’ve been receiving amazing feedback from the community both online and at events like GDC 2024. Know that we are carefully reviewing your input as always for consideration towards our roadmap.
The best way to ensure your feedback is heard is by submitting and voting on ideas within our public roadmap page for DOTS and Physics. Each card on the page can be clicked on to see details and voting options, and all feedback shared here is directly routed to the proper product teams. If you don’t see a card for a topic you’d like to share feedback on: select the “Didn’t find what you were looking for?” card, choose the level of importance for your feedback, and use the text field that pops up afterwards to let us know what’s on your mind.
In particular, we’d need your input on the following:
As mentioned above, we are considering the deprecation of Unity Cloth. If your studio/company is using Cloth – or if you decided to make your own cloth solution – please let us know in the comments! We’d love to learn more about your experience and possibly get in touch to understand the details.
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, the DOTS/Physics roadmap portal, or over on the DOTS/Physics channels of Unity’s Official Discord. Until next time!
It looks like this feature was…suggested by me? It sounds like a solution to this:
When will we got this feature Unity? after Unity 6 Preview or during the Unity 6 preview?
The merging of child colliders into a compound collider has been a perennial issue. Is there a plan to address the authoring of compound collider? Not having control over their creation causes issues for some use cases.
Good feedback. Let’s restart that conversation. I think there was a forum thread about it. I’ll dig it up.
Edit: here it is. I’ll hop over there. 
Hello,
Does that include the unification of the physics back end for entities and game object ? Or is this part of the GO/Entity unification ? Or is this never going to happen ??
I wanted to have a system query both physics world but the Physics.Cast* method are impossible to call from a thread other than the main thread. I get there is a race condition potential and I expected to be able to workaround it by controlling when the physics simulation happen with the information from this thread https://discussions.unity.com/t/648104
Heya! The current solution mainly targets GameObjects and native sdks. The system mentioned by Ashley refers to the ability to swap between different physics integrations while maintaining the same components in your scene. At the moment in Unity 6 we allow disabling PhysX completely via this mechanism (without stripping the Physics Module).
Later down the line we plan to extend this to allow using Unity.Physics with all the bells and whistles to be used with GameObjects, but for this to happen we still need to do quite a bit more in both Unity’s native codebase and the Unity.Physics package.
As for the issue with queries, myself and @Vera_mg have been talking around how to achieve this kind of freedom by having a shallow clone of the current physics world(PxScene in PhysX terms), but this is theory as we haven’t gotten into the internals of the PhysX SDK in order to verify that this is achievable in a performant way.
Cheers,
AlexRvn
Thanks for the answer. I’m currently investigating the possiblity to use System.Threading.SynchronizationContext to delegate the physics call to the main thread from a job. Seems to be working for a single thread, need to try for multithreaded and evaluate perf but I’d be content with this even if perf is not optimal as a temporary measure.
EDIT : Nevermind If I try to use the SynchronizationContext of the main thread, the Post delegate isn’t executed until the next frame. So either I lock my editor in an infinite wait or I don’t get any results in time.
Thank you for sharing! However, everything in this post seems related to Unity Physics / ECS / DOTS. There’s nothing about 2D Physics / 3D Physics / PhysX / Box2D / GameObjects.
Is PhysX included in this authoring workflow, so those using PhysX could switch to another physics backend without any further changes in their project?
Good point! I added clarifiers to show which updates apply to all users or DOTS users. 2D-related physics is owned by Unity’s 2D team, so updates in that regard will come from them.
To answer your question, yes. The unified authoring workflow will be applicable for both DOTS and GameObject users. We’ll be sharing more details on this in a future roadmap update.
One thing I would like to see, if we’re looking for things to improve, is more polymorphism and helper functions between the different collider classes. This would reduce the type-testing and chance for coordinate space mistakes.
Collider.Contains(v) should do the equivalent of Collider.ClosestPoint(v) == v but might be even faster.
Collider.Overlap(...) should do the appropriate Physics.OverlapSphere/Box/Whatever call for you, with the collider’s effective matrix and position arguments.
Collider.Cast(direction, ...) should do the appropriate Physics.Sphere/Box/WhateverCast call for you, with the collider’s effective matrix and position arguments.
Making my own extension methods devolves into a big switch statement on collider types, which is not a good design.
Sorry, I couldn’t hold myself. Not enough control over how colliders are merged makes dots physics barely usable for anything but the simplest of games without tons of workarounds.
(pretty sure folks write their own authoring tools to work around the issue but wouldn’t it be hellanice to have a usable official implementation)
Hi Ashley,
Do you have any new plans for Joints? The current Joints are completely unusable for me (in DOTS ECS)!
I found in your official case: Unity-Technologies/EntityComponentSystemSamples(GitHub) that although the current (last updated in May 2024) Joints have bakers and run in DOTS, they are actually still oriented to GameObject! Because it can only bind two PhysicsBodyAuthoring(only GameObject can access this) objects to connect, and cannot connect two Entities at runtime. Because there is no way to assign Entities to the two connected bodies (LocalBody and ConnectedBody) of “BaseBodyPairConnector”. This is not only a syntax-level inability to assign, but also a different working mode (I believe that Unity’s Baker has done a lot of things to convert the BallAndSocketJoint class to many componentDatas in DOTS), so it is completely impossible for a single person to convert GameObject-type Joints to Entities into ECS for use (that is equivalent to implementing all the ECS codes of Joints myself).
Does Unity know about this problem? I want to dynamically create Joints at runtime in ECS and connect two Entities with physical components in real time. When will Unity provide a sample project for this? Thank you!
Anyone can answer me?
Hi!
Would you mind creating a seperate thread for this and pinging me there?
I’d like to discuss this in more detail to get a better grasp of what the issue is.
Just quickly in case this helps, I believe the ragdolls sample (8. Joints and Motors/Joints - Ragdolls.unity) in the PhysicsSamples project contains joint creation code. It’s done at bake time but the process is the same: adding the same components but simply at runtime.
Thanks!
@MildlyInfuriating:
Just to confirm my understanding, I believe you are talking about the automatic creation of compound colliders during baking, right?
@halley : there might be a misunderstanding as to what the Collider.OverlapBox/Sphere/Capsule functions do.
These functions do a query between the current collider on which you are calling this function, irrespective of its type which can be even a mesh type or a compound, and a simple box, sphere or capsule with the given parameters.
The “polymorphism” you are looking for, happens under the hood and the call is redirected automatically to the specific implementations of these functions with the respective collider types, e.g., ConvexCollider.OverlapBox/Sphere/Capsule or CylinderCollider.OverlapBox/Sphere/Capsule etc.
Same for the other methods with Box/Sphere/Capsule.
The confusion is likely due to the method documentation, which is very short and not very helpful. Apologies for that.
With that said, what functionality are you looking for?
As far as I know, there is no public Collider.Overlap(). There is only Physics.OverlapBox() etc. There is no Collider.Contains(v) nor Collider.Cast() either. There should be, but there isn’t.
I want to call myCollider.Overlap() and have it figure out the derived-class appropriate API and call Physics.OverlapBox() or sphere or whatever for me, with the appropriate orientation center size etc, from the collider and transform itself. And if an artist changes the value of myCollider to some other shape, it wouldn’t break.
If I make an extension method on this Collider collider, I have to do an ugly switch statement on supported types, and figure out each type’s appropriate arguments for the Physics API. My request is to make the public API support the polymorphism you are describing.