Before submitting a bug report I want to make sure I'm not the only one seeing this.
In each viewport it's displayed the only axis that's actually not needed - the axis corresponding to the view, Y for top, etc. - since there's the bigger circle with which you can rotate in screen space.
I'm thinking it might be related to other clipping/transparency issues for which I've already filed reports.
Also, there's no grid in the sideview.
Anywone experiencing these issues?

Gizmo is aligned to world.

In the rotate handle, axes that are perpendicular to the view plane are hidden by default, you can enable them in the handle prefs.

In the ortho views, the axes that are not the view direction will always be perpendicular to the view plane.

Rotation in 2D is undefined about any other axis, so I don't see why you are saying the only axis that ‘isn’t needed' is visible, as this is literally the only rotation axis that exists in that plane. This is akin to how the Z translate handle hidden in front/back ortho views.

jsmack
In the rotate handle, axes that are perpendicular to the view plane are hidden by default, you can enable them in the handle prefs.

Thanks.
In what situation is this helpful (having those axis hidden)?

I dont think I quite understand what you said after that. All I can say is that by “not needed” I meant “redundant” because you already have the bigger circle by which you rotate in the screen space (orto view) and I was referring strictly to the case where the handle is aligned to World.

jsmack
Rotation in 2D is undefined about any other axis, so I don't see why you are saying the only axis that ‘isn’t needed' is visible, as this is literally the only rotation axis that exists in that plane. This is akin to how the Z translate handle hidden in front/back ortho views.

How do you mean that? Say you're in topview, you mean I can't rotate about X or Z axis? I don't know what you mean by “undefined”, nor do I understand the analogy with Z translation, because unlike translation, one can rotate by any axis when in a orto-view.

Right, so the handle preferences does solve the issue ya? It does here.

@Jsmack - are you sure about the orthoviews and axis rotations. AFAIK ortho views are simply perspective projections without using the w co-ordinate for scaling.

McNistor

jsmack
Rotation in 2D is undefined about any other axis, so I don't see why you are saying the only axis that ‘isn’t needed' is visible, as this is literally the only rotation axis that exists in that plane. This is akin to how the Z translate handle hidden in front/back ortho views.

How do you mean that? Say you're in topview, you mean I can't rotate about X or Z axis? I don't know what you mean by “undefined”, nor do I understand the analogy with Z translation, because unlike translation, one can rotate by any axis when in a orto-view.

Yes, in top view, the z rotation has to pass through an imaginary axis. It is true the ortho view is merely a projection of a 3D space, making the imaginary axis not so much. However, since the purpose of the view is to eliminate the influence of the projective axis on the geometry, it follows to eliminate controls that affect the imaginary plane. The projection also has the affect of making the controllers difficult to use since they are rendered edge-on, and the mouse input would become very non linear.

As for the redundancy of the axis rotate controller and the view axis controller, the controllers do not change simply because the view makes them redundant. It is possible to have non-axis aligned ortho views as well.

aRtye
Right, so the handle preferences does solve the issue ya? It does here.

Yes, it does for me too. I was just curios as to why does such a feature exist, in other words, in what situations is it useful to have those axis hidden. The active by default feature works for when the gizmo is perfectly aligned to world because either the object has 0 rotation or the gizmo's alignment is set world and only in these cases.

jsmack
Yes, in top view, the z rotation has to pass through an imaginary axis. It is true the ortho view is merely a projection of a 3D space, making the imaginary axis not so much. However, since the purpose of the view is to eliminate the influence of the projective axis on the geometry, it follows to eliminate controls that affect the imaginary plane.

I'm assuming you meant Y axis for topview, but what you said after that I don't follow.

jsmack
The projection also has the affect of making the controllers difficult to use since they are rendered edge-on, and the mouse input would become very non linear.

Well, the difference between perspective and orto regarding axis manipulation with the mouse is so small in favor to persp that it doesn't make any sense to drop the useful feature of being able to rotate by any axis in orto views. Not to me at least.

jsmack
As for the redundancy of the axis rotate controller and the view axis controller, the controllers do not change simply because the view makes them redundant.

Yeah, but apparently they change because two rotation axis are a bit less convenient to use due to non-linear input, so anything's possible by the looks of it. I might've been misunderstood about this point - I didn't intend to suggest to have the rotation axis correspondent to the screen space (e.g. Y for top) removed, I just was bewildered by the fact that the least needed (because of redundancy) axis is shown while the other two are not.

I still have not understood how is this feature useful even though you clearly tried, but I think that regardless of its usefulness, that feature ought to be off by default. Or this thread about an “axis bug” will obnoxiously resurface like that body that won't stay bottom.

McNistor
Yes, it does for me too. I was just curios as to why does such a feature exist, in other words, in what situations is it useful to have those axis hidden. The active by default feature works for when the gizmo is perfectly aligned to world because either the object has 0 rotation or the gizmo's alignment is set world and only in these cases.

In many instances you'll have a handle with both the translate axes and the rotate rings. In these cases, the edge-on rings, that you probably don't want to manipulate, will tend to obscure the axes, which you do want to manipulate. This is why we default to hiding those edge-on rings.

Hey Ondrej, that's a good explanation (finally) for why is there such a feature. To me it seems like a solution to an unnecessary problem (you know how I feel about the Y tool, nothing but bones is left of that horse) so I'm thinking, if it's technically possible, that the enabled by default feature should be restricted to the Y tool. For the pure rotate tool it makes no sense, I hope you agree.

edit: I feel like mentioning that whenever I say “I feel like” I'm actually saying “I think that”

Taking another look at this now, I think I misspoke earlier. For the Y tool we hide the edge on rings regardless of that preference setting, so there's no reason I can see that we shouldn't just change the default to showing those rings.

I've changed it for the next major release. I'm not going to bother porting back to 16.0 since daily builds will just use the currently set preferences anyway.

That's great man! However, you sure you don't want to commit this change for v.16 as well? If it's not a big time investment I think it's beneficial for those that usually delete their prefs. (like me) when installing a new build to make sure everything's pristine. And then there's the new occasional user for whom this feature is confusing and frustrating…
I'm just wondering, I personally don't mind one more click when I go to prefs. on a new build to change my handle from the Maya like (now default) style.

Hi I have prob with gizmo
after some turns two axis are in not proper position.
am i doing something wrong?

thnks