So Ive started working on a game with a large-ish map. I know that several game engines have problems with floating-point precision when the map gets too big, which causes problems with physics, movement, ect. (Torque 3d, UDK, and Cryengine 3 all have this issue) I’m wondering if I’m going to have to worry about this with my game. Any information is appreciated.
It’s a safe bet that you’ll have to worry about FP precision in ANY computing case. And if it’s a problem in Unreal, CryEngine, and other engines with an actual budget, you can assume that it’s most definitely an issue in BGE.
I’ve had pretty huge maps before with no problems. If you keep the scale of the characters reasonable you should be ok. How big is large in your case? You need to fit the scale to the map.
My game was a battlemech sim. So although the level was about 10x10km the characters were 10 meters tall. The smallest object on the map was a building…
You won’t be able to have a human scale map that large, anyway, what would you fill it with?
Thanks for the replies.
In my case, “Large” is about 3,000 Units by 3,000 units. My player model is approximately 1x1x2 units. Water, cliffs, and low-poly trees fill most of the terrain. But if there wasn’t trouble with a 10km x 10km map, I doubt I’ll have trouble with this.
Yes, you need to worry.
A) large maps are simply a lot of data to be processes -> slows down processing [less a precision issue]
B) as further you are away from the scene origin as less precise the positions will be. This will produce different results as near the origin.
A solution for both problems is to move the whole world in a way that the camera is near the scene origin. As your 3D world should only contain objects near the camera such a “world jump” should not be a big deal.
Nevertheless I would worry about it when you discover precision issues and you can’t solve them locally.
Hi, I know this has been a long time since someone replied to this, but I’m curious how this worked out 4 years later. Seems like Unreal Engine wouldn’t have this kind of problem at all since it even encourages people to use real world scale.
Using a 8 km x 8 km is working perfectly fine but if you want to address bigger than this then you will need to learn how to do it via streaming system.
What people have to understand is that an open world is often not possible if you don’t have a 100+ staff to populate such a huge world and it is going to require many years even with a 100+ staff or else it is going to be an empty walk simulator.
Look at Metro exodus, it is not open world but the map are huge but very well populated with assets and it is a blast to play.
I definitely get where you’re coming from. However, the thing was that I thought it was rather strange that a person wouldn’t be able to have a big map and populate it (even 4 years ago) because of some bizarre floating point precision problems. It seems very peculiar.
Today it is feasible but the question one must ask is; do i really need an open world and do i have the resources and staff to populate it including game mechanics per area?
Even if the knowledge is available doesn’t make it any easier and the whole project have to be done in perspective that it is going to be an open world game.
Open world now is almost one of these hype word that many are chanting without even having a clue about how steep the difficulty is to build one and often they don’t even have any 3D experience or coding skill to start with.
It’s almost criminal in my book to not warn people about the task ahead since they could invest years of their life in a project that will never see the light of day and that will remain on the broken dreams Blvd of indie game devs.
It’s not peculiar or bizarre, it’s what happens in every engine. Try building a huge map in Unreal without world streaming and you’ll run into precision problems too.
Really? That’s fascinating. I’m not really a game developer, but I was just curious about it is all.
I’m not a developer either, just an artist.
I’m not sure you two are talking about the same thing here.
Floats can have a precision problem because some numbers in decimal cannot be properly represented in binary. For example, 0.1 is a recurring number when stored in base 8 (just like 1/3 is recurring for base 10), so if you store it in Python, you may at some point see something like 0.099999999999999998 when printing your variable. This can cause issues when comparing floats to each other (e.g. obj.x == otherObj.x).
Then, there is the question of co-ordinates pushing the size of number that you can store in a float. The further away from the center, the higher the x,y, or z co-ordinate number will get.
1 Like
Thanks for clearing that up. 
In the comments of that Stack Overflow question, if you follow the link to the Unity blog, you can see they’re doing exactly what Monster suggested doing 4 years ago:
Keep the camera near the middle and move everything else. The issue was never “fixed” in another game engine; people just worked around it.
To quote the blog:
1 Like
For any DCC app, game engine… Always keep in bounds (also consider 1/3 for reserve)! - It’s the safest bet in almost all areas of development.
A floating-point variable can represent a wider range of numbers than a fixed-point variable of the same bit width at the cost of precision. A signed 32-bit integer variable has a maximum value of 231 − 1 = 2,147,483,647, whereas an IEEE 754 32-bit base-2 floating-point variable has a maximum value of (2 − 2−23) × 2127 ≈ 3.4028235 × 1038. All integers with 6 or fewer significant decimal digits, and any number that can be written as 2n such that n is a whole number from -126 to 127, can be converted into an IEEE 754 floating-point value without loss of precision.
while CAD apps must abide to CAD standarts use double-float, why are more precise but also more expensive and harder, slower to develop
Just going to throw this out there: took me nearly an hour of sprinting in a straight line on an endless map generator for the program to get confussed enough to start misaligning tiles – the size of your game world needs to be pretty darn big before this becomes a serious concern. If you were to go which such sizes, then yes, work your code around these kind of issues.
1 Like
Assuming real world scales, the issue becomes less apparent when you have slowly moving avatars like in your case, @Liebranca. But once you start playing around with flying vehicles (chopper, airplane, rockets…), you will reach the limits of single point precision quicker.
Occuring issues depend on the both sides of the scale spectrum (min & max // micro VS macro).
ie.
if min. = 1m then max. = 1000 km
if min. = 1 mm then max. = 1km
It basically comes down to how much detail you’re ready to take on or willing to sacrifice. Good choice of texel density helps a lot, as is one of the base foundations to consider along other budget restrains.