Expanding the robotics toolbox: Physics changes in Unity 2022.1

Simulate sophisticated, environment-aware robots with the new inverse dynamics force sensor tools. Explore dynamics with the completely revamped Physics Debugger. Take advantage of the performance improvements in interpolation, batch queries, and more.

The Physics Debugger is an essential tool for understanding the inner workings of the physics engine, as well as for making sense of the particular behavior observed in a project. A good debugger is a critical tool for authoring convincing, modern, rich physics. With that in mind, we completely reworked the user interface (UI) and added some interesting features.

To fit more information into the same space, we grouped the properties into tabs and then expanded them with the newly added properties.

Before, both Rigidbody and ArticulationBody components had a collapsible “Info” section in the Inspector that you could expand to view additional information, such as the current linear velocity. Once expanded, however, the overall performance of the Editor degraded significantly. In addition, it was previously complicated to compare parameters of different bodies, as you needed to open two Inspector panels. To address these issues, we moved all of the properties to the “Info” tab of the Physics Debugger window, where the properties are displayed for each of the selected objects, so you can easily compare them side by side.

Contact points can now be visualized, alongside the contact normal and the separation distance.

Physics queries, such as Physics.Raycast or Physics.CastSphere, are normally part of some custom physics behavior, such as custom character controllers or vehicle controllers. They’re invisible and tricky to debug. To help with that, this release offers optional visualization of the physics queries.

Until now, Unity had tools that supported only what is called forward dynamics: given a set of objects and the forces applied to them, calculate their trajectories. While this is incredibly useful, we wanted to expand our robotics toolbox. So, Unity 2022.1 adds support for inverse dynamics: given an object and a desired trajectory, calculate the forces that cause that trajectory when simulated.

This effort will span multiple releases, as we build it out iteratively. In Unity 2022.1, we’re exposing a set of functions to calculate the components of the current total force applied to ArticulationBodies that should be counteracted before applying the external force to drive them along the desired trajectory. Further interesting concepts will be exposed in later releases, such as the joint force required to counteract the impulse applied by the solver. We invite you to try this out and let us know what you think on the forum.

In particular, the new functions are:

• get the current force applied to the body by the drive. It’s an indication of how hard a drive is trying to reach the desired drive target. It depends on the stiffness and damping of the drive, as well as on the current delta target position and delta target velocity;
• get the joint forces required to counteract the gravity, Coriolis and centrifugal forces acting on the body; and
• get the joint force required to reach the desired acceleration.

Rigidbody uses both interpolation and extrapolation to give an impression of smooth motion while simulating at a comparatively low frequency. Internally, this is implemented by calculating the transform poses every update. In the case of interpolation, the last two simulated poses are used to calculate a new transform pose for this frame. In the case of extrapolation, the last simulated pose and velocity are used instead. Since it is designed to be lightweight, however, we don’t communicate these poses back to the physics engine. The poses are only presented to the systems outside of physics (e.g., graphics and animation). Because of that, for instance, a raycast won’t detect a body at the interpolated pose.

To keep physics from noticing the transform changes, the mechanism was to have a Physics.SyncTransforms() call each update right before pose write, followed by an internal method call to clear all transform updates for physics. That caused two classes of problems:

If a scene has at least one interpolated body, all the transform changes to all the physics components were synced with the physics engine each update (even though they’re mostly needed once per FixedUpdate); and

If a change was made to a transform that had a Rigidbody component with interpolation on it, interpolation for this object broke because the user-made transform change was propagated to the physics engine and effectively changed the last simulated pose (the pose is not stored separately – it’s just the pose that the physics engine uses currently).

To address these problems, we updated the interpolation code so that it doesn’t need to sync all transforms for each frame. This change also improves performance; the new interpolation code runs faster than before (depending on the scene complexity).

A section of the forum is dedicated to discussing various experimental previews of physics tech, and some of the changes implemented in this release originated there:

• Many projects, especially larger ones, often use many GameObject layers, so the matrix that describes the layer combinations and produces contact pairs for physics becomes quite large too. In this release, we’re highlighting the currently selected row and column so that it’s easier to use.

• A joint is used to link two Rigidbodies, and it defines the constraints on their relative motion. Starting in Unity 2020.2, a joint can also be used to link a Rigidbody to an ArticulationBody. To make that possible, each Joint class received an additional property that is shown in the Inspector. Linking to both Rigidbody and ArticulationBody at the same time is impossible, so displaying both options when one has already been set takes up vertical space for no reason. Now, only the property that was set is displayed.

• A kinematic Rigidbody is a special type of body that can influence other bodies, while not letting anything else affect it. In that regard it’s analogous to a static collider, with the exception that it’s intended to be moved frequently. Typical use cases are character controllers, animation driven physics, virtual reality (VR) simulation of wrists, and so on. It is controlled by setting a kinematic target that the body will reach in just one simulation frame. The main difference with the static collider here is that the kinematic target is reached not by instant teleportation (pose change), but by calculating the linear and angular velocities required to reach the goal in one frame, and passing them to the solver afterwards. That way, the movement can contribute to the constraint Jacobian matrices correctly, and thus any attached joint chain will react properly (no glitches). In this Unity release, we expose a new method to set both position and rotation of the kinematic goal in one operation.
• Contact modification, introduced in Unity 2021.2, enables changing the contact point details as generated by the narrow phase, right before they’re used to create contact constraints for the solver. In this release, we’re adding new getters for body velocities in a contact pair, for advanced use cases such as this example of custom anisotropic friction.
• The PhysX version was updated to 4.1.2, the latest in the 4.x line to date. It’s a minor release, so it only addresses critical bugs and crashes. Release notes are available here.
• When a dynamic body overlaps a collider, the solver aims to find a corrective impulse that pulls them apart while satisfying all the constraints. Internally, this impulse is computed per each contact point in a pair, but we had only an aggregate value that returned a total sum over all points. With this release, we’re exposing a new property of the ContactPoint structure that allows retrieving impulses for each contact point.
• We’re closely watching the feedback about the ArticulationBody component coming from the robotics community. To facilitate creating and tweaking the behavior of some smaller robot parts, we anchored the joint limit handles in screen space so that they will no longer occlude colliders in the scene.

• Physics batch queries were the result of a Unity hackweek and shipped directly to enable certain use cases, but with minimal functionality. They continue to evolve, with new functionality to enable even more use cases, such as those with more sophisticated threading patterns, and the types of queries are more diverse. In this particular release, we’re enabling the batch queries to be run on any physics scene, and we’re adding one new batch query type (Physics.ClosestPointCommand).
• For a mesh to be usable with MeshCollider, it has to be baked first. Baking is an expensive process of producing the spatial search structures required for collision detection. Normally, it happens implicitly every time a MeshCollider’s mesh property is changed, and it runs on the main thread, blocking any further work until complete. In Unity 2019.3, we exposed a thread-safe method to perform bake off the main thread on demand. The intent was to enable more sophisticated procedurally generated meshes, since one could now jobify content generation and mesh bake, gaining much higher thread utilization. However, one particular disadvantage of this function was that it only supported baking with the default cooking options. In this release, we correct it by exposing a new variant of Physics.BakeMesh that supports baking with any cooking options.

We can’t wait to see what you create with the new Inverse Dynamics APIs and the revamped Physics Debugger! Download the latest Unity 2022.1 build today and join the conversation on the robotics forum and the physics previews forum.