3D rotation around the Y axis is stuck in [-90;90], other components being adjusted to make up for it

[DimaKiva]

Hello. Not correct receive object orientation on Y axis in 3D mode.
obj_rot_y = get_node('test_cube').get_global_transform().basis.get_euler().y
If the object is rotated more or less than 90 degrees to the transformation of adjacent axes and thus takes the opposite effect on the axle.
This problem is only with the axis Y in 3D.
Godot v.1.0

[akien-mga]

Can you still reproduce this issue in the current master branch/nightly builds?

Also note that the Y+ axis is oriented upwards in 3D if I understood correctly (and not downwards like in 2D).

[DimaKiva]

The problem is still there, if you rotate the cube on the y-axis, you can see some strange values are obtained.

[EroyalSD]

I can confirm this is still happening in v2.0.3.stable.official.

[akien-mga]

I can reproduce too in the master branch, I'll investigate.

[akien-mga]

The issue probably needs to be debugged somewhere around here: https://github.com/godotengine/godot/blob/b3b1fda/tools/editor/plugins/spatial_editor_plugin.cpp#L1456
I had a quick look but I'm too bad with 3D geometry to do anything ;)

Steps to reproduce the bug:

• Reset rotation to (0, 0, 0) for better visibility
• Rotate over the Y axis:
  • From 0 to 90°, everything goes fine (apart from the fact that the X and Z components are set to -0 instead of 0, but it's no big deal)
  • When 90° is reached, X and Z are changed to -180, and dragging Y further will make the Y component to decrease from 90° down to -90°.
  • Dragging further, the X and Z components are reset to -0, and the Y component goes up again from -90 to 0.

i.e. the Y component is stuck in [-90; 90], and the two other components are adjusted accordingly to make up for this limitation.

[akien-mga]

Based on the duplicates #2153 and #2845, this is not only a bug that affects the spatial editor plugin, but the processing of the rotation Y component in all contexts.

[reduz]

As mentioned in the other issue, this is not really a bug, but something more relative how euler angles work That said, we have marked this as something that should look better in 3.0 (some research needs to be done).

[akien-mga]

What's the state on this topic in the current master branch? Was it by chance improved by @tagcup's work?

[DimaKiva]

What's the state on this topic in the current master branch? Was it by chance improved by @tagcup's work?

Godot 2.1.4-beta does not start.
In Godot 3.0-alpha the problem remained.

[reduz]

You mean the x axis lock? I see this as a feature, not a bug..

…

On Jun 28, 2017 12:20 PM, "Tort" ***@***.***> wrote: Godot 2.1.4 does not start. In Godot 3.0-alpha the problem remained. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1479 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF-Z20jE1A4LrcKaTy0bUF3wLP6wteL8ks5sIm9AgaJpZM4Dp0HM> .

[DimaKiva]

I see this as a feature, not a bug..

Well, it's not a bug, but it looks weird. Example: In the inspector, you can manually set the value [0,100,0]

and the object will turn predictably correctly,

but in the viewport arrows can not set this value.

[ghost]

It's interesting that this only happens with Y-axis which makes me think this may not be related to using Euler angles in the property editor.
I'm a bit busy these days but I'll definitely check this.

[reduz]

@tagcup I still sustain this is not a bug, as it will always depend on the order the angles are extracted.
I think, however, that we could probably come up with an algorithm (if it does not exist already) to detect when only one or two cartesian angles are used for rotation and display it in a more user-friendly way..

[ghost]

I apparently misunderstood the issue in the first place, I agree with @reduz that this is not a bug anr it's just how Euler angles work.

The reason is as follows. There is no one-to-one correspondence between an orientation in 3D space, and 3 Euler angles that can be used to parametrize such an orientation, because Euler angles span a 3-torus which is topologically different from a 3-sphere.

Nevertheless, I think this is still confusing for users. The proper way to solve this confusion is to use axis-angle parametrization in the property editor.

[ghost]

Well actually, even with axis angle parametrization, there is still a degeneracy: flipping the sign of the unit rotation axis vector (which is typically parametrized using angles in spherical coordinates, and reversing the vector means adding pi/2 to the polar angle) and the rotation angle simultaneously will result in the same rotation. In my opinion, this is still easier to understand, because understanding this degeneracy requires only basic algebra, and not any understanding of the rotation group SO(3) or topology.

So maybe I should just add a warning/explanation about this in the upcoming math tutorial.

[ghost]

@reduz I think you missed my last reply above, where I explicitly mention this particular symptom:

The problem is when you rotate via editor gizmo.

That's just one of the symptoms of the underlying problem, which is that Euler-angles are an ill-defined mapping for rotations. And there is simply no way you can fix Euler angles such that you won't have discontinuous jumps like that.

[ghost]

I'm completely against axis-angle parametrization as it's totally not user friendly.

As someone who almost everyday use axis-angle parametrization (that's just how Lie groups work) at work (which is theoretical physics, so I can guarantee you I've got a lot more experience with unitary/orthogonal decompositions and [gauge] transformations), I can't disagree more. I can understand "unfamiliar", but they're actually much more intuitive and user friendly; I think when it comes to orientation, you're just used to thinking in terms of Euler angles, but they work only in simplest cases and quickly get out of hand for any non-trivial orientation/rotation.

But then, you're the project owner, so if you want to stick with Euler angles despite all the unfixable mathematical troubles they're associated with (which I tried to point out above), there isn't much I have left to say on this topic.

[reduz]

But then, you're the project owner, so if you want to stick with Euler angles despite all the unfixable mathematical troubles they're associated with (which I tried to point out above),

The problem is the use case here. Most of the time the angles are used to do a very simple local rotation manually, or for doing simple animations. For this, these values work more than good enough.

I'll try to implement what I mentioned before, I think it's perfectly doable..

[Zireael07]

How about we give axis/angle a try, but accompanied with some documentation (script template, tooltips, whatever) introducing it?

[reduz]

commit above fixes the problem @DimaKiva was having, but I will try to do something more interesting, let's see if I succeed...

[ghost]

@reduz I understand the unwillingness against having something unfamiliar as a part of the UI, but you really can't solve this issue without switching away from Euler angles.

This will just shift the issue from "3D rotation around the Y axis is stuck in [-90;90], other components being adjusted to make up for it" to "a certain region on the 3-toroid which spans the Euler angles is inaccessible region, other components being adjusted to make up for it", and users will still see sudden jumps in Euler angles as they change the orientation in the spatial editor.

[DimaKiva]

Now I see that this is not a bug. But a beginner is easily confused (such as me).

[ghost]

@Zireael07 I really think it can be even be made artist-friendly. In the property editor, we can have an widget for editing the axis, which would allow the user to choose a point on a unit-sphere (or to choose polar and azimuthal axes separately).

[reduz]

@tagcup as I mentioned, I know you are dead set on them, but It's missing the point. You are thinking euler angles are a problem for an use case that does not exist.

[reduz]

in any case, the initial bug reported is fixed, so closing this.

[ghost]

for an use case that does not exist.

If you're saying users can rotate only around the Y-axis in the spatial editor, then yes, I'm talking about a use case that does not exist.

Otherwise, this issue remains: the only difference you can make with such workarounds is to shift it from Y-axis (as in the issue title) to a different axis.

I understand you want to close many issues and get on with 3.0 as soon as possible, but frankly you're being dismissive rather than rational here.

[reduz]

@tagcup No, I insist you don't understand the use case for the rotation property exposed in the Spatial node. In real use cases, this is used most of the time for single-axis rotation, and to make simple rotations for animations. It's too difficult, as you mention, to use it for something else but it serves it's intended use fine.

For anything else you can rotate visually or even interpolate the transform, or use matrix math in code. Trying to make this property more complex is like trying to kill a mosquito with a bazooka.

[reduz]

@tagcup also, what was reported by @DimaKiva was marked 3.0 and is now fixed, so there really is no reason to leave this open. It's not my unwillingness to discuss this.

In fact, If you want to suggest using axis angle for rotations, or even make a test (PR) showing that it can be useful, feel free to do that. Issue count is not really the problem.

[ghost]

Nah, I give up. It'd just be an implementation of what you're already against.

Let me at least note that there may be issues in the future from confused users complaining about "unexpected" jumps in Euler angles as they rotate the object in the spatial editor.

[reduz]

@tagcup sorry, I didn't mean to upset you. I'm not against what you propose, but my aim was always closing this issue. If it really works better and users find it friendly, I have nothing against it. I just think it was beyond the scope of this specific issue, which was solved by a small hack I added to get_euler()

[ghost]

@reduz Ah, no no, no worries, I didn't use the word "against" as an emotional response, I was just referring to what you said earlier:

I'm completely against axis-angle parametrization as it's totally not user friendly.

I guess I can ask for some feedback from artists about it.

[reduz]

@tagcup ah yeah, but it's in the scope of this use case. if it can be done well, I might be interesting, but I just can't picture it in my mind.

[ghost]

OK, so I got some feedback about this: The difficulty with the axis-angle parametrization isn't that the concept is complicated (it's actually simpler), nor the simplicity of the UI for setting the axis. The difficulty is to find the axis corresponding to "simple" orientations, which is the only use case for using Euler angles.

I guess there are several important things here:

1. Visualizing the orientation corresponding to a given set of Euler angle parameters is only possible for very "simple" orientations (more on the meaning of "simple" later). With axis-angle parametrization (two polar angles for the rotation axis, and the rotation angle), this is pretty easy.
2. There are two uses major cases: general rotations, and orientation (which is essentially rotation starting from the initial condition with basis=identity). For orienting stuff, finding the rotation axis for a given orientation, starting from the initial condition isn't easy. It's only easy when the rotation axis readily comes from somewhere else. This is true for, say, physics calculations involving rotations. Not so much for how people think of orienting objects.
3. And finding the Euler angles for a given orientation isn't easy either, except for a few trivial cases.
4. But, the typical way people think of orienting stuff isn't like starting from a given orientation and decomposing it into Euler angles; instead, they do it organically: they start with an object, take the first Euler rotation axis, decide on a rotation angle, and do the same for second and third angles, in this order.
5. For other use cases (meaning, rotating stuff in the spatial editor with mouse), it doesn't make any difference in terms of usability whether we're using Euler angles or an axis-angle to parametrize the rotation.

From which I conclude that axis-angle isn't worth it (despite this issue, which is arguably not an issue in the first place).

But now, after imagining going through this "organic" process, I realized that, for this to be useful, the "up" axis has to be either the last (or first) axis in this sequence, because up axis is the axis you'd most likely to set to a non-trivial angle (meaning not an integer multiple of 90 degrees). I think this is why Unity uses YXZ (which was brought up in #9905) and Blender uses XYZ, and I think we should switch to a convention like that, maybe YXZ (while we can, since 3.0 isn't finalized yet).

What do you think @reduz?

[reduz]

@tagcup I'm fine with YXZ if you want to implement this, isn't that called YawPitchRoll or something like that?

[ghost]

Cool! I'll submit a PR later tonight. I'm actually not that much familiar with engineer's jargon on rotation axes for vehicles, but it seems they would call it yaw, roll, pitch.

Just as an added note: this wouldn't break existing scenes since they store basis/transform as a matrix, and Euler angles in the editor are derived from that.

[DimaKiva]

:)

func get_rot_y(node):
	var rot = node.get_transform().basis.transposed().get_euler()
	var rot_y = 0.0
	if rot[0] > -PI/2 and rot[0] < PI/2:
		rot_y = rot[1]
	else:
		if rot[1] > 0:
			rot_y = PI - rot[1]
		else:
			rot_y = -PI + abs(rot[1])
	return(rot_y)

[crabctrl]

I'm not quite sure, but I seem to be having this issue, and I am using the latest stable (v2.1.4.stable.official). Pitch and roll seem to work fine, but get_rotation().y gets stuck at about 90 degrees... am I missing something, or is this bug still a thing?

EDIT (for more details):
I am using a Rigidbody in character mode (obviously 3D)