Search Unity

  1. Unity Asset Manager is now available in public beta. Try it out now and join the conversation here in the forums.
    Dismiss Notice
  2. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  3. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

NVIDIA PhysX plugin - preview

Discussion in 'Physics Previews' started by HerrVR, Mar 15, 2019.

  1. HerrVR

    HerrVR

    Joined:
    Mar 15, 2019
    Posts:
    41
    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:
    https://forum.unity.com/threads/physx-4-0-in-unity-experimental-builds.634960/

    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 https://gameworksdocs.nvidia.com/PhysX/4.1/documentation/physxguide/Index.html 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
     
    Last edited: Jun 25, 2019
  2. AlanMattano

    AlanMattano

    Joined:
    Aug 22, 2013
    Posts:
    1,500



    Thx! Can you expand "exposes a new set of components" or include documentation or API link?
     
  3. HerrVR

    HerrVR

    Joined:
    Mar 15, 2019
    Posts:
    41
    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.
     
    hippocoder likes this.
  4. tjmaul

    tjmaul

    Joined:
    Aug 29, 2018
    Posts:
    467
    That's great news! Any chance to get a macOS build?
     
  5. HerrVR

    HerrVR

    Joined:
    Mar 15, 2019
    Posts:
    41
    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.
     
    hippocoder likes this.
  6. tjmaul

    tjmaul

    Joined:
    Aug 29, 2018
    Posts:
    467
    Very good to hear!
    Let me know if I can be of assistance creating a macOS build
     
  7. rz_0lento

    rz_0lento

    Joined:
    Oct 8, 2013
    Posts:
    2,361
    Few questions:

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

    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 :)

    3) what license is this plugin released with?
     
    goncalo-vasconcelos likes this.
  8. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    594
    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... :) Happy testing though, it's all great tech.
     
    TokyoWarfareProject likes this.
  9. HerrVR

    HerrVR

    Joined:
    Mar 15, 2019
    Posts:
    41
    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
     
  10. Vytek

    Vytek

    Joined:
    Apr 29, 2016
    Posts:
    51
    I'll try it on 2017.4.23 LTS ;-)
     
  11. rz_0lento

    rz_0lento

    Joined:
    Oct 8, 2013
    Posts:
    2,361
    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. HerrVR

    HerrVR

    Joined:
    Mar 15, 2019
    Posts:
    41
    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.
     
  13. nxrighthere

    nxrighthere

    Joined:
    Mar 2, 2014
    Posts:
    567
    @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. rz_0lento

    rz_0lento

    Joined:
    Oct 8, 2013
    Posts:
    2,361
    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 :) 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. HerrVR

    HerrVR

    Joined:
    Mar 15, 2019
    Posts:
    41
    Sure, I'll take this into account, thanks.
     
  16. HerrVR

    HerrVR

    Joined:
    Mar 15, 2019
    Posts:
    41
    Ok then, I'll give it a try.
     
  17. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    594
    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.
     
    hippocoder, rz_0lento and Cynicat like this.
  18. HerrVR

    HerrVR

    Joined:
    Mar 15, 2019
    Posts:
    41
    Thanks Anthony. I'll still try, just to know what's happening.
     
  19. Roni92pl

    Roni92pl

    Joined:
    Jun 2, 2015
    Posts:
    396
    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. HerrVR

    HerrVR

    Joined:
    Mar 15, 2019
    Posts:
    41
    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.
     
    Roni92pl likes this.
  21. Roni92pl

    Roni92pl

    Joined:
    Jun 2, 2015
    Posts:
    396
    Yes you can, Im already doing this ;) Thanks for answer! Really appreciate this project.
    Now nothing stops me from doing virtually everything asynchronous to Unity/render thread.
     
  22. Ruchir

    Ruchir

    Joined:
    May 26, 2015
    Posts:
    933
    Will this will support the new ecs framework because the unity physics didn't seem impressive really and the havok one will be a pain option ,so it will be best if physx 4 is supported in the DOTS framework:)
     
    JVene likes this.
  23. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    594
    You can, via jobs, TransformAccess and TransformAccessArray: https://docs.unity3d.com/ScriptReference/Jobs.TransformAccessArray.html
     
  24. HerrVR

    HerrVR

    Joined:
    Mar 15, 2019
    Posts:
    41
  25. HerrVR

    HerrVR

    Joined:
    Mar 15, 2019
    Posts:
    41
    @yant As I understand user will be able to swap easily between Unity Physics and Havok Physics. Will it be also possible to make SomeOtheR Physics with the same interface and use it?
     
  26. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    594
    There's a data contract between Unity Physics (the C# thingie) and the Havok for Unity, that's how you get interoperability. I doubt PhysX as it is now can do that, because it's not DoD at all.

    The GameObject-based Unity Physics (Collider, Rigidbody - that stuff) can only be migrated to the new Unity Physics with the help of a one-way translation tool that's now being built AFAIK.
     
    Edy likes this.
  27. HerrVR

    HerrVR

    Joined:
    Mar 15, 2019
    Posts:
    41
    Last edited: Mar 20, 2019
  28. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    594
    We have to bear in mind I'm not the author of Unity Physics and thus won't be able to comment on how easy it is to make Immediate Mode crunch through the Unity Physics data. I can only say that I built a stateless thingie with Immediate Mode at a Hackweek about a year ago, it was alright (however certain moments where you pass in an allocator to let the SDK store some unsized friction data was a bit against pure DoD I recall).
     
  29. HerrVR

    HerrVR

    Joined:
    Mar 15, 2019
    Posts:
    41
    I just want to understand if I got the idea right. We have Unity Physics data and a set of functions: stateless (Unity C#) or with (optional?) caching (Havok) to process this data. The question is will be there a way to add another set of these physics data processing functions, or will it be hardcoded to only Unity/Havok? Sorry for bothering you :)
     
  30. rz_0lento

    rz_0lento

    Joined:
    Oct 8, 2013
    Posts:
    2,361
    I'd love to have custom option on the Unity Physics for this kind of use as well. It is currently hardcoded in Unity.Physics.SimulationType but could be easily extended.

    Would be nice if Unity Physics would go to github as it would make it trivial to fork and extend it for this kind of purposes.

    In the bigger picture, it would be best if users could use PhysX option for DOTS too but it seems like there's some politics involved in this choice.
     
  31. rz_0lento

    rz_0lento

    Joined:
    Oct 8, 2013
    Posts:
    2,361
    Also worth noting that since Unity Physics will allow cached implementation for full Havok, I don't really see issue on doing a PhysX implementation that isn't stateless either. In ideal world, we'd get options (stateless setup built on PhysX immediate mode and cached setup using regular PhysX scene setup).
     
  32. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    594
    Fair enough. Those aspects aren't exactly in my control actually. It's my understanding that the dots physics folks will come and reveal all the details eventually.
     
    rz_0lento likes this.
  33. Roni92pl

    Roni92pl

    Joined:
    Jun 2, 2015
    Posts:
    396
    What are the plans for this lib? Do you have any documentation? Im trying to figure out collision callbacks.
    Edit: And raycasts :D
     
    Last edited: Mar 20, 2019
  34. HerrVR

    HerrVR

    Joined:
    Mar 15, 2019
    Posts:
    41
    Current plan is to gather some user feedback.
    No documentation yet, but there are some sample scenes.
    The sample scene 'Collision' shows how to work with collision callbacks.
    And, it looks like I forgot to make raycasts :) Will add them with the next update.
     
    Marcos-Elias and Roni92pl like this.
  35. JVene

    JVene

    Joined:
    May 26, 2018
    Posts:
    2
    I'm a tad late to this thread.

    I need the Physx 4.x articulated joints for a product. I've gone so far as to reconsider other engines to get Physx 4.x, and I loaded Physx 4.1 SDK to study and verify the articulated joints are exactly what I required (robotic arms in particular).

    I was about to cobble together an experiment of building Physx 4.1 as a native module for Unity when I discovered Unity's 2019.1 beta has preview access to the new Unity Physics engine and Havok. Unfortunately I must drive toward a product so I can't really wait for that to mature (for example, it is not stable for stacked objects yet), and Havok is still a mystery license. They once offered Project Anarchy where the base of the Havok physics engine was available for free to indie developers on mobile targets, but it was unstable (their releases were more like alphas) and subsequently dropped.

    Put another way, by way of feedback, if NVIDIA, Unity or someone else were not offering a way to plug in late builds of PhysX 4.x (and ongoing) for Unity, some of us out here were about to try doing that ourselves.

    The update in recent Unity builds to PhysX 4.x is fine, but I don't see they expose the articulated joints I require, so this is a far better option (and ongoing, would continue to be as PhysX advances).

    I loaded the package (on 03-26-19), and the results were effortless so far (by comparison to what I was planning, and I'm an old hand with decades behind me, so I'm accustomed to things requiring lots of work).

    Despite Unity's new direction with physics, which are certainly interesting, this package is exactly what I need right now. Though you (HerrVR/Viktor) warned this isn't recommended for production, I see no real obstacle yet.

    I'll "stay tuned", but if there were never anything else updated or offered, I'd would (and probably will) start building the target product using this package right now (happily working around any minor 'gotchas' for now).
     
  36. Marcos-Elias

    Marcos-Elias

    Joined:
    Nov 1, 2014
    Posts:
    159
    Is it possible calling shiftOrigin function with this plugin, and does it support wheel colliders?

    If so, I'll try this to replace the current Unity's implementation, since it is very limited to a small world size. We don't have a way to call PhysX shiftOrigin function on Unity, afaik. And moving everything in a single frame is so bad when we have lots of colliders...

    Basically it seems that we need this function to enable truly open world, but unfortunately Unity does not expose it:
    http://gameworksdocs.nvidia.com/PhysX/4.0/documentation/PhysXGuide/Manual/OriginShift.html
     
    Last edited: Mar 26, 2019
  37. HerrVR

    HerrVR

    Joined:
    Mar 15, 2019
    Posts:
    41
    It's not yet recommended for production because it still can change significantly and all your setups may not work with the next version. Beside this, one of the main focuses of PhysX 4 is robotics, so I believe it should work for you.
     
  38. HerrVR

    HerrVR

    Joined:
    Mar 15, 2019
    Posts:
    41
    I can add shiftOrigin. For wheel colliders, I've never used them so I'll need to learn what is it first.
     
    Marcos-Elias likes this.
  39. Marcos-Elias

    Marcos-Elias

    Joined:
    Nov 1, 2014
    Posts:
    159
    Nice, if it is possible adding it, thanks in advance! Maybe it may help Unity implementing it as well.
     
  40. Ruchir

    Ruchir

    Joined:
    May 26, 2015
    Posts:
    933
    Will there be gpu rigid bodies ?:)
     
  41. HerrVR

    HerrVR

    Joined:
    Mar 15, 2019
    Posts:
    41
    Yes. It already works in current version. PxScene has an option to simulate on GPU.
     
  42. JRoachie

    JRoachie

    Joined:
    Apr 5, 2013
    Posts:
    1
    oh hi,

    is this plugin still going to be updated? it's possible to integrate it with the ECS workflow, it's just lacking support for features like casts and collision queries.

    thanks :)
     
    Marcos-Elias likes this.
  43. HerrVR

    HerrVR

    Joined:
    Mar 15, 2019
    Posts:
    41
    Hi. Yes, we currently discuss a possible change in the integration approach with the direct access to PhysX API from C# instead of high level C++ wrapper like it is in the current version. That should significantly improve the performance and also give the developers more ways to use it. Though, it also makes it simpler to do something wrong.
     
  44. Marcos-Elias

    Marcos-Elias

    Joined:
    Nov 1, 2014
    Posts:
    159
    Wow, it would be awesome! I miss shiftOrigin since Unity don't handle open world, and we need this function to make it better... Without being limited by the closed source part of the engine this should be easier. Hope that it works :D
     
    Last edited: Apr 26, 2019
  45. HerrVR

    HerrVR

    Joined:
    Mar 15, 2019
    Posts:
    41
    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 https://gameworksdocs.nvidia.com/PhysX/4.1/documentation/physxguide/Index.html 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.

    Viktor
    NVIDIA
     
  46. nxrighthere

    nxrighthere

    Joined:
    Mar 2, 2014
    Posts:
    567
    @HerrVR Awesome Viktor, thanks. So NVIDIA.PhysX.dll is effectively a P/Invoke wrapper which can be used outside of Unity with the native library?
     
    Last edited: Jul 14, 2019
    ClickOn likes this.
  47. HerrVR

    HerrVR

    Joined:
    Mar 15, 2019
    Posts:
    41
    In theory yes, though I didn't try. If you gonna try it please tell how it goes.
     
    ClickOn likes this.
  48. rz_0lento

    rz_0lento

    Joined:
    Oct 8, 2013
    Posts:
    2,361
    This is great. What's the status of contact modifications for this? Is it possible or are there some showstoppers for it? I don't think I saw the contact modify callback on the metadata.
     
  49. HerrVR

    HerrVR

    Joined:
    Mar 15, 2019
    Posts:
    41
    Yes, I decided to not expose contact modification callback to C# because it was too slow and unsafe. The solution will be - once the native plugin source is published, you'll be able to implement your contact modification logic there. But as this preview goes without sources, yes, it's not possible yet.
     
  50. rz_0lento

    rz_0lento

    Joined:
    Oct 8, 2013
    Posts:
    2,361
    Ah, if you actually release the native plugin sources eventually, that's all good. :) I don't really care if it's on c# or c++ side as long as it's accessible somehow.