Years ago, I made a forum suggestion asking about floating point accuracy. As a refresher for those who don't know, positional coordinates in a game engine are stored as float values, which increase or decrease on each axis the further away you get from the engine's or map's origin (0,0,0). Due to how these values are stored in memory, they basically lose their precision as the number increases (positive or negative). At smaller coordinates, this inaccuracy is negligible (usually off by mere millionths or so), but the further out you go, the higher the value is, and the inaccuracy becomes larger and larger. This therefore causes a tons of warping and jitteriness. This is why on some games, everything gets shaky when you're, say, at the corner or edge of a large map. In BeamNG.drive's case, it's definitely noticeable, you may not see it for maps that are 1.6 square miles in size (East Coast, West Coast, Jungle Rock Island, etc.), but with a map like Italy or larger (and there are plenty of large mod maps), or an infinite map like the Grid, you'll start to see some jittering the further out you get. And the main thing is that it doesn't actually take much distance at all to achieve this effect. Some games like Kerbal Space Program get around it by simply shifting where the origin is, but one of the best ways to get around this is through double floats, which have more accuracy than single floats. They still get the inaccuracy problem, however the negligible inaccuracy range is significantly greater, going from just a couple kilometers, to now billions of kilometers. You can go the edge of an entire solar system before you'd even remotely start to notice anything. As the years have went by, I've become more and more curious about this. I remember a developer on here saying that this type of issue has been getting looked into a little bit. The physics seems to be locally-based, and doesn't have to deal with inaccuracy, so it's mostly just the rendering that is affected (otherwise the inaccuracies would result in everything basically exploding). As the engine has been receiving new upgrades, particularly in the rendering and graphics department, and considering that the 32-bit version of the game for a while now has been dropped entirely, I just keep wondering if we're any closer to solving this kind of issue, or if it'll be any easier in the long run. It would make larger-scale roadtrip maps and infinite maps simply a lot more feasible (such as the mods that combine the individual vanilla maps into one big roadtrip map, or something like Los Injuris, American Roads, etc.) since you wouldn't start having visual issues within literally the first few miles out.
This would be an amazing addition to the game! Large maps is something beamng has been missing for a long time now.
YES THIS IS WHAT WE NEED!!! --- Post updated --- Hey @tdev This needs to be a thing. --- Post updated --- This REALLY needs to be put in game. It would make large maps SO much better!
devs, is this possible to do without taking two months of only working on this specific thing? or is it maybe even quick enough to do to put in a hotfix?
im going to go out on a limb since i dont do graphical math, but i recall reading that changing map positions to floats or double floats and so on for higher precision comes at a cost. Computers dont like dividing after all and decimal number calculations take a lot more time and resources to calculate, not to mention god knows how much time and effort this would take and what would be broken. im more concerned with this being an issue to begin with, i find almost comical how 30 years after the release of the modern 3D gamespaces for videogames we still have floating point issues because no one has a better idea than KSP's "you are the center of the universe" concept.
the center of the universe only works for singleplayer games. many games that have any coop/multiplayer cant do that if beam implemented that, it would complicate or make multiplayer almost impossible to implement, which is something the devs do want to implement someday
If this is the only quick way to fix it, at the moment id have a toggle for "float" and "center of the universe". Though the ideal would be double float.
you need to recode a LOT to switch from float to center of the universe, since you are basically making everything move around you instead of you moving, having a toggle would make it absurdly complicated
Ahhh I see, double float it is then thats the only option. I wonder how hard that would be to implement + performance hit.
I figured at the very least double float would/should be standardized in modern game engines. You're still gonna get rounding errors but it takes like a billion times more distance to encounter issues.
BeamNG is also singleplayer (techincally, i know about the mods). Then again, double floats also doesn't QUITE "fix" the problem, just make it small enough to be ignored for a long while.
This is a long-standing issue we want to address, however it requires some core parts of the engine to be rewritten, so its not an easy feat. I hope we can fix this soon
As far as i understand multiplayer is a "we will try, if we succeed it gets added, but if we dont it wont, and we dont know if we will succeed" thing.
Thats fantastic news, i have been planning to build a large map for a loooong time, to incorporate long drives, trucking, different environments etc and at the moment a map bigger than afew 10s of square km will start juddering. Ill keep watching this space lol
It's a lot of work to fix all up without making the game engine twice as slow ... but we are chipping on the problem slowly but surely. We just stabilized the camera as a starting point.
I did ask this question to chat GPT : Answer : AVX-512 is not available on medium cost x64 processors, but AVX2 is available on most current large public processors since a few years. AVX2 gives 256 bits wide registers. Using 64 bits floats with AVX2 could improve the older 32 bits wide code if this code was not using those instructions that use 256 bits wide registers (4 double precision numbers can be computed at the same time). If the game engine is using only SSE2 instructions (this is probable because the engine has been coded 10 years ago), then upgrading to AVX2 should double the processing power because AVX2 is using 256 bits registers instead of 128 bits registers. Then switching to 64 bits floats and upgrading to AVX2 at the same time should not give a speed penalty. AVX2 should compensate for the switch to 64 bits floats. AVX2 could be the start for a BeamNG world map ! Another point : we can approximate a doubling of computing power for 64-bit floating-point operations approximately every three years over the past decade. This mean that regardless if the the game engine 32 bits wide code is using AVX2, regardless a new optimization or not, a new 64 bits wide code should be able to run on latest general public x64 processors. When i watch at my quite old processor, an Intel core i7 8700 (release date October 5, 2017), AVX2 is supported : As a side note, it is possible to detect if a processor support AVX2 instructions at launch time, using the CPUID instruction. Then it should be possible to use a 64 bits wide version of the code, for newer processors, and keep compatibility for users that do have an older computer.
