Search Unity

The main change Unity 2018.3 brings to physics is the 3D physics engine upgrade, from PhysX 3.3.3 to PhysX 3.4.2. It’s the first time we ship the latest available version of PhysX to date. We aim to improve performance and stability and make it extremely easy for you to upgrade your project. Read this post to learn more about the upgrade and all the specific changes and new features related to working with physics in 2018.3.

PhysX 3.4 represents several years of progress in the area of computational physics. We used to wait for a year or so to let the new version of PhysX mature, before shipping it in Unity. This time around we’re shipping the latest one, after having put as much effort into testing as possible.

We’re also going light on new features this time around, to pay more attention to the core stuff that was already working. We aim at as fewer regressions as possible. Join the Unity 2018.3 beta and try it for yourself!

PhysX 3.4 upgrade

PhysX 3.4 is a big release that brings visible improvement in a whole bunch of various ways. Firstly, it addresses a significant amount of bugs. For instance, it significantly improves convex-convex collision detection and feedback, so that there are no more any odd bumps from the ground when the PCM collision detection is enabled. Physics queries against thin and long tri angles have been improved. Another example is the improved precision of contacts computation with Terrain. Secondly, the physics engine now saturates the threads with physics jobs much better. Broadphase, collision detection and the solver were re-written to be decomposed into as many atomic jobs as possible. As a result, you should see the time it took to simulate a frame to be lower than before.

Thirdly, the physics queries module is now up to two times faster than before.

There are a lot of great new things added to PhysX 3.4, read on to learn more about the features that we support in Unity 2018.3.

Multi-scene physics

We used to have only one physics scene that we populated with all the bodies and colliders from all your Unity scenes. Certainly, there are particular cases where this is limiting, so we have now enabled you to create multiple physics scenes. With that change, you can now specify whether a given Unity scene uses the default physics scene, or needs its own local one. The extra scenes are just like the default one, with the exception that all the usual Physics.* APIs will ignore them, because all the scenes are created completely independent. There is a number of ways to use the extra scenes. You can simulate them with PhysicsScene.Simulate on any frequency (think multiple parts of your world simulated with different frequencies). Another interesting option is to create an invisible physics scene to predict trajectories. This improvement is available to both 3D and 2D physics.

More batched queries

Batched physics queries is a way to run physics queries off the main thread. This API is needed because one can’t execute the usual API from another thread. In Unity 2018.1, we shipped RaycastCommand.ScheduleBatch that helps to compute raycasts off the main thread. In Unity 2018.3, we’re extending this to add the other single-result queries like SphereCast, CapsuleCast and BoxCast. We’re figuring out the technical limitations that prevent us from exposing the multiple-result queries like overlaps and sweeps for future releases.

Enhanced determinism

PhysX guarantees the same simulation result when all the inputs are exactly the same. However, many things are considered “input” from the perspective of the physics engine. One such thing is the physics scene itself. Before 2018.3, it wasn’t possible to destroy the implicit physics scene. One could only destroy all the objects in it, which formally wasn’t enough. With multi-scene physics, this is easy to work around. However, another frequent issue was that adding a new body located somewhere far away and seemingly not interacting with the other objects also had the potential to change the simulation outcome. That was because of the way PhysX in Unity grouped objects internally. This is now possible to overcome by enabling a special option in the physics settings. It’s not free in terms of performance, but it shouldn’t slow your project down significantly.

Unified heightmaps

TerrainCollider used a special collision detection algorithm that revolved around some inaccurate assumptions when computing contacts as well as a few unobvious features alike terrain thickness. In Unity 2018.3, the collision detection approach used is the same as when computing contacts with meshes.

Speculative continuous collision detection

Continuous collision detection has been an option in Unity for a while. However, the linear nature of the process was a common problem. All it did internally was to sweep the bodies some specific distance forward along the velocity vector to compute the time until next hit. This model didn’t allow for rotations support.

The simplest example of a game where that’s problematic is Pinball, where the flippers rotate fast while not being linearly moving at all. This is no longer a problem with the alternative continuous collision detection algorithm added in the 2018.3 release. It works by inflating the contact offsets that affect the generation of contact points. It generates the actual contact manifold once the objects are close enough according to that inflated distance. The predictive linear sweeps are no longer used in that mode, so it tends to be more accurate by detecting overlaps with all sorts of bodies being rotated or moved in a fast manner.

Before:

After:

Directional friction

We’re introducing new friction modes: single-directional friction and two-directional friction. The default friction model works by creating up to four scalar constraints per contact pair. This is the fastest model to compute, and it also converges fast, not requiring too many solver iterations. Both of the single-directional and two-directional friction modes work on a per contact point basis, not per contact pair. It’s potentially more accurate, but also requires more solver iterations to converge and, in case your project generates many contact points per contact pair, it can slow your project down.

No automatic transform syncing in new projects

By default, all the changes to Unity transforms were synced to the physics engine right before they might be needed. That is, every time a raycast is run, every time a simulation is run and so on. Syncing isn’t the fastest operation, and it makes sense to reduce the number of times it’s called. For that reason, we have a setting that turns off all the automatic sync points. You’re responsible for calling Physics.SyncTransforms, as otherwise transforms are synced only right before the simulation (=FixedUpdate).

Another problem with the sync points is that syncing itself can only happen on the main thread. That means, for instance, that you can’t have a raycast that includes syncing. Generally, as Unity becomes a more multi-threaded engine, it’s increasingly more often that new projects need to have the automatic sync points off. That said, we’re changing the default value of Physics.autoSyncTransforms from true to false for all new projects starting this release. This improvement is available to both 3D and 2D physics.

Obtaining contacts without garbage

Getting contacts information has always caused some unavoidable managed heap allocations. The allocations were made to pass in the instances of the Collision structure to the handlers in scripts (=OnContactStay for instance), as well as the arrays of contact points. Depending on the frequency of the events, it could hurt performance of certain projects.

In 2018.3, we introduce a new property Physics.reuseCollisionCallbacks, which is off by default to keep the behavior consistent when you’re upgrading your existing projects. However, if you turn it on, the Collision instances are going to be shared. Effectively, it means that there is only one instance of the Collision class that is reused every time the callbacks are fired. As a consequence of that, there will no longer be any garbage produced. However, the collision information you receive in the callbacks has to be copied manually if needed. This improvement is available to both 3D and 2D physics.

Drive for quality

We have a goal of making this release very easy to upgrade to. To achieve that, we dedicated a lot more hours of testing and reviewing than ever before. First, we’ve sent out builds to early adopters. Then, we’ve made a limited functionality upgrade work in Unity 2018.2 and made it available for testing as a spin-off build during 2018.2 alpha. Afterward, once 2018.2 went public, we’ve started a forum thread and invited enthusiasts to provide feedback. This resulted in a pretty productive discussion with a few bugs fixed, and some features added too. Once 2018.3 beta became a thing, we’ve merged our upgrade branch there, and right now it’s used in more than 10000 editor sessions a week. We’re still looking for feedback though, so join the beta and talk to us on the Physics forum or the 2018.3 beta forum!

32 코멘트

코멘트 구독

댓글 남기기

사용할 수 있는 HTML 태그 및 속성: <a href=""> <b> <code> <pre>

  1. fantasitic software

  2. lolthatdidntworkoutasplanned

    12월 8, 2018 12:30 오전 응답

    lol nope you are not shipping with the latest since 4.0 will be available soon :)

  3. Is there any chance of getting inverted primitive colliders, e.g. sphere, capsule, box colliders that act as containers so things on the outside can get in but anything inside can’t get out. I know this can be done with a mesh with flipped normals and mesh colliders, but with a performance cost.

  4. Well since nobody has asked, does this mean we might actually be able to have physics-based networked character controllers now, or must we continue with the faked raycast stuff?

  5. Great work! :)
    Can’t wait to try out all new features in the full release.

    Quick question: in Nvidia docs it is said that Trigger/Trigger collision callbacks are getting deprecated in PhysX 3.4.2. Will we still receive them in Unity when two Triggers collide?

    1. Yes, I can confirm you’re still going to receive the trigger/trigger events going forward.

      1. Perfect!!

        Is there already an approximate release date for 2018.3 available (when it goes out of beta)?

  6. When is 2018.3.0b11 being released? I’m looking forward to the garbage free collision callbacks in it, as none of my projects will open in the alpha versions which include it. I feel like a little kid waiting for Christmas. :)

  7. Is there somewhere we can read more about Multi-scene physics? Is this already playable with in the 2018.3 beta? I’m curious specifically if this will allow us a new alternative to floating point precision correction issues, especially for a headless authoritative server attempting to control multiple players across vast distances.

  8. Will Physics.BoxCast, CapsuleCast, etc. be updated to support rotating collisions?

    1. Could you elaborate? Not sure I understand the question right I’m afraid. Thanks.

      1. From the blog post:
        “Continuous collision detection has been an option in Unity for a while. However, the linear nature of the process was a common problem. All it did internally was to sweep the bodies some specific distance forward along the velocity vector to compute the time until next hit. This model didn’t allow for rotations support.”

        Physics.BoxCast and CapsuleCast currently share this problem since they only support linear sweeps. I was wondering if these methods will be updated to support continuous collision detection for rotation, perhaps by adding an angular velocity parameter. The blog post makes it sound like the speculative continuous collision detection added in 2018.3 will only be available on rigid bodies, but I prefer using the Physics API in my game because it is more flexible in some scenarios.

        1. Anthony Yakovlev

          11월 20, 2018 10:14 오전

          Sorry for the confusion. As pointed out above, speculative collision detection doesn’t rely on sweeps — it’s a completely different approach based on inflating the contact offsets.

  9. Is there an download for that pool table physics scene example?

  10. This is absolutely magical. thanks for this!

  11. 这些更新听起来很不错!期待Physics.reuseCollisionCallbacks的使用。

  12. This is a great update! Nice one!

  13. Physics.reuseCollisionCallbacks doesn’t appear to be available yet in 2018.3.0b9. What is the ETA for that API?

    1. It’s in 2018.3.0b11 & 2019.1.0a7.

  14. Thanks for the updates , it is going to be a great improvement a quesion i have is when is the unity rigidbody going to have options for quadratic drag??

  15. A good API is nothing without good documentation, the ConfigurableJoint is very powerful but still lacks decent documentation … how come it’s been neglected for so long ?

    https://docs.unity3d.com/Manual/class-ConfigurableJoint.html

  16. Very nice! Thanks a lot!

    When receive contact enter or stay, How we can get contact force ?

    1. Use Collision.impulse. It’s the same as force applied over the span of delta time.

  17. Excellent and directional friction!
    Only thing you could help with is joints. Those things are soo awkward to setup, just trying to simulate some suspension for a dropped car (not a full wheel collider car) seems very hard to work out with spring joints

    1. Thanks for the feedback. As to the quality of joints simulation — we’ll be bringing articulation joints based on Featherstone’s algorithm soon. Those are not as stretchy as the ones we have currently. Concerning the difficulty of configuring the SpringJoint — not exactly sure what you mean by that, but maybe a natural frequency/damping ratio model would work better than raw stiffness/damper value?

      1. Well spring joint seems to just be a loose wobbly spring and not configurable as a suspension arm (or fixed-axis spring) which some might expect or want. Is there any way to recreate a suspension-arm (with local axis) beyond the wheel collider?

        1. Anthony Yakovlev

          11월 13, 2018 2:19 오후

          The SpringJoint is just that — a simple spring that attracts two objects towards each other. What you describe sounds directly achievable with a ConfigurableJoint if you lockout the relative rotations and enable only one degree of local linear freedom.

  18. physX 3.4.2 means better wheel collider too?

    1. Like one that has full wheels not just a downward facing ray?! If only

      1. yeah really hoping that they added ShapeCast or MeshCast into the physics system, that would be a great improvement for wheel collider

  19. Best upgrade to physics for a very long time :) thank you very much (all of this is useful to me in my main project!)

    1. Thanks!