64-bit Physics?

[anonymous_user_47069605]

Just wondering if anyone has had a chance to review whether it would be easy or not to implement true 64-bit physics within the source code or has already done it?

[anonymous_user_d573ef49]

UE4 links against the 64-bit PhysX libraries. Do you mean something in addition to this?

[anonymous_user_47069605]

@;608

UE4 links against the 64-bit PhysX libraries. Do you mean something in addition to this?

Well that is a great start. I assume however that 64-bit physics are disabled by default though? It does cause some performance overhead and most games don’t need it, so that would make the most sense.
To be clear - I want double (double precision floating point) used for physics and movement within the world.

[TheJamsh (Jambax)]

Out of interest, why would you need such accuracy?

[anonymous_user_47069605]

@TheJamsh;668

Out of interest, why would you need such accuracy?

Primarily so we can create seamless worlds in excess of 100km * 100km in size without running into single precision floating point accuracy or having to write hacks (Such as teleporting-to-zero or ‘celled’ worlds). Its a fairly common feature in simulation games.

[anonymous_user_d573ef49]

The underlying physics engine used is abstracted away.
So for example, a rigid body is represented using an FBodyInstance which has the expected methods (AddForce, SetLocation, etc…).
Another example would be FPhysScene which represents a physics simulation scene that contains the various physical actors in a given scene.
Whenever possible UE4 will use these higher level representations.

You’ll see there is a WITH_PHYSX define which is used in the implementation of the physics related structs. This should allow you to easily provide alternate physics implementations.
Having said that, I wouldn’t suggest that switching the underlying physics engine is an easy task - but it’s definitely something that’s been designed with in mind.

[anonymous_user_47069605]

The underlying physics engine used is abstracted away.
So for example, a rigid body is represented using an FBodyInstance which has the expected methods (AddForce, SetLocation, etc…).
Another example would be FPhysScene which represents a physics simulation scene that contains the various physical actors in a given scene.
Whenever possible UE4 will use these higher level representations.

You’ll see there is a WITH_PHYSX define which is used in the implementation of the physics related structs. This should allow you to easily provide alternate physics implementations.
Having said that, I wouldn’t suggest that switching the underlying physics engine is an easy task - but it’s definitely something that’s been designed with in mind.

Thanks for the detailed reply . You sound like you have a firm grasp of the codebase. I don’t really wish to use a different vendor’s framework for the physics as long as the PhysX implementation already integrated in UE4 supports 64-bit compile option.
Are you able to provide a little more information on whether the UE4 codebase has already abstracted away the types used in the various physics abstractions? Eg if you set the appropriate option will it replace Vec3 and Float types with DVec3 and Double types for double precision floating point operations.

[anonymous_user_47069605]

Anyone had any previous experience doing this in the private BETA?

[anonymous_user_afd92cec]

@Scott Richmond;799

Thanks for the detailed reply . You sound like you have a firm grasp of the codebase. I don’t really wish to use a different vendor’s framework for the physics as long as the PhysX implementation already integrated in UE4 supports 64-bit compile option.
Are you able to provide a little more information on whether the UE4 codebase has already abstracted away the types used in the various physics abstractions? Eg if you set the appropriate option will it replace Vec3 and Float types with DVec3 and Double types for double precision floating point operations.

That will be a lot of work to change UE4 to work with doubles. Also you need sources for PhysX to recompile it with double precision support.
More feasible way to avoid precision issues in big worlds is world origin rebasing. Basically you can shift world origin position closer to camera when camera is far enough from current origin.
UE4 already has support for origin rebasing - check UWorld::SetNewWorldOrigin function. Using level streaming and origin rebasing you can build huge seamless worlds.

[anonymous_user_47069605]

@ddvlost;1706

That will be a lot of work to change UE4 to work with doubles. Also you need sources for PhysX to recompile it with double precision support.
More feasible way to avoid precision issues in big worlds is world origin rebasing. Basically you can shift world origin position closer to camera when camera is far enough from current origin.
UE4 already has support for origin rebasing - check UWorld::SetNewWorldOrigin function. Using level streaming and origin rebasing you can build huge seamless worlds.

Unfortunately those hacks do not work when you add multiplayer to the mix. Are you saying the PhysX component already in UE4 is not 64bit capable?

[anonymous_user_afd92cec]

Yeah, origin rebasing will not work in MP games with unreal dedicated server, you will need custom server solution for this.

Are you saying the PhysX component already in UE4 is not 64bit capable?

Both 32 bit and 64 bit PhysX libraries use floats internally.

[anonymous_user_47069605]

@ddvlost;1735

Yeah, origin rebasing will not work in MP games with unreal dedicated server, you will need custom server solution for this.

Both 32 bit and 64 bit PhysX libraries use floats internally.

Okay thanks for confirming that. Would you mind going into a little more detail as to why it would be so difficult to convert float to double throughout the necessary parts of the engine? From what I’ve gathered so far the engine has done a pretty good job at abstracting away the underlying physics components.
I’m yet to really deep dive the engine architecture so any further expert opinion from you here would be helpful.

[anonymous_user_afd92cec]

@Scott Richmond;1749

Okay thanks for confirming that. Would you mind going into a little more detail as to why it would be so difficult to convert float to double throughout the necessary parts of the engine? From what I’ve gathered so far the engine has done a pretty good job at abstracting away the underlying physics components.
I’m yet to really deep dive the engine architecture so any further expert opinion from you here would be helpful.

Well, abstraction of physics components helps in cases where you want to replace PhysX with another physics engine, like Bullet or Havok.
Lets say you managed to integrate Bullet which is compiled with double precision support. That means there are will be a points in in the engine where you convert floats used by UE4 to doubles used by Bullet and vice versa, in these points you lose precision. To fully support double precision you need to change UE4 basic types like FVector, FMatrix to use doubles instead of floats. These basic types used everywhere in the engine: game framework, rendering etc. Also these types are serialized to disk, which mean as soon as you switch to doubles you will not able to use assets serialized in 'floats" version of the engine.

[anonymous_user_47069605]

@ddvlost;1778

Well, abstraction of physics components helps in cases where you want to replace PhysX with another physics engine, like Bullet or Havok.
Lets say you managed to integrate Bullet which is compiled with double precision support. That means there are will be a points in in the engine where you convert floats used by UE4 to doubles used by Bullet and vice versa, in these points you lose precision. To fully support double precision you need to change UE4 basic types like FVector, FMatrix to use doubles instead of floats. These basic types used everywhere in the engine: game framework, rendering etc. Also these types are serialized to disk, which mean as soon as you switch to doubles you will not able to use assets serialized in 'floats" version of the engine.

All great points to consider. Thanks. There is also the concern around making sure that it isn’t too difficult to maintain through UE4 patches.

I’ll definitely look at this more deeply soon. If anyone is interested in this feature let me know - Maybe I’ll make it (or its development) public.

[anonymous_user_3b9b5161]

Hi!

I’m definitely subscribing to this thread. I don’t have the exact same use case, but I’m interested in swapping the physics engine to one that has low level network replication abilities, so very interested in seeing where your adventure goes

[anonymous_user_d573ef49]

Scott, I just talked to NVIDIA about this and it sounds like there are plans for supporting higher precision in future PhysX release. I’ll keep you posted if more details arise.

[anonymous_user_47069605]

@;4855

ddvlost, I just talked to NVIDIA about this and it sounds like there are plans for supporting higher precision in future PhysX release. I’ll keep you posted if more details arise.

Thanks for the reply . Do you know what kind of timeline they might be working on there?

[anonymous_user_d573ef49]

I don’t have a timeline right now. I’d say it’s safe to say it’ll be a few months at least.

[anonymous_user_4d7d6c8a]

awesome thread. i am working on a titan based “open world” console and our launch title is using unreal engine 4 and i am interested in double precision as well. Scoot, I think you would also have to convert the coordinates system to double precision? [not just physics]. i would be interested in talking to you about your fork.

[Dig_Squid]

Even if PhysX does support double precision, as was mentioned earlier, it doesn’t actually help unless all ‘world positions’ in the whole engine are converted to double precision as well. I’m afraid we don’t have any plans to do this at the moment.