Color gradient curve

[RobWalt]

Objective

• Currently we have the ColorRange trait to interpolate linearly between two colors
• It would be cool to have:
  1. linear interpolation between n colors where n >= 1
  2. other kinds of interpolation

Solution

1. Implement ColorGradient which takes n >= 1 colors and linearly interpolates between consecutive pairs of them
2. Implement Curve intergration for this ColorGradient which yields a curve struct. After that we can apply all of the cool curve adaptors like .reparametrize() and .map() to the gradient

Testing

• Added doc tests
• Added tests

Showcase

// let gradient = ColorGradient::new(vec![]).unwrap(); // panic! 💥
let gradient = ColorGradient::new([basic::RED, basic::LIME, basic::BLUE]).expect("non-empty");
let curve = gradient.to_curve();
let brighter_curve = curve.map(|c| c.mix(&basic::WHITE, 0.5));

---

Kind of related to #14971 (comment)

[mweatherley]

At a high level, I feel like the interplay between Curve and ColorRange needs a bit of thought (in terms of how exactly we want to work with gradients long-term).

Separately, it seems to me like all of the concrete curvy stuff here is essentially reinventing the logic in curve::cores::EvenCore/SampleCurve.

Maybe the right thing to do would be to use the EvenCore technology in helping define the ColorRanges for these kinds of transitions and separately to have a curve constructor for any ColorRange that spits out a Curve over the unit interval.

Having both ColorRange and Curve feels a bit weird, but I'm not color-y enough to make any pronouncements about whether ColorRange ought to be deprecated or something, so I'll leave that to other people.

[bushrat011899]

I like this feature, but there are some changes I'd like made around trait implementations. I can't comment on interoperability with the Curve side of Bevy as I'm not familiar with that yet.

[RobWalt]

@mweatherley @bushrat011899

I took another try to implement it. Now it's backed by a SampleCurve which simplifies it quiet a bit overall. However, unfortunately, because types, we can't get a constructor with a default mix function. Hence the current implementation also needs the user to specify how to mix 2 mixables. This is a bit unfortunate because it allows misuse of the API if the passed mix function doesn't behave like T::mix. Not sure how to resolve it in a better way :/

[bushrat011899]

This is a much better attempt, thank you for taking our feedback on board and not giving up! I have made some suggestions which should resolve your type parameter issue and make the API much cleaner to work with. I've tested this on my own machine so it should work straight away.

I also experimented with adding a FromIterator implementation, but this cannot be done due to the fallibility of ColorCurve::new, we'll have to wait for TryFromIterator to be stabilised.

Excellent work!

[RobWalt]

@bushrat011899 Thanks for guiding me! I almost already had this at some point in time. The deal breaker for me was the

        let mix: fn(&T, &T, f32) -> T = <T as Mix>::mix;

I guess I gave up too early 😅

Anyways: Looks sooooo much cleaner now! Thanks again!

[bushrat011899]

Excellent work, glad I could help!

[mweatherley]

@bushrat011899 Thanks for guiding me! I almost already had this at some point in time. The deal breaker for me was the

        let mix: fn(&T, &T, f32) -> T = <T as Mix>::mix;

I guess I gave up too early 😅

Anyways: Looks sooooo much cleaner now! Thanks again!

Another approach, if you prefer to avoid function pointers, would be to just use EvenCore directly; the Curve library itself ran into the same issue that you encountered, which is why SampleAutoCurve exists in addition to SampleCurve.

[RobWalt]

@bushrat011899 Thanks for guiding me! I almost already had this at some point in time. The deal breaker for me was the

        let mix: fn(&T, &T, f32) -> T = <T as Mix>::mix;

I guess I gave up too early 😅
Anyways: Looks sooooo much cleaner now! Thanks again!

Another approach, if you prefer to avoid function pointers, would be to just use EvenCore directly; the Curve library itself ran into the same issue that you encountered, which is why SampleAutoCurve exists in addition to SampleCurve.

That's even better and also solves the serde flaw!

[alice-i-cecile]

Useful, and a straightforward implementation. Nice work!