Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix path control points losing curve type on save/reload or undo #29446

Merged
merged 4 commits into from
Sep 2, 2024
Merged
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
47 changes: 47 additions & 0 deletions osu.Game.Rulesets.Osu.Tests/Editor/TestSceneSliderChangeStates.cs
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
// Copyright (c) ppy Pty Ltd <[email protected]>. Licensed under the MIT Licence.
// See the LICENCE file in the repository root for full licence text.

using System.Linq;
using NUnit.Framework;
using osu.Game.Beatmaps;
using osu.Game.Rulesets.Objects;
using osu.Game.Rulesets.Objects.Types;
using osu.Game.Rulesets.Osu.Objects;
using osu.Game.Tests.Beatmaps;
using osuTK;

namespace osu.Game.Rulesets.Osu.Tests.Editor
{
public partial class TestSceneSliderChangeStates : TestSceneOsuEditor
{
protected override IBeatmap CreateBeatmap(RulesetInfo ruleset) => new TestBeatmap(ruleset, false);

[TestCase(SplineType.Catmull)]
[TestCase(SplineType.BSpline)]
[TestCase(SplineType.Linear)]
[TestCase(SplineType.PerfectCurve)]
public void TestSliderRetainsCurveTypes(SplineType splineType)
{
Slider? slider = null;
PathType pathType = new PathType(splineType);

AddStep("add slider", () => EditorBeatmap.Add(slider = new Slider
{
StartTime = 500,
Path = new SliderPath(new[]
{
new PathControlPoint(Vector2.Zero, pathType),
new PathControlPoint(new Vector2(200, 0), pathType),
})
}));
AddAssert("slider has correct spline type", () => ((Slider)EditorBeatmap.HitObjects[0]).Path.ControlPoints.All(p => p.Type == pathType));
AddStep("remove object", () => EditorBeatmap.Remove(slider));
AddAssert("slider removed", () => EditorBeatmap.HitObjects.Count == 0);
addUndoSteps();
AddAssert("slider not removed", () => EditorBeatmap.HitObjects.Count == 1);
AddAssert("slider has correct spline type", () => ((Slider)EditorBeatmap.HitObjects[0]).Path.ControlPoints.All(p => p.Type == pathType));
}

private void addUndoSteps() => AddStep("undo", () => Editor.Undo());
}
}
2 changes: 1 addition & 1 deletion osu.Game/Beatmaps/Formats/LegacyBeatmapEncoder.cs
Original file line number Diff line number Diff line change
Expand Up @@ -450,7 +450,7 @@ private void addPathData(TextWriter writer, IHasPath pathData, Vector2 position)
// Explicit segments have a new format in which the type is injected into the middle of the control point string.
// To preserve compatibility with osu-stable as much as possible, explicit segments with the same type are converted to use implicit segments by duplicating the control point.
// One exception are consecutive perfect curves, which aren't supported in osu!stable and can lead to decoding issues if encoded as implicit segments
bool needsExplicitSegment = point.Type != lastType || point.Type == PathType.PERFECT_CURVE;
bool needsExplicitSegment = point.Type != lastType || point.Type == PathType.PERFECT_CURVE || i == pathData.Path.ControlPoints.Count - 1;

// Another exception to this is when the last two control points of the last segment were duplicated. This is not a scenario supported by osu!stable.
// Lazer does not add implicit segments for the last two control points of _any_ explicit segment, so an explicit segment is forced in order to maintain consistency with the decoder.
Expand Down
2 changes: 1 addition & 1 deletion osu.Game/Rulesets/Objects/Legacy/ConvertHitObjectParser.cs
Original file line number Diff line number Diff line change
Expand Up @@ -347,7 +347,7 @@ private IEnumerable<ArraySegment<PathControlPoint>> convertPoints(PathType type,
vertices[i] = new PathControlPoint { Position = points[i] };

// Edge-case rules (to match stable).
if (type == PathType.PERFECT_CURVE)
if (type == PathType.PERFECT_CURVE && FormatVersion < LegacyBeatmapEncoder.FIRST_LAZER_VERSION)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I get what the other change is going for, but what is this one doing?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This prevents perfect curve type anchors from losing curve type on undo/redo/reload if the segment has <3 anchors or they are colinear. We already have editor features that prevent you from creating invalid sliders, so its unnecessary to do this in parsing.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We already have editor features that prevent you from creating invalid sliders, so its unnecessary to do this in parsing.

I dunno if I agree with that, people still manually edit beatmaps and will continue to do so regardless of if we want that or not. We need protections against such stuff on decode.

The collinearity check getting skipped is especially alarming to me since its purpose is to prevent circular approximations with arbitrarily large radii, which is generally numerically unstable and can lead to various strange things happening.

I'd want to know which scenarios this "breaks" specifically to make a judgement call on whether this removal is worth the potential tradeoffs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are already protections against colinearity in perfect curve sliders built into the path calculation. Its already trivial to make a circular slider with arbitrarily large radii inside the editor, so parsing doesn't seem like the right place for those protections anyways.

// `PathApproximator` will already internally revert to B-spline if the arc isn't valid.
if (!circularArcProperties.IsValid)
break;
// taken from https://github.com/ppy/osu-framework/blob/1201e641699a1d50d2f6f9295192dad6263d5820/osu.Framework/Utils/PathApproximator.cs#L181-L186
int subPoints = (2f * circularArcProperties.Radius <= 0.1f) ? 2 : Math.Max(2, (int)Math.Ceiling(circularArcProperties.ThetaRange / (2.0 * Math.Acos(1f - (0.1f / circularArcProperties.Radius)))));
// 1000 subpoints requires an arc length of at least ~120 thousand to occur
// See here for calculations https://www.desmos.com/calculator/umj6jvmcz7
if (subPoints >= 1000)
break;

The only thing that makes sense to convert in parsing is perfect curve segments with >3 anchors. These are invalid and impossible to make inside the editor.

osu!_bdyevbDALw

{
int endPointLength = endPoint == null ? 0 : 1;

Expand Down
Loading