|
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)
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.
(comments are locked)
|
|
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):
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. Minor correction: you can in fact use Euler angles to describe every possible rotation of an object (gimbal lock doesn't have any bearing on what orientations can and cannot be represented).
Oct 19 '10 at 05:56 AM
Jesse Anders
Well yes, but you cannot go through them in sequence without making some corrections. As I stated - you can in fact represent any quaternion in several different ways using euler angles.
Oct 19 '10 at 12:59 PM
Cyb3rManiak
I see - I think it was just a wording/interpretation issue (i.e. I read your statement differently than you intended it).
Oct 19 '10 at 02:16 PM
Jesse Anders
I think I'm starting to understand. Well, for now I've used a scripted alternative. Using a value that I clamp between wanted angle, and set this value to the rotation. Instead of reading the rotation from the engine, so far it works well. But I'll keep in mind your way If I run into future blocks and gonna do some research on quaternitions. Thanks.
Oct 19 '10 at 05:21 PM
Oninji
@Jesse - Thanks, I see your point now, and I've tried editing my answer to make it clearer if anyone sees this post later on...
Oct 20 '10 at 10:34 AM
Cyb3rManiak
(comments are locked)
|
|
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) Well, when on another object I use this on the Y angle, and there's no error with the Y rotation. It's only the X rotation. I'm currently working on a way to make rotation dependant of a variable as an alternative, and so I could check on the Variable instead. Meanwhile, I'll also check if there's an alternative using Mathf, but I'm not sure, but well it's worth a shot. If I could find a way to get reading of the object "True Rotation Angle" it would be truly the most simple way.
Oct 18 '10 at 10:30 PM
Oninji
It's neither a bug nor an error. Also, there isn't a 'true rotation angle' as far as Euler angles are concerned. If you want the pitch/elevation angle to be computed in a certain way though, you can store and update the rotation angles yourself and then build the orientation directly from them, or you can compute the angles from the direction vectors using trig,
Oct 19 '10 at 05:53 AM
Jesse Anders
(comments are locked)
|

This description makes little to no sense. What is a "proper angle"? What do those values mean? What are you doing when you get those values? It's next to impossible to answer a question that doesn't make sense and, while it is apparent that your English is very poor, could you please rephrase the question into something clearer?
Also, try using Transform.localEulerAngles.x and post back if it helps or not, and if it's closer to what you would expect to see.
The big itself does little sense. It is as I say, What the X rotation reading return isn't the angle of the object On screen.
Added a video, and local or not it doesn't work better.