NVIDIA PhysX plugin - preview

Unity Engine
1

Hi everyone,

We’ve prepared a Unity package to enable access to NVIDIA PhysX SDK 4 from within Unity.

Currently the plugin is in alpha, but we’d like to share it with the community to gather initial feedback before we release it wider.

The current plugin version is tested with Unity 2018.2+ (.Net 4.x) and supports Windows x64.

Please find the package here:
https://drive.google.com/uc?export=download&id=1EQnNefll9Ft9dCqJ2jnprDt3GFu9I5uA

Feel free to leave your feedback here.

The plugin largely replaces the existing Physics Components in Unity with a Px* version that exposes a similar interface.

Notable PhysX 4 improvements include more accurate TGS solver and more robust reduced coordinates articulation.

We do not recommend using this for any production projects, it is meant for experimentation and early research into new PhysX 4 features.

Unity has released their own editor version that enables PhysX 4 here:

The key difference is that this package can be imported to any supported Unity version and exposes a new set of components rather than replacing the original ones.

Viktor
NVIDIA

-------------- Update 25.06.2019 -----------------------------------------------------------

Hi everyone,

We’re ready to share a different approach to exposing NVIDIA PhysX 4.1 inside Unity: we now have a low-level C# interface directly to the PhysX 4.1 API.

NVIDIA.PhysX.4.1.unitypackage (10.4 MB)

With this you can build custom physics simulations directly accessing the PhysX SDK, instead of accessing higher level physics components like RigidBody and BoxCollider. This also should provide significantly higher performance and object counts than was possible with the previous approach.

The package comes with samples that show some basic PhysX scenes, and most of the PhysX SDK documented in NVIDIA PhysX SDK 4.1 Documentation — NVIDIA PhysX SDK 4.1 Documentation is exposed in the NVIDIA.PhysX namespace.

Please refer to the sample scenes and the sample code to see how to setup PhysX scenes.

This is meant as an early preview, we are working on exposing PhysX Immediate Mode and making a set of easy-to-start physics game object components on top of PhysX API.

Vitkor
NVIDIA

21 Likes
2

Thx! Can you expand “exposes a new set of components” or include documentation or API link?

3

That new set of components is mostly similar to the Unity physics components, just with Px prefix. Sure, the documentation will follow when the API is more stable.

1 Like
4

That’s great news! Any chance to get a macOS build?

5

Eventually there will be macOS support, as well as all other platforms supported by both PhysX and Unity, but if you mean right now for testing, it will be difficult as I work on Windows and don’t have any Mac nearby.

1 Like
6

Very good to hear!
Let me know if I can be of assistance creating a macOS build

7

Few questions:

  1. any chance to get support for contact modifications built-in? :slight_smile:

  2. you have any plans on sharing the source code for native side PhysX.Native.dll and managed side PhysX.Unity.dll + PhysX.Unity.Editor.dll so people could modify the integration themselves? Would be fancy to get github branch people could fork, especially now that PhysX itself open source on non-console platforms :slight_smile:

  3. what license is this plugin released with?

1 Like
8

I find this entertaining. Almost every time I post a Mac build, there is someone complaining about the whereabouts of a Windows build. Now here we have a Windows build from the ground up… :slight_smile: Happy testing though, it’s all great tech.

1 Like
9
  1. The problem with contact modification is that the contactModifyCallback can be called from any worker thread simultaneously, which makes it quite limited. For example, if I remember correctly, Unity functions can be called only from the main thread. I believe Anthony didn’t implement this feature for a reason. But I’m open for any suggestions how to handle this.
  2. I believe all the source code will be open at some point, but for the moment it’s a little bit too messy. And I’m also not sure I won’t decide tomorrow that I should rewrite everything from scratch.
  3. I’m not deciding this, but probably it will be the same license as for PhysX itself.

The goal of this post is to understand how developers use physics in Unity. What they’re missing, what they don’t like. I can’t just rely on my imagination for this. So the result will depend on your guys feedback, suggestions and requests.

I’ll check what I can do for contacts modifications.

Cheers,
Viktor

4 Likes
10

I’ll try it on 2017.4.23 LTS :wink:

11

On how people would like to use this: I’d like to use physx outside of gameobject scenes, this would let me get more mature physics engine for Unity’s DOTS/ECS world without having to rely on hybrid solution with old unity scene setup.

12

Yes, I was thinking about this too. To expose the lower level API to allow users create rigid bodies, colliders, joints, etc. without creating physics components and game objects. And the traditional physics components would work on top of this API. I can do this if it seems useful.

5 Likes
13

@HerrVR Viktor, any chance you guys port the managed part to the .NET platform outside of Unity environment, so we will be able to use the package with the native plugin for .NET Core servers for example, and Unity for client side in networking games? At the moment my simulations are based on Newton Dynamics, but I would like to give a try to the PhysX wrapped in .NET which supported directly by NVidia.

14

Having “don’t access native Unity components within contact modify callback” limitation would be fine if the plugin itself exposes the direct physx wrappers for this purpose (so one could still get the managed side physx objects for the exposed contact set). How I see it, in most cases you’d code the contact modification logic to run mostly on the callback itself to handle edge cases or implement some functionality that is setup somewhere else already (ie. conveyor belt, normal variance for ground plane to limit jumping on the seams etc) and then enforce the preset rules on the callback.

Unity’s job system could be a nice way to handle the threading too for iterating through the contact set in parallel (if PhysX and Unity allows it) but I’m not sure if you can easily implement this on the plugin side.

I’ve implemented physx contact modifications on c++ few times already, for example I had a UE4 port that did whole physx wrapping for this from start to end ~UE 4.15. UE4 has similar limitation for accessing their engine API only through main thread but this was never an issue for me on contact modifications as I got still a direct access to the physx through the wrappers on the callback.

My main use case with contact modifications is to fix the collision seams throwing off the physics on modular assets (it’s not always trivial to fix it on colliders themselves).

This would be great :slight_smile: Even if it were not supported out of the box but the integration source code were made available, people could implement this on their own as well.

15

Sure, I’ll take this into account, thanks.

4 Likes
16

Ok then, I’ll give it a try.

17

Now, I didn’t have this solved yet because of the performance implications. It’s hard to make this design work at any scale larger than a few contacts reported per frame. It’s a variation of the infamous OnCollisionStay issue, but complicated by threading.

So, the PhysX callback comes during the physics simulation stage from any thread. Translating that directly to Mono used to require a thing called thread binding, to enable script execution on that particular thread. Once the control flow reaches out to scripts, it’s still a miserable position because most of the Unity APIs at the time couldn’t be reached from off the main thread. And finally, there had to be extra hoops jumped through in order to make sure no memory was allocated on the managed heap during this journey. (An extra bonus for making it so that it’s not possible to get into a crash state by messing with what you could still reach out to from within the callback).

I thought a good moment for contact modifications would be when the monolith Physics.Simulate() would be split into proper jobs that could be properly chained. Contact data should be passed to scripts as blobs and iterated from scripts as NativeArrays or so. Immediate mode style.

Just a mem dump here, hopefully helpful perspective still.

3 Likes
18

Thanks Anthony. I’ll still try, just to know what’s happening.

19

Hi, first of all congratulations and thank you very much for sharing this! I don’t think ppl realise how big this is.
It gives me hope to finally be able to run Physx from other thread(I even have developed Physx server prototype as workaroud this problem!).
I was able to set rigidbodies velocity, get data from them and even add force in async fashion, but unfortunately when I run PxNative.SceneUpdate(m_sceneID, .001f) from my thread nothing happens - no errors, but scene objects also seems to not update their positions, any idea how to make it work async?
If you’re interested in open sourcing this project I could help with making this lib to run async as option. Cheers.

20

That’s because scene objects will not update themselves. If you want to do it by hands, you need to take the position of each rigidbpdy from PhysX and put it into corresponding scene object transform. Note also that you cannot (as far as I know) change the gameobject transform from other thread, only from the main thread.

1 Like