search

Stellarium / stellarium

Stellarium is a free GPL software which renders realistic skies in real time with OpenGL. It is available for Linux/Unix, Windows and macOS. With Stellarium, you really see what you can see with your eyes, binoculars or a small telescope.
https://stellarium.org
GNU General Public License v2.0
7.35k stars 802 forks source link

point mirroring results in odd mouse behaviour #3653

Open axd1967 opened 4 months ago

axd1967 commented 4 months ago

Expected Behaviour

When enabling both horizontal and vertical mirroring, mouse movements should remain intuitive

Actual Behaviour

Mouse movements are inverted too

Steps to reproduce

System

Logfile

If possible, attach the logfile log.txt from your user data directory. Look into the Guide for its location.

gzotti commented 4 months ago

Cannot reproduce with Qt6-based build, and we should have seen this by around 2015 with Qt5. What OS is that?

alex-w commented 4 months ago

Cannot reproduce with Qt6-based and Qt5-based builds in linux (Ubuntu 22.04.4 LTS)

axd1967 commented 4 months ago

Cannot reproduce with Qt6-based build, and we should have seen this by around 2015 with Qt5. What OS is that?

(issue edited, info added)

gzotti commented 3 months ago

I find numerous reports of weird mouse behaviour on KDE Plasma, wayland vs. X11, etc. Probably not our bug.

axd1967 commented 1 month ago

Note: to avoid zenith lock, make sure the test starts without zenith in the centre. (See below about this.)

This also happens in normal mode (without any mirroring).

Dragging the bottom half vertically works normally, dragging any point in the upper half (striped line) inverts the movement .

Dragging left/right also has issues: eg. dragging something a bit below 9 o'clock towards the left actually drags the view down.

Rotational inputs (as opposed to radial movements) seem to work fine everywhere.

image

To me this feels like a coordinate transformation issue; anyhow, it is not natural.

The requirement should be "I want to drag the selected point where I want"; in other words, the selected grip point should always remain under the mouse cursor.

For example: I want to center on a constellation that is currently physically in my back.

  1. switch to "almost" zenital view
  2. select a constellation in the top half of the screen (which has objects behind the observer)
  3. you should be able to drag it from top to bottom to a point in the bottom half without "losing" it.

Note that this works fine when rotating (i.e. (anti)clockwise dragging) the view around the zenith: but you may not change the radial distance (to Z) while doing so.

About the zenith lock: observe that it is not possible to drag beyond zenith. This also feels like an unnecessary software limitation, most probably meant to avoid ending up "upside down" (which would be the case; in other words, having a view elevation of more than 90 degrees).

Can someone on Windows confirm/invalidate this?

axd1967 commented 1 month ago

Further analysis: what happens in fact is

When dragging purely radially away from Z, the view pans down. (and towards Z = up.)

(in eq mount mode, read NCP instead of Z in the above)

10110111 commented 1 month ago

Dragging the bottom half vertically works normally, dragging any point in the upper half (striped line) inverts the movement .

I can confirm that this has existed for many years. Ideally, the point held by the mouse at the start of motion should simply follow the cursor (with some clamping of amplitude of motion when this would imply roll in addition to pitch&yaw). But current implementation indeed works the way you describe.

About the zenith lock: observe that it is not possible to drag beyond zenith

This is just as sensible a limit as the lack of roll control. And if roll is added, there would be no need to extend the limits, since all the possible camera orientations would become available.

gzotti commented 1 month ago

This is the way the program has worked since 2008 and probably earlier, and millions of users have learned to deal with it. Yes, you cannot drag the sky around picking a single star and keeping the mouse cursor attached to that star. So what? There are at least no unexpected kinks while dragging the sky around. Whoever is rewriting StelMovementMgr may attempt solving this, but I indeed like to have an UP vector orientation and zenith limit based on current coordinate frame (add ecliptical, galactic and other frames!), and no upside-down or sideways-rolled screens.