We are considering UE but have our own physics engine. How much work is it to replace?
Can’t say because I haven’t done it, but the real question you should be asking is “What is the cost vs. benefit ratio of replacing the built-in physics engine?”
You have to have a VERY good reason to explain why you aren’t falling into the trap of “Not Invented Here” syndrome. Imagine it takes several months to completely swap out physics systems. And then several more months to properly QA it. What specifically is gained? If the things you gained are slight or small, why not just mod the exist physics system to add in the capabilities you need? The R&D cost of that is orders of magnitude smaller, on the order of days or a few weeks.
Our project is a very physics heavy realistic simulation for which we’ve already written a physics engine that took over a year of work, so yeah that’s why 
Using our physics engine isn’t the question. The question we are faced with right no is, do we integrate our physics engine into Unreal, and get the benefit of the rest of Unreal, or do we continue and build our own graphics and game engine as well.
I’m very much a proponent of using Unreal, but its going to be largely dependent on how much work that involves.
1 Like
Since there is no real easy answer to this, unless one of the devs will come in and answer the question.
You should probably just sign up for ue for one month (your company should manage a possible onetime 19$ cost)
And just pull the source from git hub and look at the binds.
It’s physx right now I think, the question if it’s hard or loosed coupled. And that would then mean that you should reflect the function calls from physx trough your own engine.
The question is, how simular are your physics engine to physx.
I don’t think anybodies ever really done it, but it’s definitely not going to be a plug and play thing.
Depending on your Physics Engine you might be able to integrate it as part of your project, and then create an Actor Component that references it. That’s probably easier than completely replacing the Engine’s physics system, as it’s pretty rooted in. Not sure where to begin though, you’d at least have to bypass the physics engine/collisions in Unreal first. Easy enough if you set everything to have no collision 
Simulating stuff shouldn’t be hard, it’s the collision side that’d probably the toughest bit.
That is actually true.
And physical objects could probably be read from the level and feed to the “personal” physics engine, making object sizes and shapes at least for the static level be provided from the editor if desired.
Why didn’t I think of this.
I am actually doing something similar controlling actors by fixed positions trough logic, rather then physics, and just use parts of the physics implementation like rays to know about the static world.
Since you have full controll over the objects transforms it should be no problem, in theory the actor is just a really fancy world transform (well a bit more) holding components.
I digged pretty deeply into this for one reason or the other, and I think it is kinda easy to just swap the physics engine, because everything is just encapsulated neatly. It’s still a rather big task, but definately not impossible to do - considering that Unreal uses PhysX subsystem. You could just try to match the PhysX Subsystem interfaces and be done in no time.
BUT, even though you have your own physics engine, I don’t see a point in switching (other than being more familar with your engine/or having a very specific engine that does weird stuff). PhysX is just working as it is supposed to, in my opinion.
1 Like
I too would like to add other physics libraries to UE4 so if anyone knows how or have done so please post a tutorial/Video. From my research it would seem the best way to go about it is to add a physics abstraction layer (PAL) so it would be easy to swap libraries with a click of a button which I have seen done in other game engines and simulation software. Here are some opensource ones:
My plane is to do what was said above and leave the current engine as is and use it for some things in the game. Then make a new plugin for the PAL and another for the new physics engine and use that for the main actor. I’m going to add another thread “Adding other Physics Engines and Algorithm Libraries to UE4” just because this threads title is specific in another way so would really like to hear from the responders to this thread and to know @AgathornTest what you know about this topic and what your team figured out.
Replacing the physics library isn’t something that you would typically pick up and blow through in a day, it would be a significant undertaking. Consider also that if you still need some features of PhysX like cloth simulation and you aren’t planning on doing your own cloth simulation then you’re just going to be running two physics engines at a time. And that sounds like a recipe for disaster. Both PhysX and Box2D are implemented in UE4, so if you start by reading say the integration guide for PhysX and tracking things down in UE4 source you’ll probably find most of the major stuff quite easily.
As to how much work it is to implement a physics engine, there are the basics of wrapping the necessary entry points and ticking the physics engine, probably something anyone could do in an afternoon. Then beyond this you need to do all the little things that would be necessary for normal users to actually use your physics engine… things like generate collision geometry in whatever odd buffer format that Physics Engine Y needs (hopefully with the aid of the UE4 editor) and render the actual debug geometry for the physics primitives to help you debug your scene. You also need to tie in collision filtering, raycasts, sweeps (if supported). Then add world controls to tune the physics parameters of the physics world.
These are just off the top of my head, I’ve integrated PhysX and ODE in the past. PhysX is pretty easy to get going, like I said you can easily do it in an afternoon (assuming this carries over to about any physics engine) and if you work with a bunch of other hackers you might only need that base level integration. But working with artists and such, if you want to decouple their physics workflow from your programmers you’ll need a more polished integration and that effort is a lot more work and a lot of grep’ing and understanding UE code.
All PhysX specific code is wrapped with an ifdef WITH_PHYSX which you can of course turn off.
We try to maintain an abstraction layer wherever possible. FBodyInstance and FPhysScene are the two objects you’d want to start looking at. Most common functionality should be fairly easy to swap (AddForce, SetLinearVelocity etc…). These are easier to swap because most physics engines have a very similar API so it should require little reworking. Things like destruction and cloth are more difficult because they’re more tightly coupled with APEX and unless your physics engine has a very similar design it may require more work.
A big concern would be on upgrading source code in the future. If you’re making modification in these engine source files upgrading engine versions will of course be more difficult.
If you decide to do this and find that certain refactors are needed it would be great to submit a pull request so that upgrading future releases is as easy as possible.
Hope that helps
1 Like