When applying a 90 degree rotation to Euler Angles, it is over/undershooting sometimes..

Question

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..

Answer 1

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..

Answer 2

Answer by nirharpaz · Jun 15, 2015 at 06:27 PM

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.

0 Show 8 · Share

highpockets · Jun 15, 2015 at 06:29 PM 0

Share

it is the parent of objects and is not a child of any object.

highpockets · Jun 15, 2015 at 06:32 PM 0

Share

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.

highpockets · Jun 15, 2015 at 06:40 PM 0

Share

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.

Baste · Jun 15, 2015 at 09:37 PM 0

Share

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.

Baste · Jun 16, 2015 at 08:50 AM 1

Share

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.

Show more comments

When applying a 90 degree rotation to Euler Angles, it is over/undershooting sometimes..

2 Replies

Your answer

Welcome to Unity Answers

Follow this Question

Related Questions