Currently using Origin Rebasing you can expand your worlds to the box of ±21 000 km in each direction.
We don’t have the tool to position assets at this scope.
What I’ve developped since the opening of this thread is library of unreal engine vectors, transforms, rotations mostly converting FVector, FVector2D, FVector 3, FTransform, FQuat, but also some geometric assets like box, sphere (for intersection computation etc…) etc… to use and operate using double precision.
In its current form, those modification are engine modifications, not a plugin i could easily share.
To fully use World Origin Rebasing you first need to change the Unreal Engine 4 Variable WORLD_MAX to go beyond the base ±20km of playable area.
Below i’m playing around at (21 000km,21 000km,0).
UPDATE:
- FDVector - Double Precision Vectors
- FDVector4 - Double Precision Vector4
- FDTransform - Double Precision position Transforms
- Math operation - Cross compatibility whenever possible
- ExtraMath: CosDouble(), SqrtDouble(),....
- Couple FMatrix operations available
- SceneComponentDouble
- PrimitiveComponentDouble
**Extra explanation:**
SceneComponentDouble and PrimitiveComponentDouble are only available in C++, still figuring out a way to hook them into the Actor class in the best way possible.
It’s worth noting that there’s absolutely no point using double-precision vectors unless you’re doing all of your movement code and game code in double-precision as well. Floating point can actually support huge numbers, but it’s the constant multiplying/dividing large numbers by small numbers that creates error.
I had the same issue in Satellite Command. Even with a world that’s much smaller than reality, our movement component does a lot of floating point operations and led to a really unstable final result. The only solution was to completely rewrite the movement component to use double-precision, and then convert back to a standard FVector at the very last minute to tell unreal where in the world to place the object. That did the job fine!
All I did was write the movement code in double-precision (this meant creating a custom Vector and Quat type, and rewriting some of Epics FMath library to use double precision). With Kepler orbits you usually have very large numbers (mass of the earth) mixed with very small numbers (delta time), and that’s where we lost precision - the solution was to just convert it all to doubles.
All of this can be done without any mods to the engine, we shipped on the launcher version of 4.12 - but I created a custom maths library and you have to write the movement component entirely on your own and not use any existing code in the engine. This is only possible of course for certain types of movement.
The movement component converts back to default precision only at the last moment, where it calls SetActorLocation() with a vector created from doubles. The key difference however is that all the maths operations are done in double-precision, that’s how you avoid the error.
I’ve added 3 main new class for Double precision Vectors, Transforms with double precision positionning, and a new SceneComponent using double precision position.
Bear in mind that PhysX uses float-precision. Any collision handling you try to do for your movement component will result in loss of precision.
Nothing you can do about that, other than to find a double-precision physics library or write your own (and integrate it into unreal). This is a lot easier said than done, it might not be evident yet, but you are fighting an uphill battle!
Noted. I’m just a space and physic fanatic, i want things at the proper scale with their proper physic unit.
Was working on the atmosphere scaterring earlier and using doubles was actually fairly useful to solve the rendering equation keeping relevant particle density or light wavelength to modelize the interfering medium.
My goal is to be able to push the origin rebasing beyond its current limitation, and i wonder if PhysX will benefit from it or not. If i really want the full physic collision i’ll most likely swap the physic engine anyway, but that’s out of the scope for now.
Spent the last couple days working on double precision support for editor viewport, think i’m gonna need a break after that!
New update on main post, a lot has been done towards deeper integration of FDVector/FDVector4/FDTransform whenever possible for positionning only, keeping as much as possible of the original code and original class/structure. Normals for instance would have been a waste of space to store in doubles.
**Edit: **added a lot more explanation if anyone is interested in the topic
MaximumDup, I’m sorry if I missed the obvious but is this something you will be releasing to the public or what exactly? Many of us have been waiting a very long time to have double point precision in our projects.
It’s a lot of experimentation at this point. I’ve a custom 4.20 with a lot of double precision experiments but it’s mixed with custom code for my game. Doubt i’ll released it as it is.
i have the same problem, being a persistent physic fan. You can develop things without it, but double precision would be a great next step in game development. And the reason is very easy. Precision reduces dramatically after already 1km away from the origin. If you want correct calculations in an open world with a wide field of vision, you have to do workarounds with distant objects.
Are there any plans to implement double precision within the life time of ue4? Or do we have to wait for ue5?
To be honest, you can already achieve really large scale if you’re computing on double precision your world element position and moving a virtual world origin around.
Largest i achieved was this 1185km radius planet:
Beside Space Sims i doubt there’s any need for double precision, but it would open up a nice range of opportunities !
How’s the work going to bring double precision to UE4? Been trying to find ways to do it (completely new to UE and C++), but haven’t had much luck myself beyond realising that it’d likely require a rebuild of the maths functions to use double precision, and not sure that’d let me use double precision in the blueprint editor.
Currently using Origin Rebasing you can expand your worlds to the box of ±21 000 km in each direction.
I’ve developped a library of unreal engine vectors, transforms, rotations mostly converting FVector, FVector2D, FVector 3, FTransform, FQuat etc… to use and operate using double precision.
You first need to whange the Unreal Engine 4 Variable WORLD_MAX to go beyond the base ±20km of playable area.
I came across this trying to figure out at what distance relevant accuracy is lost. I was wondering, and realize do to other components such as Physics engines and graphics cards etc. still use 32bit float that 64 bit float most likely will not be implemented? I am curious about making an RTS that runs as a sim for calculating actual projectile physics etc. and map sizes ranging from 5km to 80km+. I see where people often sat 32bit float gives enough precision, but in my research I am finding otherwise, as devs mention losing accuracy at even 1km distance from origin. I want accurate simulation for a multiplayer game (World Comp, level streaming etc. does not support multiplayer) at ranges beyond 80km. After all, real world Artillery can fire rounds 23km! We are so far in technology, what is it going to take for all systems to switch to using 64bit float?
Faced with the problem of limiting the size of the world. Can you tell me which engine sources need to be modified to switch from float to double ? need network support as well
it is clear that I need to change vector.h in the first place,
