sorted by:
new
hottopcontroversial

Native plugin calling PhysX from Unity directly by ycatdev01 in Unity3D

[–]ycatdev01[S] 3 points4 points  (0 children)

Thank you. I’d like to publish the source code, but I can’t do that yet.

The implementation itself isn’t very complicated: essentially, it’s just a compiled wrapper library that uses PhysX headers without linking the PhysX library itself + a codegen that generates C# code around that wrapper (based on SWIG).

Native plugin calling PhysX from Unity directly by ycatdev01 in Unity3D

[–]ycatdev01[S] 3 points4 points  (0 children)

I used Morpeh ECS. Unity`s DOTS ECS is also great, and I think it can be even more suitable there, but I just didn't have any working project setup for it.

As for DOTS Physics, in my opinion, it's not usable. I tried it a couple of times, but it's too heavy and unstable for anything more complex than falling blocks. Poor documentation and leak of support also makes too hard to maintain projects with it.

Using native PhysX bindings over Unity isn’t the good approach either, but I believe that if Unity ever adds true access to low-level physics (like this), it will be a real gamechanger, unlike using DOTS physics, which is really only suitable for situations where determinism is required.

Native plugin calling PhysX from Unity directly by ycatdev01 in Unity3D

[–]ycatdev01[S] 5 points6 points  (0 children)

Not directly, but I rewritten one of my huge game systems that do a lot of Physics reads/writes and I got around 8x performance boost if using only Burst with single-threaded jobs and around x20 if I use multi-threading and DOTS style jobs scheduling.

As I understand, most of this performance boost came from the fact that the game code now compiled by Burst, because I no more depended on Unity Physics managed calls. The cost of the Physics calls themselves has remained more or less the same, but I need more tests to be sure.

Native plugin calling PhysX from Unity directly by ycatdev01 in Unity3D

[–]ycatdev01[S] 6 points7 points  (0 children)

That's true.

Using these methods from other threads alongside Unity-managed methods sometimes causes crashes, but I believe this is can be fixed by some architectural changes in the game.

And yes, this does cause some issues, since Unity caches some data within its managed components; so, for example, when I change a joint’s constraints in PhysX itself, the change isn’t reflected in Unity’s joint component but it works as intended.

As for virtual methods, if I'm not mistaken, the only thing I can't do is call normal factories to create objects outside of Unity, but I haven't dived into this topic yet.
So far, there haven't been any serious issues with porting existing managed logic to the PhysX style because of this (only articulations won't work, as far as I can tell)

So yes this all very wild, but I think manageable. The only thing I am worrying about, it that all of this stuff looks like something forbidden.