My top-three physics feature requests

[Edy]

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 could be configured in Unity in the same way as WheelCollider.ConfigureVehicleSubsteps does with the vehicle substeps.

Vehicles — NVIDIA PhysX SDK 3.4.0 Documentation

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:

How to simulate cargo loading using Wheel Colliders?

Hi, I’m trying to do something simple, load something heavy on a truck, which is simulated using WheelCollider. The truck has a mass of 5000, and the cargo has a mass of 3000. The problem is that every time the truck climbs on a step (for example, the curb), the WheelCollider is teleported upwards, and this throws the truck upwards, which in turn makes the load jump. The problem is best illustrated in the image below. [image] Both Rigidbodys have the same type of simulation, (Interpolate =…

Weird wheelcollider behaviour

Hello, I have run into some unexpected stuff while using a wheelcollider. I recorded a short clip of what I mean by this. There is no parameter to set the collider size for it’s physical interactions, so any time you add a model to the collider, it looks very bad when partially clipping, or even passing through obstacles. I was wondering how i would go about fixing this? I want to achieve the suspension gradually adjusting as the wheel rolls onto an obstacle, not to only adjust when the little …

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:

NVIDIA GameWorks — NVIDIA GameWorks documentation

Vehicles also have their own origin shift method:

NVIDIA(R) PhysX(R) SDK 3.4 API Reference: Vehicle

Use cases:

My top-three physics feature requests

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)

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

PxVehicleWheelsSimFlags and corresponding set/get methods have been added to PxVehicleWheelsSimData. The flag eLIMIT_SUSPENSION_EXPANSION_VELOCITY can be used to avoid suspension forces being applied if the suspension can not expand fast enough to push the wheel onto the ground in a simulation step. This helps to reduce artifacts like the vehicle sticking to the ground if extreme damping ratios are chosen.

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:

• 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:
How to simulate cargo loading using Wheel Colliders?
https://twitter.com/VehiclePhysics/status/1293897582914281478

Reference: known facts about the WheelCollider:
Can anyone point me to some resources that go into the maths of what Asymptote and Extremum are? - Unity Engine - Unity Discussions

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.

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:
Get collision.impulse without OnCollisionEnter - Unity Engine - Unity Discussions
Inconsistency with Collision.impulse

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.

[yant]

Regarding 1) – I like the analogy with Physics.ResetInertiaTensor.

[Edy]

Yes, I think a similar method would be a convenient way to implement a writable sprung-mass that preserves compatibility with existing setups.

[Edy]

@yant list updated!

[Marcos-Schultz]

@yant Please take this topic into consideration … They would be welcome improvements.
Mostly number 2 and number 3 (in my opinion).

[Edy]

List updated!

• PhysX 4.1.1 fixes the bug described at #3.
• Added #5: Floating origin

[yant]

fwiw physx 4.1.1 will be rolled out in 2019.3 too - just maybe not in the initial release, but will definitely be there, as it has plenty of other bugfixes too.

[imDanOush]

@yant

fwiw physx 4.1.1 will be rolled out in 2019.3 too - just maybe not in the initial release, but will definitely be there, as it has plenty of other bugfixes too.

Well sorry to interrupt, does that mean that we get the “PxVehicleSuspensionSweeps” feature in the said version of Unity? Thanks in advance for replying.

[yant]

@imDanOush

Well sorry to interrupt, does that mean that we get the “PxVehicleSuspensionSweeps” feature in the said version of Unity? Thanks in advance for replying.

I’m afraid not, that would be a separate thing to expose API-wise which I’m generally not allowed to back-port

[yant]

Concerning (3) – 2020.1a15 will have a new WheelCollider property WheelCollider.suspensionExpansionLimited which is a direct interface to the PhysX 4.1’s eLIMIT_SUSPENSION_EXPANSION_VELOCITY flag, This is off by default, just to stay conservative here. We can make it on by default in the upcoming versions if it makes sense. Let me know what you think.

Edit: this flag is set per vehicle, not per wheel (the same way as ConfigureVehicleSubsteps).

[Edy]

@yant

Concerning (3) – 2020.1a15 will have a new WheelCollider property WheelCollider.suspensionExpansionLimited which is a direct interface to the PhysX 4.1’s eLIMIT_SUSPENSION_EXPANSION_VELOCITY flag, This is off by default, just to stay conservative here. We can make it on by default in the upcoming versions if it makes sense. Let me know what you think.

Thanks for the update!

I totally agree on being conservative with this option. While enabling it provides an actually realistic suspension, the behavior of existing cars will be likely modified if their damper values are large enough.

I suspect this flag might also provide stable cars on setups that cause bouncing and shaking cars today. If this were the case, it would be a good reason to have enabled it by default at some point.

@yant

Edit: this flag is set per vehicle, not per wheel (the same way as ConfigureVehicleSubsteps).

So I guess it’s exposed in the scripting API only. I’m ok with that.

[mjc33]

@yant

Edit: this flag is set per vehicle, not per wheel (the same way as ConfigureVehicleSubsteps).

Is there any way to control it on a per wheel basis? I have some side effects with it enabled on my two-wheeled bike vehicle and would like to turn it on in specific situations for each wheel

[Edy]

@mjc33

Is there any way to control it on a per wheel basis? I have some side effects with it enabled on my two-wheeled bike vehicle and would like to turn it on in specific situations for each wheel

No, PhysX exposes the flag as “per vehicle”. The setFlag method doesn’t allow to specify a wheel index.

[yant]

@mjc33

Is there any way to control it on a per wheel basis? I have some side effects with it enabled on my two-wheeled bike vehicle and would like to turn it on in specific situations for each wheel

What Edy said. Could you elaborate on the issues you observe?

[Edy]

Just for the record, here’s a clear example of the need for the features 1 and 2:

How to simulate cargo loading using Wheel Colliders?

Hi, I’m trying to do something simple, load something heavy on a truck, which is simulated using WheelCollider. The truck has a mass of 5000, and the cargo has a mass of 3000. The problem is that every time the truck climbs on a step (for example, the curb), the WheelCollider is teleported upwards, and this throws the truck upwards, which in turn makes the load jump. The problem is best illustrated in the image below. [image] Both Rigidbodys have the same type of simulation, (Interpolate =…

[Edy]

Update: Added links to other posts that describe use cases for these features.

Edit: Also adding related bug reports.

[StudioTatsu]

@Edy

5. 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

This is the biggest issue I have at the moment. I solved the wheel collider issue with a custom solution, but huge worlds cause major issues.

Great list @Edy .

[Edy]

Update: marked “WheelCollider: Damper produces negative suspension forces” as fixed as for the release of Unity 2020.1.

[Edy]

I’ve reached a point were I do really need writable sprungMass (point 1). WheelCollider produces a huge suspension force even when banked nearly 90 degrees:

This problem cannot be fixed from the scripting side. I just need the sprungMass value in the WheelCollider to be read/write, just as is in PhysX. This is a critical parameter for serious simulators.

Thread on Twitter:

Vehicle Physics (@VehiclePhysics) on X

@yant

[mjc33]

I agree with Edy, I’m having the same issues and they’re particularly relevant as my sim is a bike simulation. I have also found that the new option in 2020 to remove negative suspension forces causes the above issue to be accentuated as well as instability of the vehicle in every situation I’ve tried. My own solution to estimate and apply a force opposite to the negative force works better, but I can’t apply this directly to the wheel collider because of parameters being read only, I have to apply it to a rigidbody attached to the frame/chassis by a fixed joint in the approx location of the wheel.