Plausible improvement to current behavior for trimming of a Catmull-Rom spline. Instead of simply setting the endpoint of the curve to the trimmed point it relaxes the neighboring point in the curve to avoid looping it as the curve is trim point approaches the control point (see behavior in the gif below).
**Problem description**
Trimming a Catmull-Rom spline without discretization or conversion to Bezier form is not really possible since the influence from neighboring control points to the trimmed segment is constant. Using the current behavior where endpoints has multiplicity of 2 the last segment starts to form a loop as the endpoint approaches the neighboring control point (see gif). This occur due to the segment approaching a point on the line defined by the two neighboring control points to the curve endpoint as the endpoint approaches it's neighbor. This point (or 'extrema') can be found by evaluating the spline segment at t = 1/3 (or 2/3 depending where the endpoint/multiplicity lies) as it is the point where the influence for the second neighbor reaches it's maxima.
**Solution**
The curve is 'relaxed' by moving the neighboring control point toward t = 1/3 (or 2/3) within the neighboring segment. This value is not strictly related to the maximum for the influence but is related to it. Once the trim point passes the endpoint the relaxed point is removed rather then the endpoint causing the curve the snap back.
**Relaxed Trim**
{F13572819}
Relaxed Trim, control points are visualized with a point cloud geometry.
**Current behavior**
{F13572821}
Current behavior, control points are visualized with a point cloud geometry.
**Limitations**
Animating the behavior causes the behavior to curve to snap back as the trim point passes over a control point (see gif), current behavior causes a similar behavior as the spline no longer bends toward it's extrema.
This is just a suggested improvement to current behavior based on my understanding of current desired behavior.
**Other plausible solutions**
Change the Catmull-Rom endpoint behavior to not be multiplicity of 2. Trimming Catmull-Rom splines would still be approximations but behavior could likely be improved further.
Conversion to Bezier form (https://link.springer.com/article/10.1007/s42979-021-00770-x). To my current understanding conversion is not preferred behavior due to compute cost/type change as discretization was not desired in D14481.
**Oddities**
Patch includes partial changes/corrections to IndexRangeCyclic.