Page MenuHome

Walk navigation using tablet - repositioning the stylus rotates the view
Confirmed, NormalPublicBUG

Description

System Information
Operating system: Windows-10-10.0.14393-SP0 64 Bits
Graphics card: GeForce GTX 1060 6GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 456.71

Blender Version
Broken: version: 2.92.0 Alpha, branch: master (modified), commit date: 2020-12-18 09:26, hash: rBfe5d2448c6e1
Worked: unknown

Short description of error
This is a follow-up to T83718. Specifically addressing this comment - T83718#1075294 by @Pascal (PMA33).

The problem is when using a tablet in a walk navigation, lifting and repositioning the stylus is handled as if the stylus has been moved to the new position in range. This makes the view rotate a lot, making the walk navigation only usable when the stylus doesn't leave the range height.

Exact steps for others to reproduce the error

  1. In 3D Viewport execute the walk operator (ViewNavigationWalk Navigation).
  2. Use tablet to rotate view.
  3. Lift the stylus out of range.
  4. Reposition it to considerable distance and get it in range.

Result: The view rotates a lot, as if the stylus has been moved to the new location.

Expected: View doesn't move, new stylus location is assumed a new reference point.

Possible Fix

First of all, we need to reset walk->is_cursor_absolute when going from absolute to relative. Because currently, as long as a tablet has been used once, during the walk modal running, walk->is_cursor_absolute will stay absolute (even if a relative pointing device is used afterwards).

diff --git a/source/blender/editors/space_view3d/view3d_walk.c b/source/blender/editors/space_view3d/view3d_walk.c
index 665d704e6b2..79f66cb9e48 100644
--- a/source/blender/editors/space_view3d/view3d_walk.c
+++ b/source/blender/editors/space_view3d/view3d_walk.c
@@ -705,12 +705,12 @@ static void walkEvent(bContext *C, WalkInfo *walk, const wmEvent *event)
     }

     if ((walk->is_cursor_absolute == false) && event->tablet.is_motion_absolute) {
-      walk->is_cursor_absolute = true;
       copy_v2_v2_int(walk->prev_mval, event->mval);
       copy_v2_v2_int(walk->center_mval, event->mval);
       /* without this we can't turn 180d */
       CLAMP_MIN(walk->mouse_speed, 4.0f);
     }
+    walk->is_cursor_absolute = event->tablet.is_motion_absolute;
 #endif /* USE_TABLET_SUPPORT */

     walk->moffset[0] += event->mval[0] - walk->prev_mval[0];

Second we'll need a (reliable) relative position event when a tablet goes out of range so the absolute coordinates get re-centered each time the tablet goes in range. For that we can send a dummy mouse move event on WT_PROXIMITY, when not inRange.

diff --git a/intern/ghost/intern/GHOST_SystemWin32.cpp b/intern/ghost/intern/GHOST_SystemWin32.cpp
index 7e800619dda..e375b99cb41 100644
--- a/intern/ghost/intern/GHOST_SystemWin32.cpp
+++ b/intern/ghost/intern/GHOST_SystemWin32.cpp
@@ -1614,6 +1614,10 @@ LRESULT WINAPI GHOST_SystemWin32::s_wndProc(HWND hwnd, UINT msg, WPARAM wParam,
         case WT_PROXIMITY: {
           bool inRange = LOWORD(lParam);
           window->processWintabProximityEvent(inRange);
+          if (!inRange) {
+            /* Send a dummy mouse event to be able to detect that the tablet went out of range. */
+            event = processCursorEvent(window);
+          }
           break;
         }
         case WT_PACKET:

Not sure if this (second part) is an acceptable solution, maybe there's a more elegant one. Maybe @Nicholas Rishel (nicholas_rishel) can take a look. Also, I have no idea how this behaves on the other platforms. I tested this with WinTab only. Triaging help on other platforms is appreciated.

Note that the proposed fix doesn't work well if the stylus went in range not over the Blender window. Those events may also be handled if this is a way to go.

Event Timeline

Hi @Vincent Blankfield (vvv) thanks for the report and the patch. Could you please send the proposed fix as a patch? You can either use arcanist or https://developer.blender.org/differential/diff/create/ .

Then @Nicholas Rishel (nicholas_rishel) can take a look at it and if things work, commit to master or provide feedback for changes.

Philipp Oeser (lichtwerk) changed the task status from Needs Triage to Confirmed.Dec 22 2020, 1:28 PM
Philipp Oeser (lichtwerk) added projects: Restricted Project, User Interface.

@Nicholas Rishel (nicholas_rishel) : From reading here and in D9899, I assume this can be confirmed?

Nicholas Rishel (nicholas_rishel) edited projects, added Platform: Windows; removed Restricted Project.Dec 24 2020, 11:13 AM
Bastien Montagne (mont29) changed the subtype of this task from "Report" to "Bug".Mar 1 2021, 3:56 PM