Curve extrapolation for curves which can be extrapolated

[laundmo]

What problem does this solve or what need does it fill?

Currently, there are few ways to make a Curve trait implementor continue beyond its domain. This is especially apparent for SampleCurve/UnevenSampleCurve. For example, when using a simple lerp(a, b, t) to interpolate, theres no reason i couldn't extrapolate by providing a t > 1.0 or t < 0.0, and this can be very useful in some cases.

For example, this curve would translate something along a V shape:

UnevenSampleCurve::new(
  vec![
    (0.0, Vec2::new(1.0, 0.0)),
    (0.5, Vec2::new(0.0, 1.0)),
    (1.0, Vec2::new(1.0, 2.0))
  ],
  |a, b, t| a.lerp(*b, t)
)

Its perfectly valid to extrapolate this in both directions infiniteley (making a larger/infinite V shape, in this case) but i can't find a builtin way to encode this in the Curve itself. The domain is 0.0..=1.0 and i can't find a way to change that which leads to the behaviour i'm looking for.

What solution would you like?

I would like some way which allows me to get a infinite domain curve for all curves where extrapolation can make sense. Lerp is the most obvious extrapolate-able example, but bezier curves, for example, are also fine to extrapolate.

I think ideally this should be a wrapper struct, like the various ones returned by ChainExt methods. This would allow passing it to external code which calls .sample(t) more easily.

What alternative(s) have you considered?

• Curve::sample_unchecked explicitly documents i can't use it for this (quote: "extrapolation beyond a curves domain should not be relied upon"). If that documentation is changed, external code may need to be updated to use sample_unchecked to allow for infinite domain curves. Also, would make it harder to prevent extrapolation for curves which can't/shouldn't be extrapolated.

Additional context

A related feature to consider along with this is some way to cutoff and chain curves with infinite domains. Similar to CurveExt::chain, i would propose CurveExt::chain_atwith an extratargument which defines the cutoff point. This could be implemented by having a wrapper struct, similar to the one i've proposed above, which overrides their domain to end at a specific value (which would make the implementation ofchain_atsomething like this:RightCutoff::new(my_curve, t).chain(LeftCutoff(t, my_other_curve))`).

[mweatherley]

A few remarks:

• Technically, there is nothing that prevents you from using Curve::reparametrize to arbitrarily alter a curve's domain, although this is in a sense no different from relying upon sample_unchecked.
• Similarly, reparametrize can also be used to arbitrarily restrict the domain of a curve (e.g. to a bounded one from an unbounded one) for the sake of using methods that require bounded curves. I think that making this a more blessed procedure somehow would probably be a better path forward than introducing a lot of additional curve combinators.
• UnevenSampleCurve and its ilk are based on the constructs of curve::cores, which do infer some additional metadata as they perform interpolation (InterpolationDatum) which could be used for extrapolation in some contexts. At least, it would save you some work if you want to write extrapolating curves by hand (see e.g. uneven_interp). In general, that's the reason that I chose to expose these internals in the first place.
• The easing-compatible types (Ease) do support explicitly-extrapolating curves linking pairs of elements via interpolating_curve_unbounded, so perhaps this endeavor is another area where unifying some interpolation traits could be valuable.

In general, my opinion is that it might be hard to preserve usability while supporting a lot of extrapolation, which is why my general inclination has been toward making manual curve construction fairly tractable rather than trying to add a whole zoo of additional curves. On the other hand, I could imagine a future in which we have some kind of extension trait that expresses the ability of a curve to extrapolate itself in some sensible way to an arbitrary domain, but I would personally prefer to see a solid demonstrated need for it before moving forward with something of that nature. Then again, maybe just some ad-hoc methods would be fine.

Sorry for rambling!

[laundmo]

I honestly may just not have understood reparametrize, despite trying to grasp its docs repeatedly. I thought that would scale the curve, not basically extrapolate it.

I'm having a hard time expressing why i wanted this without going into lots of details, so maybe it is actually that rare, but at the same time i'm probably unreasonably convinced it coukd be very useful, like for example for making something keep moving beyind the end point if its speed is so high it would reasonably overshoot...

i'm approaching these tools probably created for animation and easings etc. from a very "i'm gonna make my entity directly controlled by a curve" mindset, which possibly not many people have.

I'll have to think about it for a bit, its late.