Fix scroll speed compounding math

[alice-i-cecile]

Objective

As discussed in #20215 (comment) by @BigWingBeat, the way that we handle scrolling is subtly wrong.

Solution

• Shamelessly steal their code.
• Add a comment.

Testing

cargo run --example 3d_gizmos --features="free_cam"

[IQuick143]

Slightly off-topic but this seems equivalent to just:

Suggested change

	scroll += amount;
	let scroll = match accumulated_mouse_scroll.unit {
	MouseScrollUnit::Line => accumulated_mouse_scroll.delta.y,
	MouseScrollUnit::Pixel => accumulated_mouse_scroll.delta.y / 16.0,
	};

Any reason it was done this way?

[alice-i-cecile]

This is how the code was when I found it 😅

[IQuick143]

While this is correct in being invariant under splitting of scroll between frames. I question the meaning of scroll_factor I can't make out a reasonable set of units for it.

If we treat former line 196

controller.walk_speed += scroll * controller.scroll_factor * controller.walk_speed;

As a differential equation (in the limit of infinite FPS), where scroll becomes a speed instead of a fixed amount:

d/dt [controller.walk_speed] = d/dt [scroll] * controller.scroll_factor * controller.walk_speed;

Assuming the scroll velocity to be constant, the integral of this is:

controller.walk_speed = exp(total_scroll * controller.scroll_factor) * INITIAL controller.walk_speed;

So this translates to code as:

controller.walk_speed *= exp(scroll * controller.scroll_factor);

In this case it's obvious that controller.scroll_factor has units of 1/[unit of scrolling], it might be any* number and negative scroll_factors simply invert the effect.
*IEEE754 restrictions apply

In the current code scroll factors less than -1.0 do something very weird and silly (0.0^scroll? -0.5^scroll? I don't know what floats you're getting out of that), and the inverse to scroll_factor is actually 1/(1+scroll_factor) - 1.

Suggested change

	controller.walk_speed *= powf(1.0 + controller.scroll_factor, scroll);
	controller.walk_speed *= exp(controller.scroll_factor * scroll);

controller.scroll_factor is thus the inverse amount of scroll needed to scale the speed by e, or simply the rate at which scroll affects the speed.

We could also do

Suggested change

	controller.walk_speed *= powf(1.0 + controller.scroll_factor, scroll);
	controller.walk_speed *= powf(2.0, controller.scroll_factor * scroll);

If a base 2 exponential is more intuitive, somehow. (It just scales the units on scroll_factor)

[IQuick143]

PS:

The two methods are equivalent, in the sense that you can convert:
controller.scroll_factor (in the suggested method)
to
exp(controller.scroll_factor) - 1.0 in the old one, I find that to be a really weird parametrisation though.

[BigWingBeat]

scroll_factor is intended to be a percentage change. So with the default value of 0.1, each scroll delta increases or decreases the value by 10%. This is basically the same code I use to control a camera zooming in/out, as it's the same situation with wanting the perceived rate of change to be the same regardless of the size of the value being changed.

[IQuick143]

What is "a scroll delta" though?
Also I would argue "increases or decreases by 10%" is misleading, you may increase by 10%, but you're decreasing by 9.09...% instead.

[BigWingBeat]

I'm not sure the scroll delta can really be qualified beyond just "the number reported by the hardware". On my mouse at least, it seems to correspond to the "notches" in the scroll wheel.

Regarding the scaling factor, I did actually briefly use the form you are suggesting, but I changed it because reasoning about percentage changes was much more intuitive for me than whatever unit it is in your suggested form (As in, how easy it was to "predict" the relationship between a given value and the perceived magnitude of effect it has on the resulting scroll behaviour).