Refactor smoothing to be less "bad"

[Zee2]

Describe the problem

The current smoothing system (in both MRTK2 and 3) is highly questionable. The units are... arbitrary, and it's really hard to author because you have to set, like, 0.000001 vs 0.0001.... it's just, strange. It's a legacy hold-over, and folks have historically been a bit dissatisfied with how "floaty" it is.

Describe the solution you'd like

An easy-to-author, easy-to-understand smoothing API. Ideally, it will default to a less floaty "feel", like Stereokit's default manipulation behavior:

movement.position    = vec3_lerp (movement.position,    dest_pos, 0.6f);
movement.orientation = quat_slerp(movement.orientation, start_handle_rot[i] * dest_rot, 0.4f);

(Edit for above: this does NOT endorse or recommend hardcoded or framerate-dependent lerping... it's just an anecdote that SK uses much snappier smoothing than we do, and there's positive customer sentiment!)

Additional context

@maluoi can elaborate on the opinions folks have had about MRTK's manipulation smoothing vs other solutions 😁

[keveleigh]

Are those lerp values hardcoded (0.6f and 0.4f)? Because if so, it sounds like that code falls into the traps MRTK's smoothing is intended to avoid.

Mainly that you'll never actually reach dest_pos in a lerp like that. Even as you're updating movement.position, you'll only ever get some miniscule distance away but never really reach it (I guess until you run out of float precision? But that feels kinda...bad to depend on a rounding error instead of actually reaching your goal).

It also doesn't take frame rate into account, which I think is needed for a good smoothing experience.

[keveleigh]

Not sure if there's a Quaternion version (and I've never actually used this...), but I just noticed an interesting Vector3 method: https://docs.unity3d.com/ScriptReference/Vector3.SmoothDamp.html

Impl: https://github.com/Unity-Technologies/UnityCsReference/blob/dcf29f6d96a9708d7a7350f92772bb75ca3befbf/Runtime/Export/Math/Vector3.cs#L97

[Zee2]

@keveleigh definitely wasn't encouraging us to hard-code magic smoothing numbers in :D Just a point of reference that SK uses relatively snappy, albeit framerate-dependent, lerping, and general customer sentiment is actually quite positive (Nick has told me in a few different occasions that one of the first reactions folks have to Stereokit is that the manipulations feel much snappier and more precise due to the reduced smoothing.)

I expect our result to still be framerate independent, but I hope we default to a less floaty smoothness, as well as having more reasonable units (rather than having to adjust the smoothing about to like, 0.000001 for a good feel...)

[Zee2]

Also @keveleigh pretty sure our current smoothing will just asymptotically approach the target too, lol.

[keveleigh]

Also @keveleigh pretty sure our current smoothing will just asymptotically approach the target too, lol.

Oof...yeah, you're right haha. I guess it's been a while since I've looked critically at this code! 😅

[maluoi]

SK's implementation is not frame dependent mostly on purpose. 0.4 & 0.6 are huge values for a lerp, and they converge extremely quickly to the destination this way, regardless of framerate! A clamped time lerp could be fine too, but the correct lerp value is much less clear in this case. The main objective is not to noticeably smooth the interaction, but to keep up with the input device as much as possible (snappy!), and reduce jitter from tracking error and unsteady hands.

As to whether or not it converges to the exact location, I haven't really checked! I suspect it does due to floating point precision, but this smoothing is specifically for hand-driven interactions, so it doesn't matter at all! A human's hand is infinitely less precise than the specific location of the hand :)