koobas.hobune.stream
When applying a 90 degree rotation to Euler Angles, it is over/undershooting sometimes..
HI,
All I'm doing is simply changing the euler angles and all numbers are adding up before the line where I apply the change, but sometimes, well quite frequently actually, the target is overshot... Any good reason for this.. The code looks similar to this:
transform.eulerangles = new Vector3 ( transform.eulerangles.x + 90, 0.0f, 0.0f );
It just overshoots by 1 - 5 degrees, but it is enough to mess things up..
The code you have posted does not overshoot, so it's com$$anonymous$$g from somewhere else.
Ok, new news, it is fed the correct info, but it becomes a parent of multiple objects before the new eulerAngle is calculated. I printed out the outcome of the eulerAngles.y calculation before and after it becomes a parent and the outcome is correct before it is a parent and incorrect after it becomes a parent. It goes from 270 to 360 before it is a parent and 270 to 1.001791E-05 afterwards.
Why is this happening? And how do I solve this?
I have now tried changing it to a quaternion rotation and I'm getting the same result.... Please help!!
OK, I solved the issue.. Well, the problem with the eulerAngles proved impossible to fix even when I un-parented the objects and rotated everything separately using eulerAngles there was an error. It seems as though anytime that you feed the number 360 to a eulerAngle float it turns into 1.001791E-05. So, I tried to ensure that when close enough to the target rotation while it was 360, just make that value 0, but this caused other issues because directly changing the eulerAngles seemed to give very strange results, like I would change it to ( 90, 270, 0 ) and it would jump to ( 0, 180, 0 ) for example because I don't remember the exact change
What I had to do, is change a lot of stuff.
No parenting, although it would probably work fine with the new structure.
No looking for objects based on specific positions because the Vector3 positions of the objects that I was rotating were reading out as way off and my code failed to find them in the way I originally planned for. It was very strange though because the Vector3 xyz positions read out wrong, but the objects were in the correct positions when looking in the game, otherwise there would be noticeable gaps.
I used raycast to find the objects to rotate because of how hard the were to find by their expected positions. I think this new structure in my script is optimized with the ray casting because I have eliminated a lot of the process I needed for finding the correct objects, it was pretty heavy before.
I used RotateAround() for rotation of all objects because it gives good results and thanks Baste because your suggestion for orbiting a point at a constant speed lead me to find this as a viable option.
Thanks Baste and nirharpaz for trying to help. I think, in the end, I would call it a bug..
are the parent objects have rotation of 0 all the time? be aware that the overall rotation is sum of all the rotations of the objects and all its parents up to null (the no-parent).
I can assume that you may be rotating the object in local space and then trying to use it's transform.rotation which is calculated in world space.
please print (transform.rotation) and (transform.localRotation) and see if you get the same results.
it is the parent of objects and is not a child of any object.
Sometimes it works perfectly and other times it is off by a little bit, but this tiny error positions the children objects where I can't find them by script and messes everything up.
I now save the result of the rotation, which is 360, in a variable before I parent and apply the variable to the appropriate eulerAngles axes and I still have the error. Even though I directly change it to 360, after printing it out on the line afterwards, it reads: 1.001791E-05
Now, since this has 9 children spread out, the positions of the far children are way off what they need to be.
1.001791E-05 is not very much.
This probably happens because the conversion between Euler angles and Quaternions suffer (like most other things) from floating point errors - ie. any operation might result in small errors.
That value, though, is so low that you can't zoom in far enough to see it. So if you're seeing unexpected results, the error lies somewhere else.
I see. That would cause a problem, yes.
If you've got something that's really far away from the rotation origin, floats will throw you off. Simulating large universes in Unity out of the box will have some major issues due to exactly that.
I would replace the parent-based rotation on such objects with something that's calculation-based, since it's easier to make sure that you're moving at a somewhat constant speed along an orbit. If that's what you're trying to do, anyways.
