Search Unity

  1. We want you to join us at GDC this year! We've added new sessions to Unity Central, space is limited so sign up now!
    Dismiss Notice
  2. Unity 2017.3 has arrived! Read about it here.
    Dismiss Notice
  3. ARCore is out of developer preview! Read about it here.
    Dismiss Notice
  4. Tell us about your experience here and you’ll get early access to the 2018 Game Studios report + more goodies.
    Dismiss Notice
  5. Be the first to take a peek at upcoming 2D Animation Preview. Drop into the forum and check it out!
    Dismiss Notice
  6. Want to see the most recent patch releases? Take a peek at the patch release page.
    Dismiss Notice

Feature requests for physics in Unity

Discussion in 'Physics' started by PhilSA, Jan 24, 2018.

  1. PhilSA


    Jul 11, 2013
    I really like how the development of Unity physics has been going ever since 5.6. ComputePenetration(), ClosestPoint(), Simulate(), manual transform sync, kinematic contact pairs, multibox pruning, etc.... have allowed me to solve many long-time problems I've had with Unity physics

    However I still have a list of features that I think would be extremely useful:
    • Physics.Sweep(shape, pos, rot, direction, distance, layers, ...)
      I often find myself in a situation where I'd need to sweep test with a convex mesh (a cylinder, most of the time), and this would allow me to accomplish that. This is much different from Rigidbody.Sweep because it can start at a specific pose, and it is not tied to the rigidbody's collision layers or to all of its possible child colliders. It also doesn't have the overhead of requiring a Rigidbody component. A SweepNonAlloc() version would be necessary too.
      The "Shape" parameter could be a new unity struct/class representing a PhysX shape, or just a Collider component if "Shape" would require too many changes
    • Physics.Overlap(shape, pos, rot, layers, ...)
      Similar to the point above, although not as crucial because it could always be replaced by an OverlapBox + a ComputePenetration. But it could be used to overlap test with convex meshes
    • Immediate mode
      ComputePenetration has served me very well in my projects and I am eternally grateful for it, but there are cases where I'd need to have the actual contact points of an overlap at a specific moment in the frame, which I cannot get. Immediate mode would give me that possibility
    • Jobifiable physics API
      This is more of a question than a request, but I wonder how job-compatible unity physics is? Even if actual physics queries are not easily jobifyable, I could still get some massive performance gains if I could get/set rigidbody.position and use rigidbody.MovePosition() through jobs. I guess this would require some kind of "RigidbodyAccessArray"?
    • Expose generic Heightfield Colliders to allow Unity users to build their own custom terrain systems
      I'm actually unsure about this one. PhysX documentation seems to suggest that heightfield colliders are now basically the same as concave mesh colliders in terms of calculations. Is that really true? Is the performance cost really the same?
    @yant I'd be curious to hear your thoughts on these points, if you could spare some time.

    PS: any updates on the rigidbody interpolation bug?
    Last edited: Jan 25, 2018
    Edy likes this.
  2. hippocoder


    Digital Ape Moderator

    Apr 11, 2010
    Also interested in this one in regard to performance.
    Daemonhahn likes this.
  3. yant


    Unity Technologies

    Jul 24, 2013
    Thanks. I'm a bit busy right at the moment, and probably have to return back with a more thorough description, but in short there is this big task on-going where we try to bring you PhysX 3.4 update in the best possible quality. Once done, there is a whole lot of interesting things we'd be pushing out. Immediate mode. Speculative CCD. More async query types. Being more ECS (and thus job/thread) friendly. Less dependences on Components/GameObjects. Multi-scene simulation. Stuff like that is coming, stay tuned for more.
    rizu, JacobSmaga, Daemonhahn and 3 others like this.
  4. rizu


    Oct 8, 2013
    I only now saw this, if you bring out PhysX 3.4, could you please consider using 3.4.1 and implementing PhysX Collision Modification callbacks for the Unity API so we could finally modify these special collision cases outselves?

    The ability to spoof the collision data is priceless: for example when the lean the vehicle towards railing at high speed and you hit the collider seam there, this is classic example you see on many indie racing games where vehicles just bounce to the sky etc as they couldn't solve it properly. Or just think of any other surface leaning object when it reaches collider seam and physx interprets one of the collision pairs contact point as 90 degree normal, another classic example for this is when you do any kind of rolling ball and have a level that has modular ground objects, ball is prone to bounce on parts where colliders has seam/overlap (I'm aware of the workarounds for this with changing contact offsets or using customized collision shapes for situation like these but it's not always easy or feasible solution to do at full project scale). Or ability to limit the collisions impulse on objects that aren't supposed to be 100% rigid (yes, you can do softer collisions with these too). There just are countless edge cases that would be much harder to solve with traditional workarounds. Also the reason why I request 3.4.1 to be used is that it exposes additionally friction and restitution mods for contact modifications.

    At the moment, if you want to have similar control over collisions with Unity and PhysX, you'd have to use shadowed collision triggers for object pairs that you want to have custom collision with and then implement the collision resolving yourself for those, but this is out of reach solution for most of the users here. It also requires way messier setup as need to implement additional kinematic rigidbody with that trigger that follows your actual dynamic rigidbody. Also setup like this would only work with few edge cases, otherwise the complexity of the setup could just get out of hands.