Search Unity

My top-three physics feature requests

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

  1. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,552
    Updated: October 2019

    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

    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.

    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
    upload_2019-8-9_20-37-35.png

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

    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.

    Updated September 2019: already fixed in PhysX 4.1.1:
    4. 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.

    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
     
    Last edited: Oct 7, 2019
  2. yant

    yant

    Unity Technologies

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

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,552
    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,552
  5. Marcos-Schultz

    Marcos-Schultz

    Joined:
    Feb 24, 2014
    Posts:
    290
    @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,552
    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:
    305
    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.
     
    Edy likes this.
  8. Mr_Dan_O

    Mr_Dan_O

    Joined:
    Oct 12, 2013
    Posts:
    345
    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:
    305
    I'm afraid not, that would be a separate thing to expose API-wise which I'm generally not allowed to back-port