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

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.

 

+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

 

@PhilSA Have you tested the recent additions for implementing a custom physics update loop? (Physics.autoSimulation and Physics.Simulate)

 

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

 

First attempt at summoning @yant

 

@yant Please expose the friction type as well:

http://docs.nvidia.com/gameworks/co.../apireference/files/structPxFrictionType.html

Here's a good example on the type of issues resolved by configuring the friction type:

https://devtalk.nvidia.com/default/...-friction-coefficient-behaviour-in-physx-3-4/

Thank you!

 

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.

 

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.

 

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.

 

Oh, good to know!
Yep, you explained it well, thank's. .

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

 

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

 

how about physx hardware acceleration support?

 

@yant Do you have any spoilers regarding what PhysX/Box2D related stuff will make it into 2018.1 beta, if any?

Also bumping regarding the VHACD question.

 

Bumping this again for VHACD question

Not asking any exact ETA. More like, is it under development or is it a thing sitting at the end of the backlog atm.

 

Is that a way to see what physx api used by Unity? I want to build the exact same logic on server by physx sdk.

 

PhysX 3.4.2 in Unity 2018.3

 

Totally agree as the physx subset limit often requires hacks and fixes that are always fighting an uphill battle of secondary effect, complexity and expense.
Sort of slightly bemused why there is far more exposed in a C# wrapper of the PhysX API?

 

Maybe this could peek your interest? https://forum.unity.com/threads/nvidia-physx-plugin-preview.645004/

 

I will have to give it a look see thanks though
Suppose there will be plans for https://news.developer.nvidia.com/announcing-nvidia-physx-sdk-5-0/ ?