Gizmo gradient blending should be done in the color space provided, rather than linear RGB

[alice-i-cecile]

Bevy version

0.13.1

What you did

Called bevy_gizmo::gizmos::line_gradient or similar.

What went wrong

The colors appear to be blended in linear RGBA space: instead, these should be blended in the color space of the start and end color types (which should be forced to be the same).

Additional information

Found as part of #12056.

[viridia]

@alice-i-cecile This is kind of what I was aiming for with the various attempts at defining color gradients. You define a range by a start and end color, both of which have to be in the same color space - and then you can extract out a color from any point along that range, converted into linear rgba.

The 'Mix' trait is a trait bound for this: you can construct a range from any color type that implements Mix (which is all of them).

[alice-i-cecile]

Yep, that's exactly the work that I'm hoping to use here :)

[tim-blackbird]

I think this isn't feasible for gizmos. The interpolation is done on the vertex level on the GPU. It might be possible to make that work but I highly doubt it's worth the complexity/performance for what's supposed to be a debugging tool.

We should work this out whenever we add a dedicated line-renderer intended for visual effects, of course

[viridia]

That makes sense. I've done something similar: my gradient slider UiMaterial shader interpolates in Srgba, because it looks much better that way.

I can envision a future version of Gizmos which does the interpolation in oklab (which, by many accounts, produces the best looking gradients).

Maybe we need to consider a library of color conversion functions written for shader code?