Comments and answers for "Unity editor rotation accuracy 89.999 etc"
http://answers.unity.com/questions/1156322/unity-editor-rotation-accuracy-89999-etc.html
The latest comments and answers for the question "Unity editor rotation accuracy 89.999 etc"Comment by armorhide406
http://answers.unity.com/comments/1343929/view.html
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 integerSat, 22 Apr 2017 02:33:30 GMTarmorhide406Comment by tanoshimi on tanoshimi's answer
http://answers.unity.com/comments/1333213/view.html
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.Thu, 30 Mar 2017 15:40:15 GMTtanoshimiAnswer by Matexyu
http://answers.unity.com/answers/1333142/view.html
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.Thu, 30 Mar 2017 13:22:29 GMTMatexyuComment by Black_Demon on Black_Demon's comment
http://answers.unity.com/comments/1281569/view.html
Thanks, it's exactly what I was looking for.Tue, 06 Dec 2016 17:44:41 GMTBlack_DemonComment by MSpiteri on MSpiteri's comment
http://answers.unity.com/comments/1157002/view.html
@Bunny83 ... Thanks for the video. Very instructive :)Fri, 18 Mar 2016 12:35:51 GMTMSpiteriComment by Bunny83 on Bunny83's answer
http://answers.unity.com/comments/1156977/view.html
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][1].
[1]: https://www.youtube.com/watch?v=3BR8t$$anonymous$$-LuB0Fri, 18 Mar 2016 11:53:11 GMTBunny83Comment by Bunny83 on Bunny83's comment
http://answers.unity.com/comments/1156969/view.html
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.Fri, 18 Mar 2016 11:36:10 GMTBunny83Comment by MSpiteri on MSpiteri's comment
http://answers.unity.com/comments/1156924/view.html
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.
My 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 Menu 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). :-)Fri, 18 Mar 2016 09:58:11 GMTMSpiteriComment by Fredex8
http://answers.unity.com/comments/1156570/view.html
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][1] 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);
[1]: http://docs.unity3d.com/ScriptReference/Transform-eulerAngles.htmlThu, 17 Mar 2016 18:09:58 GMTFredex8Comment by elenzil on elenzil's comment
http://answers.unity.com/comments/1156539/view.html
agreed. `Mathf.Approximately()` is a much better approach than going through `Mathf.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! IMO it's also easier to understand the intent of the code.Thu, 17 Mar 2016 17:16:22 GMTelenzilComment by Dave-Carlile
http://answers.unity.com/comments/1156494/view.html
[What Every Computer Scientist Should $$anonymous$$now about Floating-Point Arithmetic][1]
> 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.
[1]: https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.htmlThu, 17 Mar 2016 16:00:12 GMTDave-CarlileComment by Eno-Khaon on Eno-Khaon's answer
http://answers.unity.com/comments/1156486/view.html
Another option for number comparison for a case like this, especially, would be use to [Mathf.Approximately][1]. It's intended, by design, to act as the floating point equivalency comparison.
if(transform.rotation.z == 90.0f)
// Less reliable
if(Mathf.Approximately(transform.rotation.z, 90.0f))
// More reliable
[1]: http://docs.unity3d.com/ScriptReference/Mathf.Approximately.htmlThu, 17 Mar 2016 15:53:36 GMTEno-KhaonAnswer by Theli
http://answers.unity.com/answers/1156332/view.html
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.Thu, 17 Mar 2016 15:22:12 GMTTheliAnswer by Kamil1064
http://answers.unity.com/answers/1156334/view.html
@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 stuffThu, 17 Mar 2016 10:55:53 GMTKamil1064