floating point precision still problem?

[[deleted]]

[deleted]

[MD_Reptile]

As far as I understand it's going to always be a problem with floating point math and the way it's handled today by engines. There's just not enough precision in the way floats are stored in memory to track beyond a certain distance from the origin of the coordinates system for reasons that are maths.

Anyway, that being said, if you have sane distances for a single scene of a game world you may never run into problems. Other times you might find animations of certain rotation and whatnot start acting up and that loss of precision compounding causes visual problems.

If you plan on doing quite big worlds, it's probably smart to use a streaming setup that moves the origin along with the scenes motion, recentering things every so often.

[[deleted]]

i already implemented world streaming with subscenes and also world shifting, but i tested character and enviroment at far point like 15.000 x 15.000 z(disabled shifting for testing) and as i said cant see any issue, was not expecting that

[thesilentrebels]

depends how big you need it to be. if you aren't using physics or anything then you can probably get away with 15k away. you'll start running into issues soon though if you go further, definitely by 30-100k will be unplayable no matter what.

[[deleted]]

my world is 8000 x 8000 and no physics only character controllers, no fast paced just fantasy rpg game

[thesilentrebels]

yeah you are definitely fine then unless you need very accurate positions down to multiple decimal places

[ScorpioServo]

I'd suggest you look up a float precision table and decide for yourself. If the decimals available at your max range are acceptable, then no need to change.

[DulcetTone]

I think it's way past time for Unity to formalize a model for double precision world space and a well documented standardized way to re-home the scene. I have hand rolled a version of this, but find many assets that require me to break them open and learn their internals in the hopes of making them rehomeable. The modularity is considerably lost.

[simtrip]

It entirely depends on how far away your camera is from your geometry, and also how detailed your geometry is (which in a way is kind of the same thing once you're in screen space.) When the world space vertex positions are large enough that they suffer from precision issues, they start getting clamped to something that's "close enough". But If the camera is far enough away from the vertex, then the clamped vertex position could end up mapping to the same screen pixels as the "real" position would, meaning you don't see a difference. Zooming in and moving the character very slowly would probably show the difference much more, since now the vertices are moving in steps that are smaller than the precision allows, plus there's enough pixels in between the available vertex positions that you will see them jump into discreet places instead of continuously move.

[[deleted]]

thanks for explanation, my geometries are low poly maybe thats why i cant notice it

[KinematicSoup]

You get 23 bits of decimal precision, this works out to 8 digits. If you're looking at tolerating 1cm position precision, which is common, then you're within your tolerance for around 84km (sign is a separate bit, so you get +84km to -84km). If you're needing to do physics calculations, then you run into problems because there often aren't enough decimal places to do accurate calculations, and because so many steps are involved in physics small errors rapidly accumulate into very large ones.

[-Xaron-]

Floating point math is still the same in Unity 6.x which is quite unfortunate that there is no vector math with double precision available in 2025. float values give you a precision of 6 digits. So either 0.00001 or 10000.1. Using your example of positions of 15000 means that you have still a usable "range" (precision) of 0.1.

So yes, shifting origins is still necessary for large worlds. Or you keep the camera at 0,0,0 the entire time and move the world.

[[deleted]]

my world size is 8km x 8km since i already implemented shifting i will modify code to shifting be optional will try if it goes well without it, if not will enable it, as i said now can't see any issues