koobas.hobune.stream
Why am I experiencing vector addition inaccuracies?
I have a simple script designed to decide when an object should change direction. The decision only occurs when the object is perfectly inside a tile. Each tile is one square unit in size, enabling a simple modulus calculation to determine when the position is within the tile:
Vector3 _position = transform.position;
if (_position.x % 1.0f == 0.0f && _position.y % 1.0f == 0.0f) {
Redirect();
}
Unfortunately, this condition is never satisfied.
The math behind moving the object is quite simple as well. There is a normalized directional vector multiplied by movement speed, and added to the object's position each frame:
_position += _direction * 0.01f;
transform.position = _position;
The position of the object quickly displays accuracy issues. I logged a couple bits of information every frame to find out where the issue is rooted at. The _direction variable is initially set to (0,1,0). Each frame, the log shows the calculation of _direction * 0.01f to be (0,0.01,0), exactly as expected. However, the _position vector loses stability quickly.
From the log:
Movement: 0,0.01,0;
Position: -4,0.01,0;
-----
Movement: 0,0.01,0;
Position: -4,0.02,0;
-----
Movement: 0,0.01,0;
Position: -4,0.03,0;
-----
Movement: 0,0.01,0;
Position: -4,0.04,0;
-----
Movement: 0,0.01,0;
Position: -4,0.05,0;
-----
Movement: 0,0.01,0;
Position: -4,0.05999999,0;
The position corrects itself at y=0.11, but loses accuracy again after y=0.33 for some reason.
I know that floating point numbers have accuracy issues, but I've NEVER experienced issues with numbers only 2 decimal places deep. Especially considering the multiplication operation churns out the correct result, yet simple addition results in horribly disfigured results, causes me much confusion.
Suggestions?
That is just classic float inaccuracy, in Unity these are single precision values. Any attempt to use exact coordinates with vectors is flawed. You need to test the difference against an epsilon accuracy value and adjust the position at that point if you prefer.
I am unfamiliar with that, but I will research it. Is there a better alternative to the logic used in my code? Would it be more suitable to have x, y, and z variables in the object, perform the operations on them, and simply transfer them into the transform position at the end of each frame for drawing? This should eli$$anonymous$$ate having to use single-precision floats, and will keep the vector separated from the logic.
Well I would do this:
const float EPSILON = 0.0001f;
if($$anonymous$$athf.Repeat(_position.x, 1) < EPSILON && $$anonymous$$athf.Repeat(_position.y, 1) < EPSILON) {
}
Doing it in variables really won't help doing any kind of == on a floating point value of any precision is considered a bad idea.
I always feel "nervous" using % with floats - but maybe it works these days! $$anonymous$$athf.Repeat is an explicit floating point version of modulus.
I'm not sure how that will apply. The result from the function as it approaches and "hits" the integer whole value, gives me 0.9000001 and 1.192093E-07 respectively. I could then check if each dimension is less than 0.01 or greater than 0.91, but there will be several of these objects on the board, and must remain in sync with each other, falling on integer coordinates at the same time. With the now obvious inaccuracies of floating point arithmetic, I would be concerned that this synchronization could become problematic.
I guess this is due to the speed of movement of things though - in your example log you are experiencing tiny fractional inaccuracies of the order of 0.000000001 - is it the fact that the object skips the boundary entirely? In which case we need to deal with the case where it is just over the line and just under the line. That appears to be the issue.
var diff = Mathf.Repeat(x, 1);
if(diff <= EPSILON || diff >= 1-EPSILON) {
