I give a bit more details about the issues with the current behavior here:

https://blenderartists.org/t/navigate-gizmo-doesnt-really-work/1133584/6

@Brecht Van Lommel (brecht): Well, the trouble before was that it was very hard to see which axes were pointing towards you vs away from you.

Here the positive axes are pointing towards you:

Here the positive axes are pointing away:

Apart from the position of the X and Y, there's no indication of any difference. That's why I think this patch is a real benefit.

As for the kerning, I agree. There's too much spacing between the - and the letter, making the layout inside the circle look clumsy. It the character spacing could be reduced, it would be nice.

Now the letters are crunched up right against the edge with too much space between the letter and the minus:

It would be nice if we can move them together more and put them in the middle like so:

The perspective and labels help with that problem, but the coloring is problematic in my opinion. This change helps when the view is upside down, but in the more common case where you just rotated around it looks wrong to me. At a glance I do not see the text or axis lines, just the bright spheres.

Testing the patch, the flickering colors when rotating the view are also not great.

I think the negative signs are more disturbing. What if you only change the opacity?
It becomes clear which axis points forwards or backwards:

@Martin Capitanio (capnm) That could work too I think, yes.

In D3936#89284, @Martin Capitanio (capnm) wrote:

I think the negative signs are more disturbing. What if you only change the opacity?
It becomes clear which axis points forwards or backwards:

I like that too, much simpler. Aligning the negative symbol properly is tricky.

In D3936#89284, @Martin Capitanio (capnm) wrote:

I think the negative signs are more disturbing. What if you only change the opacity?
It becomes clear which axis points forwards or backwards:

This screenshot illustrates the current problems quite well. The top row images do almost nothing to distinguish between the positive axes facing away versus toward, in fact the visual cues show otherwise. If the top-left one looks correct for a generic 3D object in that arrangement, but the top-right image looks so wrong with further balls being larger and duller. Like the current behavior, it gets the 3D visual cues completely backward.

To evaluate this requires more than just recoloring a single screenshot. The problems with this screenshot above would be more obvious in practice while actually using it. For example, what would happen in this idea when the closer negative axis ball moves in front of the further positive one? One bad choice would to have the labelled ball in behind occlude the unlabeled ball in front so you could no longer grab the closer ball. The other bad choice would be have the closer unlabeled ball occlude the further ball and therefore could no longer see an axis text at all.

In D3936#89280, @Brecht Van Lommel (brecht) wrote:

Testing the patch, the flickering colors when rotating the view are also not great.

It is not really obvious at first, but the flickering is necessary...

The colors of the balls could smoothly transition from dull to bright and back while rotating around, and that does look quite pleasing. However, that does mean that the balls are the same color when equidistant. When we are in an aligned view we really don't want that. Instead we want to heavily favor the positive direction. Hence the need for them to snap as they approach and leave alignment.

To evaluate this requires more than just recoloring a single screenshot …

You're right, we need a prototype to fine-tune the details.
Personally, however, I believe that you only construct problems that aren't a problem.

In D3936#89310, @Martin Capitanio (capnm) wrote:

You're right, we need a prototype to fine-tune the details.

You just need to apply my patch, use the widget, and compare it against current behavior.

Personally, however, I believe that you only construct problems that aren't a problem.

If you really think the current behavior is best, then I would ask you to go to the following page
and follow it along. You will see the wrong axis displayed, the wrong direction displayed at times,
an inability to move a negative axis to the front, and two rotation scenarios that are opposite on
one axis but drawn identically,

https://blenderartists.org/t/navigate-gizmo-doesnt-really-work/1133584

Checked this patch and think it's not an improvement.

• Current XYZ axis is visually easy to read at a glance.
• Emphasizing the negative axis makes the 3 positive axes less prominent (even though the positive lines remain).
• Showing the negative sign isn't all that helpful since its implicit when we always show the positive.
• the negative sign isn't something you can easily read out of the corner of you're eye, remember this is currently an interactive replacement for the regular XYZ axis.
• Find flickering during navigation annoying.

Originally the view navigation gizmo always had a visible circle (now only shown on hover),

this had the advantage of making axes pointing backwards slightly faded.

Suggest we tint/fade the colors, so its clear when axes point backwards.

Oh well, I tried...

The proposed changes will not address any of the problems shown here:

https://blenderartists.org/t/navigate-gizmo-doesnt-really-work/1133584

This design, always showing the positive ends larger and brighter, will remain difficult to read. This is because it appears to be in perspective in some directions, but is actually not so in most. So in the following image if you can guess the orientation in some views, you are necessarily fooled in others. LOL.

Please let me explain some of these these issues as simply as I can, because these are not just visual problems but important usability issues. It isn't just that the gizmo looks confusing (and it does most times) but it also does not work correctly.

Load the default scene. Grab the bright positive "Y" ball (currently at the right) and drag it toward you. You will see that the big bright positive ball is still displayed that way when facing toward you. Just as you'd expect.

Press Numpad-1 for front view. Notice that the middle "Y" is big and bright, which should be indicating the positive "Y" is facing toward you, as you found earlier. It is NOT, it just looks like it is. When in front view it is negative Y that is toward you.

While in front view, use your mouse and drag the bright "Y" ball in the middle. Drag a bit, side to side. What is happening? Did you notice that you are not dragging the big positive bright "Y" at all? That it was moving in the opposite direction of your mouse? You were actually dragging the dull smaller ball which appears to be in back but is actually invisibly in front! So you think you are dragging positive Y when that is actually impossible to do, so instead you are dragging the negative side.

Now press ctrl-numpad-1 to go to back view. There is a smaller, faded "Y" now in the center, so it is different from front view. Click on that "Y" and drag it a bit. Now will notice that you are actually dragging the positive ball, not the negative one. Try to put it back to the middle. Notice that the ball is big and bright in the middle now despite still being in back view. That is far from correct. We have now seen the big and bright "Y" in the middle when in front view and in back view.

The above are consequences of the design choice of only labeling the positive axes and making those bigger and brighter. It not only means that we have lost perspective cues used to guess the orientation. It also means that when axis balls are overlapping there will be oddness. The only choices with this design is for the unlabeled negative ball to occlude the labeled positive one, which would be confusing. Or you have to make the positive ball always display on top, even when it is behind, which causes the issues above.

Right, drawing negative axis over the top of positive wasn't working well (when nearly aligned), committed fix for this rB477407bd3b02ceb1c08322724a7cb2b5d369a268

We could still add a way to show which axis is in-front when they're not overlapping.

Don't think this is as confusing as you make out in your last statement.

The positive axes still have axis lines, users are aware these represent XYZ and are not reading these characters for the first time.

In D3936#89341, @Campbell Barton (campbellbarton) wrote:

Don't think this is as confusing as you make out in your last statement.

That was less about being confusing and more about a choice in this that is fundamental. As soon as you add balls to the end of axes we have the chance of them overlapping. With that there are really only two choices:

A - Favor (visually and for selectability) the one that is closest. This involves the least compromises because that is how real objects work, and because the close part is more important to the user.

B - Favor one end of the axis over the other, so positive over negative. This has the one advantage of being able to label just one of the two ends, but otherwise requires compromises for how it looks and how it works

Your new patch moves one issue from B to A, so it definitely helps. Don't get me wrong it helps.

But many B>A compromises remain. One new one is being okay with occlusion of unlabeled negative axes over positive axes. So like this:

It also means that in a negatively aligned view (like front view), the very moment you start moving the middle axis ball it immediately occludes that label. So you get a "pop" from trying to move a big bright "Y" to actually moving an unlabeled dull ball instead. But still better than before.

We of course still have visual problems with the differing size balls since they give a false depth cue half the time. But I don't want to keep beating that dead horse. LOL

On another note though, when having a perfectly aligned axis I think we have the center colors incorrect. What I mean is that when dragging manually, when the positive ball is in front then you have a bright ball there. When the negative side is in front you have that smaller duller ball. That is fine. But when in an aligned view we are showing negative brighter and positive duller. I think those are just swapped.

In the image below, top row shows positive X almost aligned, then perfectly aligned at right. bottom image shows negative X almost aligned, then perfectly aligned.

In D3936#89361, @Harley Acheson (harley) wrote:

On another note though, when having a perfectly aligned axis I think we have the center colors incorrect. What I mean is that when dragging manually, when the positive ball is in front then you have a bright ball there. When the negative side is in front you have that smaller duller ball. That is fine. But when in an aligned view we are showing negative brighter and positive duller. I think those are just swapped.

In the image below, top row shows positive X almost aligned, then perfectly aligned at right. bottom image shows negative X almost aligned, then perfectly aligned.

Good point, for interactivity it's nice to click and move to the opposite axis - but for display it's no good. Committed rB28e7c94de26a4706af16d6f2893917ca910a27ce

In D3936#89341, @Campbell Barton (campbellbarton) wrote:

...but for display it's no good. Committed rB28e7c94de26a4706af16d6f2893917ca910a27ce

Thanks Campbell!

I promise to leave this subject at least until a while after we come out of beta.

But I will add notes to a design doc if I notice one.

Cheers, Harley

After talking with @William Reynish (billreynish) we agreed using color fading to represent front/back was best. Committed rB3ecc79fa1aec0e8494369cae0e27549702f19dee

(occlusion issues remain, but think this wont be handled before the beta)