gui: fix zoom-to-mouse

[buzzhuzz]

Plater disappeared when zoom-to-mouse enabled and user tries to zoom
with a side view enabled (Ctrl+<3..6>).

Mouse/screen center position estimation in 3D is made by calculating
intersection of a mouse vector which comes 'through' the screen with an
XY plane. However, when screen is parallel to Z axis, intersection point
located at infinite which results in infinite camera translation vector.

This change switches mouse position estimation to use of projection
matrix like its done for camera panning.

Fixes #4797, #4579, #3615

[buzzhuzz]

I've only tested Linux build on a 1920x1280 and 3840x2560 screens with several window sizes.

Needed some additional testing on a variety of screens and platforms.

[buzzhuzz]

I really don't like compare value twice, but I couldn't find better way to check absolute value limits.

[discip]

@buzzhuzz

First of all: Thank you so much for taking this on! 👍

Unfortunately the zoom to mouse does not work after ctrl + (3, 4, 5, 6).
Or is that by design? 😅

setup

CPU	GPU	RAM	SSD
Ryzen 9 7950X3D	XFX 7900 XTX	G.Skill Flare X5 32 GB	Samsung 990 Pro 2 TB

[liftbag]

@buzzhuzz Thank you so much! Your build works correctly in my case.

macOS Sonoma 14.4.1 (23E224) on MacMini 2023 Apple M2 Pro.

Registrazione.schermo.2024-04-02.alle.22.47.27.mp4

[buzzhuzz]

Unfortunately the zoom to mouse does not work after ctrl + (3, 4, 5, 6).
Or is that by design? 😅

This is intentional and mentioned in PR description. This change aimed to have working application by limiting zoom functions in some use-cases. Zoom-to-mouse started working if you rotate parts plane by some amount.

Current implementation of zoom-to-mouse implemented like this:

• it estimates to estimate position of the screen center and mouse cursor on the parts plane
• calculates camera translation vector and translate camera by this amount

Problem happens when the screen plane is parallel to Z-axis. In this case current code can't find position of either screen center nor mouse cursor as viewing vector never intersects parts (XY) plane returning vectors which has infinity coordinates. And because of this infinite camera translations makes it impossible to get parts plate back into screen. Another use-case is really small angle of XY plane view which results in really big translation vectors like (10^6,10^20) - this too could move view port far away.

Proposed solution checks if translation vector has reasonable values and falls back to zoom-to-center logic if it's not. Once you get parts plate to an angled position, zoom-to-mouse starts working as usual.

One more point of request for testing is to get public feedback. There should be way completely re-implement zoom-to-mouse logic to get rid of this fundamental flaw, but it may require some time for me to get into details of 3D rendering and camera handling on current code base.

[buzzhuzz]

@discip , could you check updated version.

I've found an easy way to fix the issue keeping zoom-to-mouse for all cases including Ctrl+<3..6>

[discip]

@buzzhuzz

Thank you!

That definitely did the trick! 👍

But there is still some annoyance regarding the the ctrl + (3-6) action.

1. If you open a project you need to click into the window which contains the plate with the object in order to make the ctrl + (3-6) action work, otherwise nothing happens.

2. If you happen to zoom to mouse position and your mouse is not directly over the object the mentioned shortcut leads not to the expected view (not absolutely normal to the corresponding view [X-Z, Y-Z]).
   In order to look dead center along either the X-/Y-axis you first need to press ctrl + 7.

I hope I made myself clear enough. 😅

btw:
I was not able to find a solution searching the internet for a fix of the following issues:

1. Any chance you could look into making the 3Dconnexion SpaceNavigator work on Linux (Manjaro GNOME) for OrcaSlicer like it does on Windows? Don't know if this is related in any way, but you seem quite capable! 😊

2. Could you also look into the weird popup every time OrcaSlicer is started?

   

thank you very much in advance
kind regards

[buzzhuzz]

Thank you for testing.

I've seen both of those issues.

1. This one really annoys me. The problem is that input focus does not set to the 3D canvas automatically.
2. That one caused by the design of zoom-to-mouse feature. Which translates the world when you zoom with your cursor being off-center. Should be not so hard to fix.

As for additional requests:

1. I don't have any of 3dconnexion devices. However, I probably could borrow one over a weekend at ME department on my work.
2. I've set "remember my choice" once and never see this one again. Somehow that checkbox missing on your screen.
   
   I could look into missing checkbox if I could reproduce this issue.
   As a workaround you could try to add/set "tls_cert_store_accepted" to "yes" in `.config/OrcaSlicer/OrcaSlicer.conf
   

[discip]

Thank you very much!

I don't have any of 3dconnexion devices. However, I probably could borrow one over a weekend at ME department on my work.

That would be really great!

As a workaround you could try to add/set "tls_cert_store_accepted" to "yes" in `.config/OrcaSlicer/OrcaSlicer.conf

Will do as soon as I get home again!

[buzzhuzz]

If you happen to zoom to mouse position and your mouse is not directly over the object the mentioned shortcut leads not to the expected view (not absolutely normal to the corresponding view [X-Z, Y-Z]).

That one should be fixed in f941a92

If you open a project you need to click into the window which contains the plate with the object in order to make the ctrl + (3-6) action work, otherwise nothing happens.

I'd like to move it into own issue since it is more about general input events handling in the app globally rather than camera position. For example: if you click to any test field on the left pane and modify value there by entering value and pressing either Return or Tab, you'll end up with the same issue: keyboard events not reaching 3D view.

[discip]

That one should be fixed in f941a92

Thank you, will test later. 😃👍

I'd like to move it into own issue since it is more about general input events handling in the app globally rather than camera position. For example: if you click to any test field on the left pane and modify value there by entering value and pressing either Return or Tab, you'll end up with the same issue: keyboard events not reaching 3D view.

Do as you wish, Sir.

[discip]

2. I've set "remember my choice" once and never see this one again. Somehow that checkbox missing on your screen.

I tried to click in the area where the tick should have been, and sure enough there was one, except not visible because the text and box seem to be white.

That one should be fixed in f941a92

That worked absolutely flawlessly! 👍

While you're at it, there's one more thing that could be adjusted, unless it's intentional:
It's the 3D Navigator driven view.
Maybe you could also edit it so that the object is centered?
Since @Noisyfox is the creator of that gizmo, I think it's best to let him decide whether this is a good idea or not.

[buzzhuzz]

@discip,

regarding your issue with popup on application start: I can't reproduce it on my end, so I've tried to do my best trying to solve it blindly. Could you please check if https://github.com/buzzhuzz/OrcaSlicer/actions/runs/8540040433 gets "Remember my choice" checkbox visible for you? Also, you may create an issue for this bug so every affected user may track the progress and test fixes on their side.

Regarding the 3D cube gizmo. I've found a way to fix it. However, the more I dig into this, the more use cases I see (including user input using 3d mouse devices) which might be affected by a simple fact that the world gets translated on zooming to a mouse cursor. I'd like to take a break and weight two approaches: going down a rabbit hole fixing all possible scenarios risking break something and re-implementation of core zoom-to-mouse logic.

[buzzhuzz]

Converted PR to a draft. The reason is in previous comment.

[discip]

regarding your issue with popup on application start

1. Will test.
2. As you helped me to get it remembered, I'm good with the current situation.

I'd like to take a break and ...

That is definitely a good idea.
While making the suggestion I had similar doubts and therefore I tagged the original developer.

including user input using 3d mouse devices

1. I could test that case (using a 3D mouse) but only for Windows.
2. Maybe you could get spacenavd to work for OrcaSlicer so I would be able to test it on my Linux machine too 😊.

As the testing phase might take some time I suggest to split this PR into the part that is already working, which could get implemented already and the part that still needs to be polished.

[buzzhuzz]

I have reverted latest change which made Ctrl-<1..6> focus on a build plate. Reason for this is to make behavior consistent for all use-cases including camera panning (RMB+move) which moves target point in 3d space. Target point is a point camera focused to.

My thoughts are next:

• if you pan camera, you may want to look to some point on 3D scene, rotate camera around that point and so on
• zoom-to-mouse is essentially combination of camera panning and zoom which results in the same behavior: you moves your focus towards some point in space.

As for 3D view gizmo and camera angles: they are setting camera view in regard to a current focus point. Because of this, I consider correct rotating around some point in space which is not on a build plate.

I totally get that using rotate gizmo and camera angle shortcuts may be inconvenient in some cases, but same happens for simple camera panning.

I could suggest adding some shortcut to switch focus point into a build plate (or even selected objects) which could make life a little easier, like this:

focus-key-demo.mp4

[SoftFever]

Looks good.
Thank you very much!