Maybe another limit found (Map-Making)

Hey!

I think I've found another limit for maps. When you move too far away from the origin of the map (XYZ = 0/0/0) the static objects, the decals, and also the car itself will start to flicker.

I suspected that there would be a limit for the size of the map...so i started to create a tunnel (one piece is 1000m long, with lights every 50m...packed to a prefab object). Then I build a tunnel with 100km of lenght. Don't watch the textures or the model itself...it was just build for testing!

After 30-40 km (map-position XYZ 30000/0/0) the objects start to flicker. And it increases the more you drive away from 0/0/0.

Have a look at the video, and you know what I mean. Watch also the walls, and the skidmarks.

https://www.youtube.com/watch?v=S34ZTilSdW0

 

That's because of floating point becoming unprecise on large numbers as it is too far away from it's origin, as you already found out.

Simple solution for you is to not build that far away from the origin.
The alternative would be for the BeamNG developers to use a 64 bit engine of Torque3D (dunno if there is one in the works) or move the world around the car/camera instead of the car/camera around the world.

Basically when you're at the center, you're at x=0 y=0 . but when you move you're at x=5.4654068463500000 y=0. The problem now is the more you move away from the center the less precise the fraction digits can be so in the end you're at x=32500.34542510000000000 y=0. I've simplified the numbers for better understanding. Basically the bigger the numbers, the less precise are the fraction digits thus more flickering and weird behavior of the rendering engine.

Correct me if i'm wrong, but that should be it.

 

Sadly even a 64 bit variant of torque3d wouldnt alleviate that issue as this is a problem with floating point math which is not handled by the CPU core itself. A single precision float is indeed 32 bit, but it is handled in a dedicated floating point co-processor, if you have an FPU capable of double precision (which you all do) it is still usable in double precision mode from a 32 bit application. Regardless, doubles are slower than floats which would be problematic for BeamNG, even on NVidia CUDA which is incredibly good at working with floating point arithmetic, arithmetic operations on a double take 3 times as long as on a single precision float (and bizarrely, addition and subtraction operations on floating point are slower than multiplication and division, with integer data its the other way around with multiplication and division being exponentially slower than addition and subtraction).

Application wise, 32 vs 64 bit programs and OS refers to the CPU data size which refers to integer only, floating point has to be categorised entirely seperately.

Does anyone remember the old end of the map issues in minecraft where map generation broke down? People sometimes called it the end (prior to an actual "end" dimension being added) or the far lands. That was due to floating point breakdown and actually alleviated by having a floating world origin. Kerbal space program have a few dev blogs also discussing issues with floating point, they have some very bizarre solutions.

 

We had the same problem in our game aswell ... in the end we moved the world around the player and thus kept the origin point at 0,0 all the time.
Fixes rendering at x=200.000.000 but makes it a bit funny with positioning of npcs and multiplayer-stuff.

 

Currently it's a Minecraft clone basically. The rest is secret until we feel it's ready for everyone.

 

This is essentially the KSP approach too, you don't orbit around the planets in the universe, they orbit backwards around you. They also use doubles, originally they used floats, just the move to doubles alone almost entirely alleviated the old space kraken bugs.

I've found 2 of the blogs:
http://forum.kerbalspaceprogram.com/entries/54-Scaled-Space-Now-with-100-more-Floating-Origin!
http://forum.kerbalspaceprogram.com/entries/12-Krakensbane

 

This also affects the selection blocks over boxes as you move closer to the far lands. Kurtjmac has a series called "Far Lands or Bust!" where he dedicates 30 minutes per episode, 3 episodes per week in walking to the far lands. In his videos you can see the camera is rather jittery due to floating point precision errors. The further he goes, the worse it gets. It is actually pretty cool because while hovering over a block, the selection box is about 1/16- 1/8 of a block off. Quite interesting indeed.

 

Interesting ways around this problem. Since my game is built in a small city I won't really have any issues (Other than Unity not updating PhysX for months -_-). But yeah the limit is caused by the maximum values of floating point numbers.