koobas.hobune.stream
Unity editor rotation accuracy 89.999 etc
Have you ever noticed that there is a problem in the Unity Editor with the accuracy of the rotation of the objects? This happens to me many times when I duplicate objects. For example if an object has a rotation of 90 degrees in the y-axis, as soon as I duplicate that object, the rotation of the new object becomes 89.999.
This is not a problem as such, but it gets annoying. Has anyone found a fix for this?
What Every Computer Scientist Should $$anonymous$$now about Floating-Point Arithmetic
Squeezing infinitely many real numbers into a finite number of bits requires an approximate representation. Although there are infinitely many integers, in most programs the result of integer computations can be stored in 32 bits. In contrast, given any fixed number of bits, most calculations with real numbers will produce quantities that cannot be exactly represented using that many bits. Therefore the result of a floating-point calculation must often be rounded in order to fit back into its finite representation. This rounding error is the characteristic feature of floating-point computation.
As I am a little bit OCD about accuracy things like this drive me insane, especially in 3D modelling software when I model to fractions of a millimetre and want things modelled perfectly.
It is annoying in Unity too as it makes comparing angles and positions awkward without rounding them or having a tolerance. One solution I sometimes use is to set the Euler Angles to remove inaccuracies that may have worked their way in there. Not ideal I'm sure but it seems to set values more accurately than other methods.
example.transform.localEulerAngles = new Vector3(0, 90, 0);
OCD :) Same here! This is why I posted this question. This thing also drives me nuts and I waste a lot of time going through the duplicated object to set its angle properly.
$$anonymous$$y worry is that if the angle is 89.999 and the axis movement is set to "Local", moving the object in the x-axis would eventually give a big error in the position of the object. So I would have to correct the position anyway.
I was thinking about making a $$anonymous$$enu script that, when executed, goes through all Transform objects of the scene and rounds up the angles to the nearest degree. I like to use round numbers for angles, so I guess this would be the best solution for me (and for us OCD people, hehe). :-)
I also like things to be perfectly aligned, however certain things can't be done. Unity stores the rotation not in euler angles but as quaternion. That conversion can introduce small errors.
Just to be clear what that would mean:
If your angle is off by 0.000001 degrees the sine of that value would be 0.0000000174532925. So when moving sideways on the x axis say +- 10000 units the error on the z axis at 10000 units would be 0.000174532925 units so that's 0.17 "milli units". The floating point format only has around 6-8 significant digits, so when you're about 10000 units away from the center you only have about 3 digits behind the decimal point.
Just type in 90 into the corresponding box. As others have mentioned, it's just an artifact of how Unity works. If it bothers your OCD (and it does me, but I don't have OCD) then you have to take the time to make it an integer
There is no "fix", it's just how floating numbers work. They are not precise by their definition.
In depth: You can actually have exactly 90 as floating number, like many other integer values. However under the hood unity doesn't use Euler angles for rotations, it uses quaternions. So, when you set rotation to 90 degrees it gets converted to quaternion. Quaternion consists of four small floating numbers (all of them are < 1), and these are not precise. So when editor converts them back into Euler angles to display to you small errors are inevitable.
btw: The number doesn't "float", it's the decimal point that "floats" to the left or right. That's why they are called: floating point numbers.
And if you want to understand quaternions a bit better, i suggest this numberphile video.
@Bunny83 ... Thanks for the video. Very instructive :)
@MSpiteri, That's normal behaviour and not only in unity, the same in blender, for example. But if you need to compare values and you don't want random working you may use:
private float precise = 90;
if(Mathf.Round(transform.rotation.z) == precise)
// do you stuff
Another option for number comparison for a case like this, especially, would be use to $$anonymous$$athf.Approximately. It's intended, by design, to act as the floating point equivalency comparison.
if(transform.rotation.z == 90.0f)
// Less reliable
if($$anonymous$$athf.Approximately(transform.rotation.z, 90.0f))
// $$anonymous$$ore reliable
agreed. $$anonymous$$athf.Approximately() is a much better approach than going through $$anonymous$$athf.Round(), because with the round() approach everything from 89.5 through 90.4999 will be "equal to" 90. If you were working with radians ins$$anonymous$$d of degrees, the result would be disastrous because the rounding error would be equivalent to nearly 60 degrees! I$$anonymous$$O it's also easier to understand the intent of the code.
Thanks, it's exactly what I was looking for.
By the way, it looks like this rounding error no longer manifests itself when copy-pasting GameObjects, at least here, using Unity 5.5.1f1.
The way the editor displays the values may have changed, but I can assure you that the underlying data is no more (in)accurate.
If you wanted, you could write a custom inspector that rounded all rotations to the nearest whole integer prior to display in the editor, but the underlying backing value would still be a float, with all that entails.
