Plonq / bevy_panorbit_camera

A simple pan and orbit camera for the Bevy game engine
Apache License 2.0
186 stars 36 forks source link

mouse_delta in pan_orbit_camera fn yields unexpected values and movements #32

Closed CarbonFlora closed 1 year ago

CarbonFlora commented 1 year ago

Context (Environment)

I am running the multiple_viewports.rs example in dev mode. I am interacting with the GUI through Windows Remote Desktop Connection. A println!("mouse delta: {}", mouse_delta); was added on line 420 in lib.rs.

Behavior

I am presuming the mouse delta shouldn't spike to the tens of thousands. With these current delta readings, the camera orbits and pans in sharp and unexpected directions and intensities.

Possible Fix

This is most likely a problem with bevy_input as opposed to bevy_panorbit_camera. I haven't taken a deep looked into bevy_input to source the problem. Never posted an issue before, lmk if there's a better place to post this issue.

Log

Compiling bevy_panorbit_camera v0.7.0 
(D:\rust\bevy_panorbit_camera)
    Finished dev [unoptimized + debuginfo] target(s) in 11.00s
     Running `target\debug\examples\multiple_viewports.exe`
2023-08-17T17:03:43.722274Z  INFO bevy_winit::system: Creating new window "App" (0v0)
2023-08-17T17:03:44.608741Z  INFO bevy_render::renderer: AdapterInfo { name: "NVIDIA GeForce GTX 1650", vendor: 4318, device: 8066, device_type: DiscreteGpu, driver: "NVIDIA", driver_info: "531.61", backend: Vulkan }
2023-08-17T17:03:45.439330Z  INFO bevy_diagnostic::system_information_diagnostics_plugin::internal: SystemInfo { os: "Windows 10 Pro", kernel: "19045", cpu: "Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz", core_count: "8", memory: "15.8 GiB" }
// Note: Program Running
mouse delta: [27699, 28732]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [0, 0]
mouse delta: [27733, 29036]
mouse delta: [0, 0]
mouse delta: [27733, 28975]
mouse delta: [27733, 28914]
mouse delta: [0, 0]
mouse delta: [55466, 57343]
mouse delta: [27733, 28489]
// Note: Program Stopped
Plonq commented 1 year ago

Hi there. mouse_motion comes directly from the event reader, so you are right in that this is likely an issue upstream. However, it's also possibly an issue with Windows Remote Desktop - e.g. maybe the input jitter/spikes are an artefact of the network and how RDP mirrors the mouse motion. That actually sounds like the more likely culprit.

A few things to try to narrow this down:

  1. Try to replicate without using RDP
  2. Try to replicate via RDP with a plain bevy app that just prints mouse motion
  3. Try to replicate via RDP using winit by itself and printing out its mouse motion events

If you can't replicate in 1 and can replicate in 2 and 3, then that strongly suggests it's RDP that is sending spiky mouse movement rather than a bug in the tech stack. It could theoretically be a bug in how winit interprets events from the OS, but that seems unlikely to me.

CarbonFlora commented 1 year ago
  1. I ran multiple_viewports.rs without Windows Remote Desktop Connection, and it operates flawlessly. I will try 2 & 3 next week to help diagnose the root cause of the problem. Thanks for your help.
Plonq commented 1 year ago

Closing this as it's not related to the plugin