An another approach to D3936
Change opacity to make it clearer which axis points forward or backward
(also stay consistent in the front/side/... view)
In my opinion it looks much clearer and more beautiful ;-)
It does not fix every conceivable problem, but I think it's a good compromise.
@Campbell Barton (campbellbarton) Suggest we tint/fade the colors, so its clear when axes point backwards.
Yes, I think maybe a fade implementation would be better.
Would prefer this blend tint instead of using low-alpha since it mixes up negative axis with axis behind the view. (alpha looks a bit strange in Y axis - second last example).
Also not sure why change is needed for this line: if ((axis_align == axis) && (gz->matrix_offset[axis][2] > 0.0f) == is_pos) {
Since this is in Differential already, not sure if we need this task open as well (discussion could continue there?)
Anyways, will leave open for now...
Anyways, will leave open for now...
Thanks, I still don't understand how this CMS works ;)
Would prefer this blend tint instead of using low-alpha since it mixes up negative axis with axis behind the view. (alpha looks a bit strange in Y axis - second last example).
D3941 rebased to after your commit now it looks perfect:
Also not sure why change is needed for this line: if ((axis_align == axis) && (gz->matrix_offset[axis][2] > 0.0f) == is_pos) {
I just tweaked that to get the desired behavior—highlight the ball if the axis points to your nose. With
diff --git a/source/blender/editors/space_view3d/view3d_gizmo_navigate_type.c b/source/blender/editors/space_view3d/view3d_gizmo_navigate_type.c index f594df858b4..0086b49d4c0 100644 --- a/source/blender/editors/space_view3d/view3d_gizmo_navigate_type.c +++ b/source/blender/editors/space_view3d/view3d_gizmo_navigate_type.c @@ -286,9 +286,11 @@ static void axis_geom_draw( bool ok = true; - /* skip view align axis */ + /* skip view align axis if not positive */ + printf("XXX axis %d, offset: %.2f, positive: %d\n", axis, gz->matrix_offset[axis][2], is_pos); if ((axis_align == axis) && (gz->matrix_offset[axis][2] < 0.0f) && !is_pos) { ok = false; + printf("XXX skip axis %d\n", axis); } if (ok) { /* Check aligned, since the front axis won't display in this case,
for example, I get for y back
XXX axis 1, offset: -1.00, positive: 1 XXX axis 2, offset: -0.00, positive: 1 XXX axis 0, offset: -0.00, positive: 0 XXX axis 0, offset: -0.00, positive: 1 XXX axis 2, offset: -0.00, positive: 0 XXX axis 1, offset: -1.00, positive: 0 XXX skip axis 1
Do you have a better idea?
@Martin Capitanio (capnm) I've since committed some improvements to the gizmo, but there is still the issue of it being non-obvious which axes are in front. Did you want to continue looking into this?
@Campbell Barton (campbellbarton) That's hard to understand and doesn't work as intended for the first paragraph:
+ /* Flip the faded state when axis aligned, since we're hiding the front-mode axis + * otherwise we see the color for the back-most axis, which is useful for + * click-to-rotate 180d but not useful to visualize. + * + * Use depth bias so axis-aligned views show the positive axis as being in-front. + * This is a detail so primary axes show as dominant. + */ + const bool is_pos_color = ( + ((axis_order[axis_index].depth > (axis_depth_bias * (is_pos ? -1 : 1))) == (axis_align != axis))); +
I'd leave that here as in the previous commit:
@@ -341,11 +353,6 @@ static void axis_geom_draw(
/* Axis Ball. */
{
- /* Flip the faded state when axis aligned, since we're hiding the front-mode axis
- * otherwise we see the color for the back-most axis, which is useful for
- * click-to-rotate 180d but not useful to visualize. */
- const bool is_pos_color = is_pos == (axis_align != axis);Otherwise, I am absolutely satisfied. Thanks!
@Martin Capitanio (capnm) testing here, axes which are in-front are displayed brighter - which is the intent.
testing here, axes which are in-front are displayed brighter - which is the intent.
I mean the aligned axes (Y in the example 1,2) that worked on the previous commit
28e7c94de26a4706af16d6f2893917ca910a27ce
now they are always bright.
@Martin Capitanio (capnm) made a tweak to address this: rB8c7727946c5bbf5119cd82c3ae08dcb65ab8076e (now both front/back always draw)
@Campbell Barton (campbellbarton) from a graphic-design point of view and the front/back consistency it doesn't look very good. My (female) co-worker and I still prefer variant 1 :
I.e.: