Search Unity

  1. Click here to see what's on sale for the "Best of Super Sale" on the Asset Store
    Dismiss Notice
  2. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice

My top-three physics feature requests

Discussion in 'Physics' started by Edy, Nov 16, 2018.

  1. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,879
    Updated: August 2020

    This is mostly for @yant, but I decided to post these requests here for public discussion.

    1. WheelCollider: allow to configure the wheel's sprung mass explicitly

    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:
    https://forum.unity.com/threads/how-to-simulate-cargo-loading-using-wheel-colliders.869773/
    https://twitter.com/VehiclePhysics/status/1293897582914281478 (THIS ONE CANNOT BE SOLVED WITH SCRIPTING ALONE)

    Reference: all known facts about the WheelCollider:
    https://forum.unity.com/threads/can...ymptote-and-extremum-are.947193/#post-6179013

    2. 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
    upload_2019-8-9_20-37-35.png
    Use cases:
    https://forum.unity.com/threads/how-to-simulate-cargo-loading-using-wheel-colliders.869773/

    3. Collision: expose impulses per contact

    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:
    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

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

    -----------------------------------------------------------------

    Fixed: WheelCollider: Damper produces negative suspension forces.

    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
    Update April 2020: exposed in Unity 2020.1 beta
    Update July 2020: fixed in 2020.1: New option WheelCollider.suspensionExpansionLimited
     
    Last edited: Aug 17, 2020
    StudioTatsu, valarus, mjc33 and 9 others like this.
  2. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    440
    Regarding 1) -- I like the analogy with Physics.ResetInertiaTensor.
     
    hippocoder and Edy like this.
  3. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,879
    Yes, I think a similar method would be a convenient way to implement a writable sprung-mass that preserves compatibility with existing setups.
     
    hippocoder likes this.
  4. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,879
  5. Marcos-Schultz

    Marcos-Schultz

    Joined:
    Feb 24, 2014
    Posts:
    348
    @yant Please take this topic into consideration ... They would be welcome improvements.
    Mostly number 2 and number 3 (in my opinion).
     
    Edy likes this.
  6. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,879
    List updated!
    • PhysX 4.1.1 fixes the bug described at #3.
    • Added #5: Floating origin
     
  7. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    440
    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.
     
    sasa42 and Edy like this.
  8. Mr_Dan_O

    Mr_Dan_O

    Joined:
    Oct 12, 2013
    Posts:
    347
    Well sorry to interrupt, does that mean that we get the "PxVehicleSuspensionSweeps" feature in the said version of Unity? Thanks in advance for replying.
     
  9. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    440
    I'm afraid not, that would be a separate thing to expose API-wise which I'm generally not allowed to back-port
     
  10. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    440
    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).
     
    sasa42 likes this.
  11. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,879
    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.

    So I guess it's exposed in the scripting API only. I'm ok with that.
     
    sasa42 likes this.
  12. mjc33

    mjc33

    Joined:
    Oct 9, 2019
    Posts:
    17
    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
     
  13. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,879
    No, PhysX exposes the flag as "per vehicle". The setFlag method doesn't allow to specify a wheel index.
     
  14. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    440
    What Edy said. Could you elaborate on the issues you observe?
     
  15. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,879
    Last edited: Apr 18, 2020
  16. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,879
    Update: Added links to other posts that describe use cases for these features.

    Edit: Also adding related bug reports.
     
    Last edited: Jul 23, 2020
  17. StudioTatsu

    StudioTatsu

    Joined:
    Dec 31, 2018
    Posts:
    3
    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 likes this.
  18. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,879
    Update: marked "WheelCollider: Damper produces negative suspension forces" as fixed as for the release of Unity 2020.1.
     
  19. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,879
    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:

    upload_2020-8-13_17-1-48.png

    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:
    https://twitter.com/VehiclePhysics/status/1293897582914281478

    @yant
     
    yant and mjc33 like this.
  20. mjc33

    mjc33

    Joined:
    Oct 9, 2019
    Posts:
    17
    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.
     
    Edy likes this.
unityunity