Unity 2021.2 beta contains usability improvements to the physics features that enable new use cases while providing easier authoring and faster debugging in the field of robotics.
The ArticulationBody component is at the core of our robotics simulation because it enables simulating kinematic chains at high accuracy, which is essential for robotic hands, manipulators, mobile robotics, and much more. We have been listening to user feedback and have made multiple changes to improve performance and usability.
The properties of the ArticulationBody component have been rearranged for better readability. Now, parameters related to mass are in one visual block, followed by the parameters related to anchors and then to drives. These changes have been back-ported to Unity 2021.1 & 2020.3.
The ArticulationBody editor now uses the same joint tools that the regular iterative joints do. This ensures a consistent experience across the Editor. On top of that, it is also possible to edit the limits and anchors of all joints visually.
The joint tools support all of the ArticulationBody joint types, because they have been extended to allow editing of the Prismatic Joint, which wasn’t available before. See this forum thread for more information or to provide feedback.
ArticulationBody has a new setting that allows selecting the collision detection mode. All the continuous collision detection modes are supported, just like with Rigidbody. This was back-ported to 2021.1 and 2020.3 since it was viewed as essential to certain use cases. For example, training a machine learning model to control a humanoid character to walk required enabling the continuous collision detection on the feet as otherwise our model was able to learn how to use the depenetration impulse coming from the feet overlapping the ground to its advantage: moved forward a lot faster than it would have normally, and some flight patterns were discovered too.
Additional variants of ArticulationBody.AddForce have been added to match those in Rigidbody.AddForce. Apply force, acceleration or impulse directly. This eases up migration of pre-existing code from Rigidbody to ArticulationBody.
We improved the clarity of the documentation by explicitly stating boundary conditions and special cases. In this release, we have a new page for the ArticulationBody component.
Based on user feedback, we have also included units of measurement for all of the C#-facing properties of the ArticulationBody component in the docs; see mass, for example.
We continue to invest in making the general physics-related pipelines easier to use, and into providing more flexibility to accommodate various usage patterns. We believe it makes more sophisticated simulations possible, driven by creators now being able to use the extra functionality to understand their field better and thus configuring the simulation to achieve more accurate results.
That being said, the Physics Debugger now supports prefabs properly -- both in the Isolation Mode and in the Context Mode. It allows using the divide-and-conquer design principle to a larger extent now, by observing properties of prefabs in isolation, while the rest of the scene is not shown.
Physics layers are an essential tool in optimizing performance of the collision detection system. Frequently, and especially in the large scenes with many layers, it’s best to disable all collisions first, and enable only the needed ones afterwards. To enable this usage pattern, new buttons were added to toggle collision detection between all layers in the physics settings. This is useful in larger projects where many layers are present, but where you can reduce interactions to a smaller subset of layer combinations to improve performance.
Additional metrics have been added to the Physics Profiler. Now, there are more graphs available, and the textual pane displays more data about the current simulation. Among the new additions are the total number of physics queries, the number of articulation bodies, and the number of transforms synced over the last frame.
A custom profiler module can also be created, to include only the metrics that are needed for a particular project.
Finally, memory usage is now also available as a metric.
The physics batch queries are a way to boost performance of physics queries (like Raycasts for instance) by running them on all the available cores, as opposed to normally where we run them all on the main thread exclusively.
Ideally, the code that depends on the results of a batched query is a C# job itself to maximize the performance boost. However, the main problem preventing this from happening was the fact that the collider hit was reported as a Unity Component (RaycastHit.collider). None of the Unity Components are available off the main thread, so that quite limited the adoption of the batched queries.
To address this, the instance ID of the Collider that was hit is now exposed. Instance IDs can be freely used off the main thread, so it should be no problem to chain the query jobs any longer.
The patch friction mode is the default friction simulation mode in Unity. It’s certainly a compromise towards higher performance rather than simulation accuracy, but it can still be tweaked to get reasonable results within a tight computational budget.
A new improved patch friction mode is now available in the physics settings. It addresses the problem that when more than one friction anchor is generated in a contact pair, the friction forces can be up to two times stronger than predicted by analytical models.
For example, on the following graph, cubes with different dynamic friction are sliding over a plane. The red cubes show the expected final positions as predicted theoretically. The blue cubes use regular patch friction, and seem to travel about half-way to the goal. The green cubes use the new improved patch friction, and approach much closer to the expected values.
The new contact modification API is now available, and we’re collecting feedback on this forum thread. It allows for the customization of the physics engine’s reaction to the contacts. For any contact pair, it is possible to change contact points, limit the impulses applied by the solver, tweak target velocities, and more. Among other usages, it allows making holes in any colliders, creating sticky contacts and various physics-powered conveyor belts. In the example below, the sphere falls through the plane because it ignores the contact points with it (can be made area-sensitive). On the right, a cube is bouncing off the two inclined planes while not rotating -- because the reaction to the contact was customized to exclude rotations.
These improvements ensure users generate more realistic results from their simulations in Unity. Many of these improvements were made based on suggestions or feedback from our community and we invite you to join the conversation. To get started with robotics in Unity, check out some of our examples and demos on the Unity Robotics Hub.