How Can I return the rotation value I entered into the inspector?

So I had made a cube and rotated it's z to 40. But when I typed this:


void OnGUI()
{
GUI.Label(new Rect(10,0,150,150), (Mathf.Rad2Deg*transform.rotation.z).ToString());
}

Then the number on the screen that appeared was not 40, it was like 19.278138 or something.

What's with that? How do I get it to give me the value that I inputted in the inspector?

 

Not sure. Maybe its because of Mathf.Rad2Deg.

Try removing it and try again.

 

Transform.rotation is a quaternion, which is a 4D struct, and it doesn't use degrees. Don't attempt to use individual elements of quaternions unless you thoroughly understand them. Probably you meant to use eulerAngles, but there's more than one valid way to convert quaternions to eulerAngles, so again attempting to read individual elements isn't recommended. For example, if you have an object rotated to (180, 180, 180), printing eulerAngles.z will give you 0 (or close to it).

--Eric

 

I see.... So how would I use eulerAngles to get it to where GUI returns 40?

 

Is there even a way to retrieve that specific value?

What is the point of setting rotationx/y/z/ in the inspector if you cannot retrieve that value? Or am I missing something here?

 

The point of setting the rotation in the inspector is so objects can be rotated the way you want. Typically you'd track rotation axes yourself if you want to read a specific axis, like the standard assets mouselook script does.

--Eric

 

Are you telling me that the value that I punch into the inspector for the rotation of an object cannot be retrieved?

 

It can be, but see my first post in this topic.

--Eric

 

I see your post, I must have read it over at least 20 times. I cannot extrapolate from it the part of it that tells me what I'm supposed to do in order to retrieve the value I put into the inspector.

And yes, I have been tinkering with Unity all the while with no progress on the subject.

 

As I said, you can retrieve the value, but it may not be what you expected, since there is more than one valid way to convert quaternions to eulerAngles. You would typically track the axis yourself, which is shown in the standard assets mouselook script. And that's about all I can say since I'm just repeating myself now.

--Eric

 

I see that you are repeating yourself. So perhaps I should explain what I am trying to do in more detail so as to try and allow you a better picture of how my problem is. Because it has nothing to do with this "mouselook"ing you seem to imagine that the problem is about.

I've got these plane objects, and have them set up with different rotation zs, I would like to make it to where a bullet that travels above them will do so in a direction that is parallel to the rotation z that I gave to the plane that is below them.

I have it currently so that the bullet will check if there is a plane beneath them with simple math, you know, if it is within the x-range of the plane and above it. And that the bullet travels in the 2D angle "move_angle"

The issue is that I am unable to retrieve the value that I punched into the rotation z on the planes from the inspector and thus cannot properly give move_angle the correct value.

 

You don't have to. Just set the bullet's transform.up to match the plane's transform.up

 

Hypothetically you are correct, however for reasons that are a bit hard to explain, I really need to be able to retrieve the value that I put in the inspector for the rotation z of the planes.

 

Why?

 

*Sigh* a constant problem I have with this community is that instead of trying to help guide the greenhorn to the solution to the problem the way they frame it, people instead propose "easier" alternatives. I am new to unity and, and have been using Game Maker's GML for the past 9 years to make games, and that is the mindset that that my game design flow is built upon.

Unity's conventions to do things, like the mechanim, or transform.up theoretically do make things easier, but at the same time they do not yield the same kind of answers that I am seeking. Right now I am seeking a particular bit of information, and that bit of information is a known value to me, it is 40, but it could be something else, which would just as easily be a known value to me, because I set it personally (33, 20, 10, 5 whatever). The issue is that I find it hard to believe that it is so hard for unity to retrieve that value, a value that never changes throughout the game for that particular instance of that object, mind you.

Why I need the value that I input in the inspector for rotation z is not important for you to know. There are a ton of uses that I could have that value used for. All you need to know is that that is the thing that is the value that I am trying to retrieve, and I need it in such a form that I can say it something like this:

float move_angle = the_value_i_set_that_planes_rotation_z_to_in_the_inspector;

 

Specifically - the field you are looking for is transform.rotation.eulerAngles.z - but, as has been stated previously, this might not be "40" although it will still mean the same thing.

Asking what you're trying to achieve in order to offer alternative methods that you haven't thought of is not a feature unique to this community - nor is it a detrimental one. All you've offered to this point is that you want a bullet to rotate so that it will match the "ground" underneath it - for which a method was provided. Beyond that, it appears to have simply boiled down to "because I want it this way" which is rarely a valid use case. You want it to be 40 because you know you entered 40 in the inspector - the real question is why the value of 40 is important in the first place.

 

It may not be unique to this community, but it was not so on Game Maker Community, where people would tell you the answers to the question as framed by the user.

You want to know why your easier alternative method is meaningless to me? For my project I pretty much have reshaped the way the physics works to be more akin to how it is in Game Maker, because that is what I know. Ergo all these fancy features are not in use for my project. I have already stated that I have it set up to where the object will move based on the "move_angle" float, did I not? It does this with simply sin()*move_speed and cos() *move_speed coding.

And that is why I need a way for it to return the exact value that I punched into the inspector. I have seen that transform.rotatation.eulerAngles.z does not return "40" and would like to know how to turn it into the proper value that was inputted into the inspector with accuracy.

 

So it appears that the reason truly is "because I want it that way". I'm not trying to be a jerk but it just seems odd that you're fighting with people simply because you don't like the perfectly valid answers they're giving you. In all honesty, what you're "used to" is irrelevant when searching for a solution to a problem because what you're "used to" are paradigms from a different engine - that also happens to be two-dimensional in which rotations are far simpler than they are in three-dimensional space.

In either case - do your bullets always move forward in the direction that they are facing? If so, here is some code to facilitate that behavior. I don't know whether or not this is what you're used to in Game Maker but the solution to what you're trying to achieve can't get much simpler than this - and ultimately isn't that the most important thing?

Code (csharp):

1.  
2. bullet.transform.up = plane.transform.up;
3. bullet.transform.position += bullet.transform.forward * move_speed * Time.deltaTime;
4.  

 

See it how you want. But the system I've already set up for my game is such that it doesn't utilize things like "transform.up" or "transform.forward". It is not simply "because I want it that way" it is rather "because that is the way I have set things up in the game thus far."

And what I am "used to" is not "irrelevant when searching for a solution to a problem because what you're used to are paradigms from a different engine- that also happens to be two dimensional in which rotations are far simpler than they're in three dimensional space."

I've ONLY ever used Game Maker to create 3D games:

And even if it were from 2D to 3D, the logic and math would remain true regardless of the engine used to create the game. I know for a fact that if I can retrieve that rotation z value that I inputted in the inspector that I can have things running in a way that fully supports the way I've built my game so far. And just so you know, the game that I'm working on right now is a Super Smash Bros clone, which plays in only 2D anyway:

Like I said earlier, your method is technically valid, but it won't work with the movement system I have put into effect with my game already, which completely denies a lot of the standard concepts of movement in Unity in favor of making it more similar to Game Maker.

All I'm asking for is a means to retrieve the rotation z value that has been applied to an object from the inspector. Also maybe I should note that both the rotation x and rotation y of these rotated objects will always be 0.

 

It's not about mouselook. As I said, keeping track of rotation yourself...like the mouselook script in standard assets does. So you could just look at that script and see.

--Eric

 

It looks like you guys are both getting a bit frustrated. I'll see if I can help any. I don't really have much to add to what Eric's already said, but perhaps I can say it in a different way.

In 2D, rotation is a scalar value — a single number, a point on the real number line. Though even that's not quite true; a rotation of 370 degrees is exactly the same as a rotation of 10 degrees or -350 degrees. But that's the only complication there is to it (and I'm sure you're already comfortable with that one).

In 3D, rotation is no longer a scalar value. It's a three-dimensional value. It's often thought of as roll, pitch, and yaw, but those are pretty arbitrary. Any three sufficiently separate rotation axes will do. It's important to note that the order in which rotation about the three axes is applied is very important; a roll followed by a pitch does NOT get you the same result as a pitch followed by a roll. I find the best way to convince yourself of this is to try it with a Rubik's cube.

Further complicating the picture, for reasons we won't go into here, it's often quite convenient to represent it as a 4-dimensional value called a quaternion. (Only a subset of the full 4-D space represents rotations, but in game programming we generally restrict ourselves to exactly that subset.) Quaternions let you do all sorts of neat things, like efficiently combine rotations or interpolate between two orientations. They also avoid some problems that can occur when working with only Euler (roll/pitch/yaw) angles. However, beginners often find quaternions mysterious and hard to understand.

OK, so, getting back to your question. You are coming to this discussion with the belief that it must be possible to get out exactly the value you have assigned to one of the Rotation fields in the inspector. It's not. Period, end of story, no matter how much you want it, it is not (in general) possible. So, start by abandoning your belief that this is possible.

Now, if you've successfully let go of that false belief, I expect you have either or both of these follow-up questions:

1. Why is it not possible?
The reason is that, as soon as you enter a rotation value in the Inspector (or assign to transform.rotation using Quaternion.Euler), the Euler angles you enter are converted to a quaternion. And when you inspect rotation.euler, you're converting that rotation back to Euler angles for your convenience. This round-trip conversion will give you a set of euler angles which are equivalent to what you started with, but which are probably not the same values. The mapping between quaternions and euler angles is not unique. Unavoidable mathematical fact, I'm afraid.

2. What do do instead?
This is probably easy: stop trying to look at the transform itself for the Euler angles you seek. Instead, keep your own Euler angles, and look only at those, the angles you yourself are keeping track of in your own scripts. Eric has pointed out the mouseLook script as an example of this approach. We still don't understand what you're trying to do well enough to suggest a more specific example, but the basic idea should be the same: make your own rotation property or properties, always update those, and treat transform.rotation as a write-only property.

There is one hitch in this plan. If you are applying physics, so that your objects are rotating outside your direct control, then you can't do this; you'll have to read the rotation out of the transform to see what the physics engine has done to it. In this case, you'll have to abandon your belief that getting back the exact same values set in the inspector is important. Neither Eric nor I can see why this should be important, but if you want to try to explain in more detail, perhaps we can suggest some alternative. (For example, there are functions to find out which way is "forward" for any transform, functions to find the angle between two vectors, etc... some combination of these may do what you need.)

HTH,
- Joe

 

Alright Joe, thanks for telling me that. Why didn't Eric say it that way? He kept on making it sound like it WAS possible to get that rotation value back. And that is why I kept on pressing; although he made it sound like it was possible, it was just a red hearing all along.

And now that I know that it is impossible I know exactly how to solve this problem: In it's script I'm making saying : public float rot;

And in the inspector, I'll just copy and past whatever I put in the rotation z slot into rot, and refer to the rot value.

 

Yep, sounds like that should work!