Insufficient data for determining note slice position

[Protected]

Feature request

It doesn't seem like NoteCutObject contains sufficient information for determining the position of the slice on the sliced note. There are two key issues:

• cutDistanceToCenter always seems to return a positive (absolute) distance, from my experiments so far, and
• cutPoint seems to be absolute (or at least not relative to the center of the note).

So while we can calculate the angle of the cut and how offset it is from the center of the note, there is no way to tell if it's to the "left" or to the "right" of the center of the note. Other mod authors retrieve the position of the note in order to calculate the local position of the cutPoint, for example

https://github.com/m1el/BeatSaber-SliceVisualizer/blob/master/Core/NsvSlicedBlock.cs#L280

As long as the value of cutPoint is included unmodified, I propose adding a notePosition field to NoteCutObject when the note was not missed.

Alternatively the cutPoint could be transformed server-side (since we have no other use for the note position), and/or a boolean "cutLeftOfCenter" could be included, which would be enough.

Motivation

I want to draw the slice on the note!

[opl-]

From what I recall, and as long as nothing has changed since, the cutNormal property combined with cutDistanceToCenter is sufficient to determine where the plane of the cut is relative to the note's center.

[Protected]

I didn't have much more time today but there was a brief discussion on the subject in the discord; I'll look into it again ASAP.

[Protected]

I've been thinking the direction of the normal might match the direction of the offset. Hopefully I'll have time to run the tests tomorrow.

[Protected]

I've been looking at this for hours and ran many tests using VR, can't figure it out. Got the angle working, the offset not so much.

Here are two example notes from one of my tests - real data from the HTTP status mod. They're from the old Muse - Uprising map. Both are in the same line and layer and have the same direction. One of them was sliced down along the left side (left of center) and the other was sliced down along the right side.

https://gist.github.com/Protected/b2c8a8422f9cd86db5bf8874daa3e0b7

How would you tell that they were sliced down along different sides?

Here's my illustration from yesterday on Discord to demonstrate the two cuts with the same normal and distance to center:

https://cdn.discordapp.com/attachments/443146108420620318/893941603213901925/unknown.png

No one was able to provide a link to an existing solution that is correctly offsetting the cut plane without using the note position. Some developers simply do not offset the cut plane at all (they only use the angle and show every cut running through the center of the note).

Please, if you remember the procedure I'd appreciate an explanation. I'll share my code on github as soon as I have a decent working version (getting very close now).

[opl-]

The gist you sent indeed seems to not differ in any meaningful way. As I said before, I believe the cutNormal used to hint at the side on which the cut occurred, but I might be wrong here and I can't check my old data for that easily. Also, I just submitted a review of the PR.

[opl-]

As discussed in #78 and over Discord, the positions that are being sent in 1.18.0 (and certainly some versions before it) are next to useless, which likely happened due to the game changing over the years without anyone realizing. This has been fixed in 13a5f02 by transforming the noteCut.cutPoint, noteCut.cutNormal, and noteCut.saberDir vectors into note space before sending them out and documenting things accordingly.

While I don't believe anyone could've possibly made sensible use of this data on the current plugin version, feel free to contact me for help if your use case broke because of this change.