Improve incremental B-spline builder via stochastic optimisation

[OliBomby]

Summary

This PR proposes an improvement to IncrementalBSplineBuilder to make it optimize control point placement to more closely match the input path. It utilizes PiecewiseLinearToBSpline to iteratively optimize the control point placement while drawing the path, and when a segment is finished it will optimize the segment as a whole a bit further.
Furthermore IncrementalBSplineBuilder.ControlPoints is now a IReadOnlyList<List<Vector2>> so each segment is explicitly provided.

• IncrementalBSplineBuilder.ControlPoints is now a IReadOnlyList<List<Vector2>>.
• Added IncrementalBSplineBuilder.Finish() which should be called when you finish drawing.
• Updated recommended parameters in TestSceneInteractivePathDrawing.
• Added learnableMask to PiecewiseLinearToBSpline to control which control points to optimize.

Requirements

• Add method to convert piecewise linear curves to spline control points #6056

Considerations

• IncrementalBSplineBuilder.ControlPoints could potentially be modified from the outside which would disrupt the builder as it updates from the previous control points instead of completely remaking the control points every time. I don't know if this should be considered as an issue.
• Slider building could be further improved by adding circular arc type sections. These are generally better looking and easier to edit, also people can't draw perfect circles by hand. This could be achieved by detecting segments which could be reasonably approximated with a circular arc and replacing those segments, though this is probably outside the scope of a B-Spline builder.

osu.Framework.Tests_Noks6XgEXm.mp4

[peppy]

Okay this looks pretty amazing.

[bdach]

I've attempted to resolve merge conflicts. @OliBomby please check if I did it correctly whenever you have the time.

Sometimes if I try really hard I seem to be able to break this:

The approximation straight up stops following the path for a bit there. I'm not exactly sure why this is though, it's exceedingly difficult to reproduce, and only happens if I try really dumb stuff, so not sure how much of a blocker this is.

Will do a 15-minute pass over the source now, but I don't expect to understand much of this, especially so that this is to be expedited.

[bdach]

What's this doing? I'd hope initializeSegment() would already enforce this?

[OliBomby]

initializeSegment() does not already enforce this because it does not update the lastSegment, it only returns what would be the initial control points for this segment. lastSegment is not equal to the initial control points because it already has been optimized for several iterations in the previous frames.

This part of the code is responsible for updating the end-points of lastSegment to be equal to cps or adding the end-points if it does not already have them.

[bdach]

Where is the "have already been optimised enough" part done? I only see the end 2 * degree control points being fixed in place.

[OliBomby]

Perhaps this comment is misleading. I deemed control points which are 2 * degree away from the end as "optimized enough" because they would have barely any impact on the end-point which is the part that has to be updated. There is no actual check to see if they are "optimized enough" as in close to optimal. I chose the 2 * degree because that seemed like the point where control points stopped moving around a whole lot. I'll change the comment to make this more clear.

btw, the end 2 * degree control points are the only ones not fixed in place. 0 in this mask means that they are fixed.

[bdach]

What does controlPointsPartiallyInvalid mean? And why is it true when done drawing?

[OliBomby]

controlPointsPartiallyInvalid means that controlPoints is valid for the current input path and settings minus some part of the path which was added onto the end. It will then re-use the previous controlPoints to prevent doing double work on the segments it has already computed control points for, basically only updating the last segment of the controlPoints.

I set it to true when done drawing because we want to optimize the control points a bit further once we know this is the entire input path. This leads to better results.

[bdach]

I've renamed this flag and a few other things in e7c7397 to hopefully aid in understanding. Please check that you're ok with this.

[OliBomby]

I think these new names kinda misrepresent the meaning.

The method regenerateLastApproximatedSegment doesn't regenerate the last segment, because it re-uses the existing control points and updates their position or adds/removes some. Also the effect is not limited to just the last segment. If enough path has been added it could be adding several segments to the path. Saying it 'updates' the control points would be more accurate there. Same thing for shouldOptimiseLastSegment.

[bdach]

Well what you had was pretty terrible readability-wise (regenerateApproximatedPathControlPoints vs updateApproximatedPathControlPoints - what is the difference there? what's the significance of "regenerate" vs "update"? the entirety of the context that the second method only touches the last part is lost).

I dunno. Maybe the new names aren't strictly correct but at least they attempt to explain themselves in some respect. If you can figure out an alternative that is both correct and descriptive then push at your leisure.

[OliBomby]

Sometimes if I try really hard I seem to be able to break this:

I think I found the cause for this issue. In extremely rare cases detectCorners can return less corners than it did on the previous frame. Another check stopped updating the last segment in case there is a mismatch in the corner count and the segment count, so the segment where this rare case would occur would stop updating entirely.

The fix is pretty simple so i'll fix that right away.

[bdach]

can't seem to break this any further so /shrug