Search Unity

  1. We've closed the job boards. If you're looking for work, or looking to hire check out Unity Connect. You can see more information here.
    Dismiss Notice
  2. We're running great holiday deals on subscriptions, swag and Asset Store packages! Take a peek at this blog for more information!
    Dismiss Notice
  3. Check out our Unite Austin 2017 YouTube playlist to catch up on what you missed. More videos coming soon.
    Dismiss Notice
  4. Unity 2017.2 is now released.
    Dismiss Notice
  5. The Unity Gear Store is here to help you look great at your next meetup, user group or conference. With all new Unity apparel, stickers and more!
    Dismiss Notice
  6. Introducing the Unity Essentials Packs! Find out more.
    Dismiss Notice
  7. Want to see the most recent patch releases? Take a peek at the patch release page.
    Dismiss Notice
  8. Unity 2017.3 beta is now available for download.
    Dismiss Notice

Any plans on exposing more of PhysX to the scripting API?

Discussion in 'Physics' started by EnokV, Oct 2, 2017.

  1. EnokV

    EnokV

    Joined:
    Apr 14, 2016
    Posts:
    47
    There are some geometry / mesh queries in PhysX that haven't made it to the Unity scripting API which forces users(such as myself) to implement ugly workarounds when really, what we need exists in the source, but is simply not available. Why?

    Now I understand that not every little piece of PhysX needs to be exposed just for the sake of it, but having access to the most vital parts of PhysX would definitely solve a lot of problems and prevent headaches.

    Even the CharacterController component in Unity is a stripped version of the PhysX one; which supports arbitrary up(it can be rotated). Why is this functionality stripped in the Unity implementation?

    The PhysX docs states that using a rigidbody over a character controller is a bit of a hack, but the Unity CC is just useless for quite a lot of games. It's not exactly a base that's easy to extend, which it would be if it was fully exposed.

    There is no method provided in Unity to query a volume for triangles, this exists in PhysX, here: http://docs.nvidia.com/gameworks/co...hysx/apireference/files/classPxMeshQuery.html (see findOverlapTriangleMesh).

    There are no ways to get a full contact manifold WITHOUT the resolution, which would make the rigidbody an acceptable candidate. (Although this might be solved in 2017.3b with kinematic-kinematic and kinematic-static pairs, but they're bugged atm so I haven't had the chance to try them out).

    Casts against triangle meshes can be configured to return multiple hits on a single mesh in PhysX, through the Px::eMESH::MULTIPLE flag, but not in Unity. This would be useful.
     
    VergilUa, Edy and PhilSA like this.
  2. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    487
    +1 for this
    I think the key to solving most physics problems in Unity is to just give us a direct translation of the PhysX API as much as possible

    Also I almost never even use "OnCollision" messages anymore, because I always end up requiring more fine-tuned control than that. Most of the time, it's because I need to get all contacts info WITHOUT resolving. I need to have that sequence of events:
    1. FixedUpdate part 1 happens
    2. Get contacts info
    3. FixedUpdate part 2 happens
    4. Resolve collisions
    5. FixedUpdate part 3 happens

    I've managed to solve a bunch of my problems with ComputePenetration but having more control would definitely be very useful. I think I've seen a dev somewhere saying there were plans for replacing the magical monobehaviour collision callbacks with rigidbody events that you can subscribe to, and it would give you more low-level control. This would be a really great addition to the engine
     
    Last edited: Oct 6, 2017
  3. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    887
  4. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    487
    Yes, this solves the problem of having a PreFixedUpdate and a PostFixedUpdate, but it's still impossible to have the "MiddleFixedUpdate" that happens between the contacts generation phase and the collision resolution phase

    Because both the contacts generation and the collision resolution happen within the Physics.Simulate() call
     
    Last edited: Oct 6, 2017
  5. EnokV

    EnokV

    Joined:
    Apr 14, 2016
    Posts:
    47
    First attempt at summoning @yant
     
  6. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    114
    Steve-Tack, VergilUa, EnokV and 2 others like this.
  7. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    887
    yant likes this.
  8. EnokV

    EnokV

    Joined:
    Apr 14, 2016
    Posts:
    47
    Something which would be nice, if you could look into it, would be to expose a triangle property of the mesh collider.

    EDIT: come to think of it, perhaps PhysX doesn't perform any optimization at that level and the collision mesh is an exact representation of the mesh, at which point it'll become redundant maybe.
     
    Last edited: Oct 24, 2017
  9. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    114
    Not sure what you mean, could you elaborate a little?
     
  10. EnokV

    EnokV

    Joined:
    Apr 14, 2016
    Posts:
    47
    A mesh collider consists of triangles, and for collision detection it makes sense to have access to that property, however, if a mesh colliders triangle array is identical to that of a mesh, then it doesn't matter.

    I assumed PhysX perhaps removed triangles that aren't needed, like a quad with 100 triangles could be reduced to 2 and it would then make more sense to work with that, rather than directly from mesh.
     
  11. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    887
    That happens when you mark a collider as "convex". PhysX computes a convex hull out of the triangles, so such quad with 100 triangles will be effectively reduced to two triangles in the collision mesh.
     
  12. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    114
    This is not necessarily true -- as convex MeshColliders are represented as a set of convex faces internally. A convex face may have more than 3 vertices. That's why we don't provide https://docs.unity3d.com/ScriptReference/RaycastHit-triangleIndex.html for convex MeshColliders.

    Now, internally, PhysX would always reorder vertices for better use in the spatial queries. It would also remove some types of the degenerate triangles as well. We take care of that and remap from the PhysX' indices to the original Mesh indices so there's nothing to worry about in this particular case.

    And to clarify on the other topic -- there won't be an optimisation as intense as you describe. This would require to build up some understanding of the Mesh's topology and is unlikely to be runtime code.

    Hope that's useful. :)
     
  13. EnokV

    EnokV

    Joined:
    Apr 14, 2016
    Posts:
    47
    Oh, good to know!
    Yep, you explained it well, thank's. :).

    On another note, I saw "VHACD" on the roadmap, any news on that?
     
  14. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    487
    Really interested in this as well. Concave colliders are usually very problematic, and having VHACD integrated in the engine would help a great deal with educating users to never use concave colliders unless they reaaaaaaaaally have to
     
    Last edited: Oct 27, 2017
  15. logixworx

    logixworx

    Joined:
    Jun 29, 2017
    Posts:
    38
    how about physx hardware acceleration support?