koobas.hobune.stream
How can I have a 0,0,0 rotation value of every single bone inside Unity?
Hello fellow artists, riggers and Unity-devs,
I have a question about a Unity-3dsMax rig exporting issue. I am trying to get a rigged skinned character from Max in Unity with 0,0,0 rotation value of every single bone. I have shown a simple example here to show the problem. In Max the bones already have an inheritant world space rotation values that I have reset to 0,0,0(local is 0,0,0). However when exported to Unity those bones take on new rotation values.
Why does this happen? How can I have a 0,0,0 rotation value of every single bone inside Unity?
Thanks a lot in advance!!! 
@DiegoSLTS, @getyour411 Thank you guys for the detailed replies! There are still values like -90 which doesn't have the -e . Any ideas why?
The world space directions in 3DS might not match that of Unity. Different systems have different world space definitions (for example Z-up Y-forward vs Y-Up z-forward; Unity and UD$$anonymous$$ have different definitions too); many models come in from Blender taking a dirt nap when viewed in Asset previewer but the Unity engine runtime translates and animates them fine as long as the FBX/import was done with the right settings. Are you seeing freaky animations or translations?
Hey @getyour411 I am not seeing any freaky animations because the model is to be used with $$anonymous$$inekt and things work fine there. But we do need those rotation values to be at 0,0,0. I am guessing this is impossible to achieve through 3ds $$anonymous$$ax maybe through code in Unity?
Those values are not exactly 0, but they're close enough. If you look at the full text in the fields they look like "-8.84271e-20", which means 0.00alotofzeros0000884271.
This is usually "unfixable" (I'm not sure it's something you should fix) since in practice those values are 0. If anything you do depends on that small difference you're probably using the wrong approach.
This close-but-not-zero values happen because Unity is doing it's things behind the scenes, and it computes positions, rotations and scales. Since computers have limitations, some times what should be a zero in theorical math it's "close enough" to zero in computers. It happens every time when working with float (or double) variables, not only around the zero, you could do some simple math and will be surprise that the result is not what you get on papers.
Good answer. I needed to do some more analysis of the floating point issue affecting my game and came across this article, now I find myself linking it for anyone wanting to know how floating point affects Unity (and 7precision game engines in general).
http://www.davenewson.com/dev/unity-notes-on-rendering-the-big-and-the-small
