Updated: September 2021 This is mostly for @yant, but I decided to post these requests here for public discussion. 1. WheelCollider: Implement PxVehicleSuspensionSweeps This provides contacts beyond the single raycast, allowing the wheels to smoothly climb obstacles. This feature may be configured by just two parameters (reject angles) that should be exposed in Unity somehow. https://docs.nvidia.com/gameworks/c...l/Vehicles.html#wheel-contact-beyond-raycasts https://twitter.com/PierreTerdiman/status/1111286064864522240 https://twitter.com/PierreTerdiman/status/1293910165020844032 https://twitter.com/PierreTerdiman/status/1293922415974678528 https://twitter.com/PierreTerdiman/status/1293924958331179008 Use cases: https://forum.unity.com/threads/how-to-simulate-cargo-loading-using-wheel-colliders.869773/ 2. Floating Origin (a.k.a. Scene Origin) The further away objects move from the origin, the larger the chance to suffer from floating point precision issues. This can cause troubles especially in scenarios with big game worlds. To address this, PhysX offers an API to shift the origin of a scene: https://gameworksdocs.nvidia.com/PhysX/4.1/documentation/physxguide/Manual/OriginShift.html Use cases: https://forum.unity.com/threads/my-top-three-physics-feature-requests.584263/#post-6129512 Update July 2021: Vehicle Physics Pro implements a satisfactory floating origin solution, so this is low priority now. ----------------------------------------------------------------- WheelCollider: Damper produces negative suspension forces. [Fixed in Unity 2020.1] This is a bug. A car suspension cannot produce negative forces (unless it mounts magnets in the wheels and drives over a steel road). Case number: 725365 (2015) Spoiler The fix this should be implemented as a configuration option in Unity (disabled by default). Possibly the bug is already used to enhance gameplay by keeping cars adherent to the road in situations where they would go airborne otherwise. Update September 2019: fixed in PhysX 4.1.1 Update April 2020: exposed in Unity 2020.1 beta Update July 2020: fixed in 2020.1: New option WheelCollider.suspensionExpansionLimited WheelCollider: allow to configure the wheel's sprung mass explicitly [Fixed in Unity 2019.4.15, 2020.1.13 and 2020.2] This change was first requested on 3/13/2014 in the private Unity Alpha forum. One-pager document with the proposed change Configuring the wheel's sprung mass explicitly (WheelCollider.sprungMass, currently read-only) would allow to simulate common situations with vehicles that now require tweaks and workarounds, if even possible at all: Spoiler Center of mass being outside the boundaries of the wheels. This is the case of truck trailers, for example. In this situation, the automatic sprung mass calculation just splits the whole mass evenly between all wheels, which messes up the sprung mass model and causes weird suspension effects. Add-on masses added to the vehicle as rigidbodies with joints. Examples: cargo in trucks, add-on parts (excavator, container carried by a truck), etc. In these cases it's impossible to let the wheels know they have an added mass, and the sprung mass values keep assuming the vehicle is the main rigidbody only. Wheels that don't support any mass. Think on trucks with 3-4 axles, but the rearmost axle being lifted when the truck is not carrying any load. Frequent changes in mass and/or center of mass, for example due to fuel consumption or stabilization systems that are simulated by small changes to the center of mass in runtime (i.e. anti-roll bars). Currently, changing mass or center of mass is very expensive computationally due to the sprung mass being recalculated in each wheel on each change. My request is for making WheelCollider.sprungMass writable and disabling the automatic calculation. It may be a feature similar to Rigidbody.inertiaTensor, which is recomputed automatically but writing it directly disables the automatic calculation. Later, Rigidbody.ResetInertiaTensor may be called to restore the default behavior. Use cases: https://forum.unity.com/threads/how-to-simulate-cargo-loading-using-wheel-colliders.869773/ https://twitter.com/VehiclePhysics/status/1293897582914281478 Reference: known facts about the WheelCollider: https://forum.unity.com/threads/can...ymptote-and-extremum-are.947193/#post-6179013 Collision: expose impulses per contact [Exposed in Unity 2022.1] Having access to the individual impulses per contact would allow to implement precise behaviors based on the collision forces, such as special friction, bouncing and visual effects. Also, it's necessary to implement a true solid 3D wheel model. Spoiler Currently, Collision exposes Collision.impulse, which is a sum of the impulses in all contact points. However, PhysX exposes an impulse per contact point (PxContactPair struct). My request is for exposing the individual impulses per contact (a new member in ContactPoint) instead of, or in addition to, the summed collision impuse. Use cases: https://forum.unity.com/threads/get-collision-impulse-without-oncollisionenter.935981/#post-6116324 https://forum.unity.com/threads/inconsistency-with-collision-impulse.936728/ Bug report(s): https://fogbugz.unity3d.com/default.asp?1265352_hdbl7i2v5ulcmliq Update August 2021: Exposing per-contact impulses is expected in Unity 2022. Update September 2021: Available since 2022.1.0a10.