Search Unity

Unity 2019.3 beta brings quite a few updates to our PhysX integration. This will make the current implementation more precise, faster, and more robust.

We’ve upgraded the PhysX library to PhysX 4.1 from PhysX 3.4. For more information, see the section “Migrating from PhysX SDK 3.4 to 4.0” in NVIDIA’s PhysX 4.1 SDK Guide.

New solver type

We exposed a new solver type in 2019.3, which is called Temporal Gauss-Seidel. It’s available under Edit > Project Settings, in the Physics category. With this new solver type, joints tend to be more resistant to overstretching and various glitches.

New broad-phase type

We also exposed a new broad-phase algorithm, which is called Automatic Box Pruning. It’s similar to the Multibox Pruning algorithm that’s been available for a while but it can compute the world boundaries and amount of subdivisions automatically. It will maintain the set of grid cells and use the regular Sweep And Prune approach to work out potentially overlapping pairs of colliders. This is intended to help with big scenes where a single Sweep And Prune would be producing lots of extra false positives. This mode is the default broad-phase in PhysX 4.1, but we chose to be conservative and keep it disabled by default. If you want to try it out, enable it in the Physics settings under Broadphase Type.

New mid-phase

Mid-phase is a set of data structures as well as a set of algorithms. These algorithms pick a small set of potentially intersecting triangles of a mesh whenever you run a physics query or when a collider is close to the surface of a mesh. The idea is that a mesh may have a large number of triangles and you don’t want to be running precise checks for each of them, so we build an acceleration structure that allows the algorithm to pick only a small subset that is worth checking.

This acceleration structure is built during the mesh baking for physics, which normally happens when you instantiate the MeshCollider component and assign it its sharedMesh property. Building that structure can take quite a bit of time, and it makes sense to minimize it. The majority of the time spent during this process in older PhysX versions was in constructing the R-Trees.

PhysX 4.1 has a new algorithm in place that doesn’t require any R-Trees. However, the downside is that it can currently only run on Windows, Mac and Linux targets. It is automatically used on Desktop platforms but can be disabled per MeshCollider in the Cooking Options drop-down menu. On unsupported platforms, it will automatically fall back on the old mid-phase algorithm.

Delayed and multi-threaded mesh baking

As we mentioned before, instantiating a new MeshCollider can take time. Now you can pre-bake a Mesh instance for usage with the MeshCollider using the Physics.BakeMesh function. You can hide the computationally intense mesh-baking process behind a loading screen or transition scenes, like a dialog scene in an adventure game or a cut-scene.

An interesting side effect of this function is that you can actually call it from off the main thread, and thereby spread the baking load across all of the available cores. Check the docs for an example of how to use it with the C# Job System.

Removed TerrainCollider thickness and Unified Heightmaps setting

Back in Unity 2018.3, we switched to a more robust contact generation path for TerrainCollider, and changed the contacts generation algorithm. Instead of using a special path to handle the heightmap geometry when computing contacts, this newer algorithm treats a portion of the heightmap in contact as a mesh and utilizes the regular mesh contacts generation code. However, we kept the old code around, and it was still available in the physics settings as the Enable Unified Heightmaps option.

The update to PhysX 4.1 removes the Enable Unified Heightmaps option. On top of that, we’re also removing the thickness setting that was available in the Terrain component properties. Terrain thickness was intended to solve the tunneling effect, where fast moving objects would pass through the terrain surface undetected. Now that thickness is gone, we recommended that you use Continuous Collision Detection instead.

Kinematic re-insertion

When a kinematic Rigidbody is turned into a non-kinematic one, the physics engine will now re-insert it into the broad-phase structures for the purposes of collision detection. This will cause an extra OnTriggerEnter event.


We’ve been focusing on polishing and stabilizing the PhysX integration in Unity, and we hope that this update will bring you improved precision, stability and performance. Get Unity 2019.3 beta to try it out and let us know what you think on the forum

Deixar uma resposta

Você poderá usar estes atributos e marcas HTML: <a href=""> <b> <code> <pre>

  1. Any news regarding concave objects with rigidbodies and more than 255 polygons like it is at the moment ?
    In my company, since we really need concave objects without approximations, we are currently bypassing this limitation by cutting our objects in sub-objects, which really is a pain.

  2. When will the basic feature of having the contacts BEFORE resolved available? Why would anybody want to get the contacts after they are resolved? Any info (penetration distance, speed, etc) is not useful afterwards. We want to anticipate the resolution stage, just as PhysX lets us, so we can CHANGE what it will do. Add additional impulses, forces, changes, or even avoid the contact by chaning the other collider.

    1. I want to stress that too, I always complained about that, it killed one project

    2. Agreed. This is 100% must-have feature.

  3. What’s new or updated in wheel Colliders in the 2019.3 PhysX upgrade?

    1. There are plenty of changes in the SDK itself, but we didn’t get any new features exposed, unfortunately. One little thing that will get back-ported soon-ish is that flag that limits the force applied by the wheel to the car body due to spring damping, available since PhysX 4.1.1.

  4. Cool stuff. But, with Havok coming to Unity I’d really like to know what’s the main reason I’d pick one physics engine over the other. Can you guys make an article comparing between PhysX and Havok? Like a pros and cons?

    1. PhysX is the physics engine used for games when the game code is written with GameObjects / MonoBehaviours.
      Havok or Unity.Physics is used when the game code is written in Unity.Entities.

      Generally speaking Havok is significantly faster and has significantly better simulation stability. But of course given that DOTS and the packages surrounding it are in preview, the choice is really less about do you want to use physx vs havok but rather about do you want to use DOTS for your game code or stay with a stable proven game object / monobehaviour based solution.

      1. Joachim, will game object / monobehaviour eventually be phased out in the future after DOTS become stable or you will keep advancing both?

        1. I think many Unity developers have this same question. I think it would be really clear to anyone if they would say if Dots will replace GameObjects one day or just be another solution to choose from. I have the same concerns back then when Flash was going to die but everyone was about talking around it. We all know what happened, so I think being more clear about Dots and MonoBehaviour situation would help a lot. =)

  5. Cloth physics continue failing since many versions ago.

  6. Great updates, thanks!

  7. More perf is always welcome, thanks!

  8. Tristan Bellman-Greenwood

    outubro 22, 2019 às 9:01 pm Responder

    Do these changes have any effect on raycast queries?

    1. As usual with the PhysX upgrades, some portion of the query engine received a bit of a facelift that allowed to return more accurate results when it comes to thin colliders, large meshes, etc. Performance won’t be affected significantly in this area.

    1. Not sure where this link is supposed take you, but I’ve discovered that the code sample I posted externally and linked to has expired. I should have probably put it on github really. However, it’s now available as part of the API docs, here:

  9. “This will cause an extra OnTriggerEnter event”

    This is very dirty, was this necessary? I can’t imagine a case where this does not introduce unwanted behaviour.

    1. I agree, it seems like it’ll cause trouble. I’d like to know more about the rationale of this decision.

    2. And you’ll be lucky if you remember having read this blog post to understand where the unwanted behavior is coming from.

    3. Its really not that difficult to catch the first event and ignore the second, it really shouldnt impact you.

      1. Yeah, it is not difficult. It is ugly though. It adds a nice touch of amateurism.

    4. This is a change in PhysX SDK itself, not sure it’s possible to roll back really. However, we rolled back trigger-trigger events deprecation for now.

  10. By the way what happened to the manual update of the Physics simulation?
    Has it ever be implemented?

  11. Nice Update.
    I’m a bit worried about this:
    “This will cause an extra OnTriggerEnter event.”
    Isn’t this breaking backward compatibility?