Generalize curve support.

[brandon-reinhart]

Instead of a custom gradient, systems should accept some kind of generalized curve. This is also a bevy issue, in that some bevy modules will want to be able to be parameterized over generalized curves and there needs to be agreement across crates about what curves to use.

Why is this useful?

1. writing a bunch of your own curve types will mean fewer supported types
2. also its annoying to do!
3. if we're going to write curves, we should all share the results
4. you'll often want more curves than just linear interp between keyframes. ex: non-linear ramping over a color space

[djeedai]

I'm considering adding general texture-based gradient but that'd be after the #109 refactor.

[brandon-reinhart]

I'm considering adding general texture-based gradient but that'd be after the #109 refactor.

Yeah that would solve it and basically outsource the problem to whatever texture gen process people wanted. Nice!

[djeedai]

The outsourcing to drawing softwares is not really the main reason; it's true if we don't provide any conversion from analytical gradient to texture, but false otherwise. The real reason is that the more complex the gradient, the less attractive the analytical solution is compared to the texture sampling one. With a few key points and linear interpolation, that's just a few instructions in the shader, but as things are getting more complex with more key points and nonlinear interpolation, the cost of sampling an analytical gradient increases, and outweighs a single texture sampling. Storage is also of concern, although texture-based gradients are going to use more GPU memory most of the time unless the gradient is incredibly complex. But even then, those textures are small by today's GPU standards, so the performance benefit is the core reason.