First nonzero mouse_delta_ndc() is very large

[kbarros]

I put the following line of code in my win.update() loop:

println!("{:?}", win.input.mouse_delta_ndc());

At first, the program prints exactly Vector2 [0.0, 0.0]. Once the mouse moves, I first get a single very large delta, of order 0.5. And then after that, mouse motion gives meaningful deltas, of order 0.001 (corresponding to a few pixels of movement).

I would have expected that all return values of mouse_delta_ndc() correspond to actual mouse deltas.

[vitvakatu]

To fix this, we probably need to store initial mouse position on Input initialization, or (less likely) move pointer in the center of the screen. @kbarros don't you want to try to fix that? I can provide you all the neccessary help.

[kbarros]

Yes, I can try to help.

It seems the best way would be to store mouse position on Input initialization, but I can't see how to get this information from glutin. (There are methods like glutin::Window::set_cursor_position but I can't find any get_cursor_position.)

Another option is to store f32::NAN for the initial values of mouse_pos and mouse_ndc. Then we could have logic to drop the first mouse delta.

[vitvakatu]

Heh, indeed. There's no method to get mouse position (without using event loop). Okay, then we should try approach with setting cursor to the center of the window on start. I don't like idea with NaNs, it seems harder and possibly more dangerous.

[kbarros]

It seems unfortunate that we should have to move the cursor to fix a bug that very few people will run into :-) If you don't like NaNs, a semantically equivalent option is to put the mouse_pos and mouse_ndc within Options to indicate that they are not initially valid.

[vitvakatu]

Well, you can try, but I think the internal structure of our code will be overengineered then. The approach with moving cursor will envolve a very small code injection in one place, while you'll need to change a lot of logic to use Option or NaNs

[kbarros]

The necessary changes are actually quite minimal: https://github.com/kbarros/three/commit/faf9e58f8cc685c8f420327e961939d58adfd6e4

Note that we may wish to change Input::mouse_pos() and Input::mouse_pos_ndc() to return an Option, which indicates that three-rs does not necessarily know the mouse position. (Alternatively, we could simply return (0,0) for this case.)

[kbarros]

On second thought, maybe this should be closed as "won't fix" until glutin gets the ability to query the mouse position?

[kvark]

We can keep it for tracking, marking as blocked for now.