Suggestions

[Pjort]

Hi, I tested this thing out, and it works really well. But I have some suggestions, and some things I quickly changed and it felt much better.

I am guessing you are mostly testing everything while sitting, since if you stand up all the cubes are spawning really low. So I added 0.5 to the y position on the spawn and it works wonders. So maybe some sort of offset slider on the main screen?

Then another thing that was easy fix was the colision with the floor and the light sabers, when standing and in rest position the sabers go into the ground and rumbles. So I just removed the colision on the floor and that fixed that.

I also managed to import some songs from BeatSaver so I could test with some more action, I normally play on hard in beatsaber. And I found when you cut the cubes in really fast sucession, not only did they pile up infront of you before despawning, but the cutting was laggin the game, making it unplayable. When I commented the cutting part out there was no performance issues. I would suggest addeding like a little extra rumble on the cutting, just a tiny bit more for the hebtic feedback that you cut the cube, and just despawn the cube without animation and then just shoot out some particles in the color of the cube.

[NeoSpark314]

Thanks for the feedback and suggestions! Adding a calibration to adjust for different body sizes is a good idea; several VR games have such a system and a simple button in the main menu "calibrate height" is probably enough. The performance issue with many cubes is something to be investigated; maybe we need to add a system that avoids this by making them despawn faster when many cubes appear; and the cutting computation is quite expensive; so maybe we would need to optimize this too at some point.

[eternaldensity]

Yeah I added an offset too, and considered but never got around to making a slider for it. And good call on the floor vibration, that bugged me too.

I never noticed the cubes piling up being a problem, though sometimes when I cut them the pieces get in the way. Shame, the cutting animation is a good bit of work and I hope it's possible to keep it. But yeah, a bit more rumble would be nice, as I do tend to feel there's not quite enough feedback to really feel like I've cut it. (I did have a funny idea for an alternate mode where instead of a cutting saber you've got a bat so you just hit the blocks and knock them away (they despawn after a few moments). I call it Yeet Mode :P)

The problem I did have is the way you calculate what the block speed should be. On some maps it comes out much slower in Beat Saber so the notes are far too close together. On other maps it's way too fast which wouldn't be so much of a problem except that the notes don't get into position quickly enough. That means they're still spinning and swooping right until they reach me or even perhaps past that, making them pretty impossible to hit.

And then there's the note hit sound which sounds like I'm making popcorn. The sound in Beat Saber is a bit more subtle and swishy, probably so it doesn't sound so jarringly off tempo when you don't hit a note at the exact right moment.

Some time I ought to try implementing song info (so you can see the number of notes and bpm) and score saving (I guess to a dat file in the Beat Saber folder. I could put it in the user:// folder but then people can't back it up. Well probably want multiple player name support too.

Oh I'd like to do something about the 'missing one note sets your multiplier all the way back to zero' feature, cos at it is the score % difference between a full combo and missing one note in the middle must be immense, making it far more brutal in scoring that Beat Saber.

[Firepal]

But yeah, a bit more rumble would be nice, as I do tend to feel there's not quite enough feedback to really feel like I've cut it.

This could be done by, instead of rumbling when the saber is intersecting a beat, rumbling once for a fixed period of time (0.3 seconds for example) when the saber has cut a beat.

And then there's the note hit sound which sounds like I'm making popcorn. The sound in Beat Saber is a bit more subtle and swishy, probably so it doesn't sound so jarringly off tempo when you don't hit a note at the exact right moment.

I believe Beat Saber plays the cut sound in sequence with the beats (actually slightly in advance because the swish fades in), and missing a beat "mutes" it until a beat is cut again. Beep Saber plays the cut sound when Godot's physics engine has realised you have. Their appoach is probably more stable... (yes we really need a new cut sound)

Also, just for funsies, I'd like to see burn marks on the floor like in the PCVR Beat Saber, which I will gladly implement once I can get to my computer =>

[Firepal]

I also thought about this: is controller position queried at idle time or physics time? Because I feel like I'm missing beats I shouldn't be, from moving the controller too fast. (We could grow the saber collider (or its margin) by the controller's velocity to prevent missing beats due to going too fast?)

[NeoSpark314]

I also thought about this: is controller position queried at idle time or physics time?

I think position is queried in the physics loop; but this is probably not enough for quick movements since the collision object is just a thin cylinder at the moment. I do not know what a good practice is to make this more robust; one first idea would be to keep the old saber position and create a quad between the old and new saber position and use this to test for collisions with the cube...

Burn marks would be cool (but probably need to be optional or very performant to run on quest 1)

For the cut sound: yes :-) maybe we can even make it an option and provide multiple different. Playing the cut sound always with the beat and only muting it when not cutting sounds like a good solution.

[Firepal]

I do not know what a good practice is to make this more robust; one first idea would be to keep the old saber position and create a quad between the old and new saber position and use this to test for collisions with the cube...

That's sort of what I was envisioning, and looks like a good first thing to try for this problem.

Burn marks would be cool (but probably need to be optional or very performant to run on quest 1)

I'm envisioning something that doesn't seem too perf-heavy on paper (Inside of a 2D Viewport, put a single "burner quad" that is accumulated over several frames using the "Keep" setting of the WorldEnvironment Background. That quad would appear and move to where the saber intersected the floor)

[leandrodreamer]

I'm envisioning something that doesn't seem too perf-heavy on paper (Inside of a 2D Viewport, put a single "burner quad" that is accumulated over several frames using the "Keep" setting of the WorldEnvironment Background. That quad would appear and move to where the saber intersected the floor)

i tried and may work ok

https://user-images.githubusercontent.com/26260718/112684901-c095e700-8e41-11eb-9105-8bb97a5d0db3.mp4

just need better in-between that the one that i did and make it more burn like

edit: there is some ghosting on the image that don't disappear, maybe will be better to use 2d particles or something like that

[Firepal]

@leandrodreamer You should make a PR. That looks really great!

It's basically what I was gonna do, but I got busy improving the saber's shader and adding a glow to it (which I will probably make a PR of, once I clean up the mess I made changing the saber's capsule blade to a cylinder)

EDIT: The ghost is fine. It's probably really easy to fix and it fits the burning aspect

[leandrodreamer]

improved and done https://github.com/NeoSpark314/BeepSaber/pull/10

[eternaldensity]

I believe Beat Saber plays the cut sound in sequence with the beats (actually slightly in advance because the swish fades in), and missing a beat "mutes" it until a beat is cut again. Beep Saber plays the cut sound when Godot's physics engine has realised you have. Their appoach is probably more stable... (yes we really need a new cut sound)

I figured it had to be something like that. Basically they 'cheat' the timing to make it feel more natural to players, which is why BeepSaber feels a bit less comfortable to play. I presume BeepSaber also doesn't have the larger bounding boxes BeatSaber uses normally (though they've now added a modifier to disable that) which is why it feels like I miss a lot more on BeepSaber.

[Firepal]

I presume BeepSaber also doesn't have the larger bounding boxes BeatSaber uses normally

~~Correct! They're tightly bound to the box visuals currently. #13 adds the extra large bounding boxes, although IMO the sabers should be shorter to compensate like in the actual Beat Saber. How much shorter is the question, currently the cutting area of the saber is 1.35m long, so maybe just 1m or 800cm~~

[Firepal]

I guess the small hitbox is what actually made me miss cubes in BeepSaber.

Also something to note is that framerate on Quest 2 is pretty meh. I know BeepSaber runs at 72fps but it can be notably stuttery compared to the simpler GodotOQToolkit version. I think the event_driver may be a possible culprit as it creates at least 54 to 63 drawcalls despite cleanly using Mesh resources. GPU instancing could fix this as most of the objects are the same mesh duplicated but as far as I know Godot has zero support for this

[Pjort]

3 years old issue, I am closing it.