Question How to replace the Physics engine in Unity

How does one replace the physics engine in Unity? Do you just disable the physics engine and call your own on FixedUpdate()? Or is there a more integrated way?

 

Thanks for the quick response. Can you point to any documentation that explains this in detail or with examples or API docs? While you describe it at a high level, it isn't clear how to begin building an alternate physics engine or how it would manipulate/access/interact with things like transform position or rotation properties.

 

Does Unity document the API that a physics engine needs to publish as a plugin for Unity to use it? And when those API calls are made by Unity into the plugin?

 

I think you are missing yant's point here. You're not going to be able to magically place a new physics engine in and Unity will be able to use it natively. The advice described is that you are going to disable Unity's physics engine, import another library, and then completely write your own system on top of that from scratch. All of your physics-related stuff will then have to go through this layer that you yourself will provide.

 

Sorry... give me a sec...

Is the library the phys engine I write? If so, what is my own system on top of that? If it is to run the phys engine, then why not just write it all in C# and don't bother with the library and native C interfacing?

 

Well, I think my personal opinion would be why bother to replace the built-in physics engine in the first place

But I get there are sometimes reasons you might want to try something different either for fun or because you actually really have to.

But when I say 'write you own system' I mean write you own integration of an imported physics library backend. Writing the physics library itself and writing the integration of it into an engine are two different things. In this case you would need to create that integration - which would likely require some sort of centralized system that ticks the physics library's simulation every frame or perhaps every fixed frame. You'd also need a way to instantiate physics objects in the library that more easily integrate with your Unity objects and data, which would most easily come in the form of monobehaviours (or components if you are using ECS). You'd need to constantly pump data back and forth between the physics library and your Unity objects which would be more stuff that need to update every frame. If this sounds like a lot of work that's because it is. Luckily, someone already did it for you - which is why Unity has built-in physics in the first place. So again, I'd say you probably really just want to find a way to work with the system already in place.

Potentially you are trying to do something very extremely simple and the built-in physics is overkill or perhaps actually more work than it's worth to get running due to the fact that often realistic physics are hard to get right when going for that 'video game' feel? In that case, I'd say it might in fact just be easier to write your own physics code from scratch.

 

My intent was to look into the effort to replace the physics engine with a fixed point fully deterministic substitute.

If I cannot create a physics engine drop in replacement, then I may as well just turn off the physics engine and do it all in my own C# assembly. It would be more straight forward to review, comprehend, and make changes to - more maintainable. If that is how I need to do it, then I got a good idea of the effort.

Not today...

 

Personally I would think implementing the integration of another existing engine would be much much easier. Either way you still have to do the integration yourself but now you ALSO need to write the simulation too.

You could also look into Unity's other physics engine (yeah I know, it's confusing). There was some kind of package that implemented Havok for use with ECS if I recall correctly. I don't know what the state of it is or if it's even usable or still exists. But then again, I could say that about almost everything in Unity these days. I do know that it was supposed to be developed with networking and determinism in mind though. Can't say if it used fixed point or not. It might be worth looking into at the very least.

EDIT: A quick google search seems to suggest that it is alive and kicking and even 'supported for production' (not that such a thing carries much weight with me these days coming from Unity). Have a look and see if it meets your needs.

https://blog.unity.com/technology/havok-physics-now-supported-for-production

EDIT AGAIN: Bah, I just realized it's a pro-only thing anyway so unless you are working for a big company with lots of money to spare or you already have pro it probably isn't worth the money just to have a play around for the sake of review.

 

I am familiar with the havoc option, but it isn't the fixed point deterministic type of physics I was looking at.

I began looking at building my own physics engine last year. I began by working on the fixed point math library. I stopped before I got to the question I posed here. It was quite a bit of work. But the concept that Photon;s Quantum presents is quite interesting.

 

I recommend looking into the Unity DOTS. Both UnityPhysics and Havok are currently deterministic and should be cross-platform (cross CPU architecture) deterministic after Burst Compiler gets the determinism feature. I would suggest going on the DOTS roadmap and mark "Burst Determinism" as Critical. https://unity.com/roadmap/unity-platform/dots

 

I see, thanks for the reply! I really like your 2D physics updates. Especially the new include and exclude layers they are very practical and helpful! I hope it won't take too long to get the burst feature. So I was just wondering. Is Rapier the only 2D physics engine on the market that currently ensures cross-platform determinism? Is there any possibility that Unity will offer 2D physics with cross-platform determinism in the future?

 

I am truly skeptical of any claim of a floating point library being fully deterministic across platforms. It is not my understanding that they use fixed point under the hood. Am I incorrect?

 

I apologize for continuing this thread here but I am very curious about this. Does this mean that the current gameobject 2D physics engine would also benefit like the DOTS ones from the Determinism Burst feature? Or would it need an equivalent 2D physics written for DOTS? I am not an expert on Burst so I don’t know. Thanks for the reply in advance!

 

I see, thanks for the explanation! My last question would be whether there are any plans to create 2D physics written in C# to be able to benefit from the Burst feature like the DOTS physics could. Maybe 2D physics for DOTS? Thanks for all the answers again, I really appreciate it!