Proper X Rotation Angle Detection.

Questions & Answers
1

Hellow, I need the be able to read the proper angle of my object.

But when I read it from Unity in my script,

(the reading part of the script)

AngleX = transform.eulerAngles.x;

It read it quite awkwardly,

It goes from 360(0) to 270, then from 270 to 360(0), then from 360(0) to 90, then from 90 to 360(0).

That's readings I get, on a SINGLE full rotation.

Edit:

Here a video http://www.megaupload.com/?d=WIEMPF70

Youtube for the ones who do not want to download a file. http://www.youtube.com/watch?v=gfTcPG7Nfd4

Just look the X Angle value in the inpsector, and you'll probably understand.

2

This has to do with the way unity converts its native rotations (Quaternions) to Euler Angles (Vector3). If you look at the transform in the inspector, the Y and Z rotations are changing when you hit certain points to compensate for the conversion. If I were you, I'd look into having a function that relies on Mathf.Angle and not Quaternion to Euler conversion (mostly because I am afraid of Quaternions)

3

Ok. Now I understand what you were talking about.

You must understand that there is a big difference between Quaternions and Euler angles. You cannot use Euler angles to describe every possible rotation of the object if you simply rotate along the axes in an arbitrary way without some forethought, since there are cases in which a situation called "gimble lock" occurs. I won't go into explanations about how and why this happens, and ways to solve it. You can do a search in youtube or google. Plenty of material exists on this, but those flips you see (one of the axes you're not editing must be modified) are done to avoid that situation.

Anyway, just like Adam said - internally Unity stores the rotation as Quaternions. What you see exposed in the inspector is a representation of the local rotation in Euler angles, which can differ since there are several ways to describe each quaternion in euler angles, and to avoid gimble lock a representation which is less readable to you as a user is used, but will not produce gimple lock internaly. If you're going to rotate on more than one axis - stop using euler angles, or get frustrated very fast.

If you insist on doing it using euler angles - use the local rotation to your advantage. Setup your model this way (lets say your model has a part called "base", which has a child called "turret" - which moves):

  1. Rotate "turret" to the begining of the rotation where you want 0 degrees to be.

  2. Create a new game object and call it "turretParent". Make this object be a child of "turret".

  3. Enter the position (0,0,0) and rotation (0,0,0) for "turretParent" in the inspector. This will move the "turretParent" to the pivot of "turret" and align it to the exact rotation of "turret".

  4. Make "turretParent" be a child of "base".

  5. Make "turret" a child of "turretPivot".

Now if you look at the moving part in the inspector ("turret") - the rotation will be (0,0,0), even though you moved it before. It's just that relative to its parent ("turretPivot") - it's exactly in the same direction - and so if you rotate it around the X asis now - it will move from 0 to 360 without flipping anything. If you want to start from another number (lets say you want the starting position to be (90,0,0)) - between steps 4 and 5 - rotate "turretParent" 90 degrees on the X axis. Now when in stage 5 you parent "turret" to be a child of "turretParent" - they will have 90 degrees difference, and instead of saying (0,0,0) the inspector will read (90,0,0) even though the turrent is in the same position. It's just that it's rotation is now shown relative to the new game object, and not the base.