Walk/fly navigation doesn't work with graphic tablets #65559

New Issue

Michał · 2019-06-06T13:29:53+02:00

Michał commented

2019-06-06 13:29:53 +02:00

System Information
Operating system: Windows 10
Graphics card: GTX1070
Tablet: Wacom Intuos4 L

Blender Version
Broken: (example: 2.80, 0efe89bdd8, 2019-06-03), 2.79

Short description of error
When using fly or walk navigation with a graphic tablet (in absolute mode, not mouse mode) the controls don't respond properly, the view just rotates chaotically. For reference, Unreal Engine interprets pen input well for FPS-type control, using offset from initial pen position.

Exact steps for others to reproduce the error
In 2.8 press shift-tilde, try navigating with the mouse, then do the same using a graphic tablet.

**System Information** Operating system: Windows 10 Graphics card: GTX1070 Tablet: Wacom Intuos4 L **Blender Version** Broken: (example: 2.80, 0efe89bdd810, 2019-06-03), 2.79 **Short description of error** When using fly or walk navigation with a graphic tablet (in absolute mode, not mouse mode) the controls don't respond properly, the view just rotates chaotically. For reference, Unreal Engine interprets pen input well for FPS-type control, using offset from initial pen position. **Exact steps for others to reproduce the error** In 2.8 press shift-tilde, try navigating with the mouse, then do the same using a graphic tablet.

Michał commented

2019-06-06 13:29:53 +02:00

Added subscriber: @MichalDresner

Sebastian Parborg commented

2019-06-14 10:30:40 +02:00

Added subscribers: @brecht, @ZedDB

Brecht Van Lommel was assigned by Sebastian Parborg

2019-06-14 10:30:40 +02:00

Sebastian Parborg commented

2019-06-14 10:30:40 +02:00

@brecht can you reproduce this?

Brecht Van Lommel removed their assignment 2019-09-25 16:38:55 +02:00

Stephane Messerli commented

2019-11-05 21:27:53 +01:00

Added subscriber: @stephane

Stephane Messerli commented

2019-11-05 21:27:53 +01:00

Update 2020-06-15 - The problem I described below is not related to my Wacom tablet in any way. I finally pinned the root cause to be a custom Xorg "Coordinate Transform Matrix" mapping the mouse DPI to the monitor.

The Xorg bug can be found here: https://gitlab.freedesktop.org/xorg/xserver/-/issues/633

To summarize, a custom coordinate transform matrix affects relative mouse move events sent by Xorg. A fixed offset is added to those relative move events, while they should be 'centered' around (0,0) on average. This creates the rotation drag effect in Blender walk mode that I described below, but it's definitely not a Blender problem.

Hi,

I have a similar problem on Ubuntu 18.04, but somehow my Wacom tablet seems to temporarily solve the problem instead of causing it.

I can't use the walk navigation mode with my Logitech mouse: moving the mouse results in some fast and uncontrolled up/right field of view rotation. Fly mode is not affected, only Walk mode is.
When I connect my Wacom tablet and use the pen for a fraction of a second, "something" is reset and the mouse then functions correctly, without the initial rotational drift.
If I leave the walk navigation mode and re-enable it, the drift occurs again until I move the tablet pen a bit.

I suspect that the absolute vs relative mouse coordinates handling is the source of the trouble.
As a side note, I've experienced the same kind of issues with the mouse handling of the SDL graphic library in the past, on both Linux and MacOS.

This weird behavior happens with Blender 2.80 and 2.81 beta. Versions 2.79 and older are working fine in Walk mode.
Since the normal 3D view and the Fly mode are not affected, something must be done differently with the mouse input in the Walk mode that causes the issue.

Edit: mouse input is indeed read in absolute mode after using the tablet pen, with no wrapping happening (mouse is not recentered after a move event is received). Would the relative position (used before using the table pen) be returned with a non zero (x,y) value to start with, that would induce the observed rotational drift.

**Update 2020-06-15** - The problem I described below is **not related to my Wacom tablet** in any way. I finally pinned the root cause to be a custom Xorg "Coordinate Transform Matrix" mapping the mouse DPI to the monitor. The Xorg bug can be found here: https://gitlab.freedesktop.org/xorg/xserver/-/issues/633 To summarize, a custom coordinate transform matrix affects relative mouse move events sent by Xorg. A fixed offset is added to those relative move events, while they should be 'centered' around (0,0) on average. This creates the rotation drag effect in Blender walk mode that I described below, but it's definitely not a Blender problem. ----- Hi, I have a similar problem on Ubuntu 18.04, but somehow my Wacom tablet seems to temporarily solve the problem instead of causing it. I can't use the walk navigation mode with my Logitech mouse: moving the mouse results in some fast and uncontrolled up/right field of view rotation. Fly mode is not affected, only Walk mode is. When I connect my Wacom tablet and use the pen for a fraction of a second, "something" is reset and the mouse then functions correctly, without the initial rotational drift. If I leave the walk navigation mode and re-enable it, the drift occurs again until I move the tablet pen a bit. I suspect that the absolute vs relative mouse coordinates handling is the source of the trouble. As a side note, I've experienced the same kind of issues with the mouse handling of the SDL graphic library in the past, on both Linux and MacOS. This weird behavior happens with Blender 2.80 and 2.81 beta. Versions 2.79 and older are working fine in Walk mode. Since the normal 3D view and the Fly mode are not affected, something must be done differently with the mouse input in the Walk mode that causes the issue. Edit: mouse input is indeed read in absolute mode after using the tablet pen, with no wrapping happening (mouse is not recentered after a move event is received). Would the relative position (used before using the table pen) be returned with a non zero (x,y) value to start with, that would induce the observed rotational drift.

Brecht Van Lommel commented

2020-02-11 17:52:39 +01:00

I can confirm walk/fly doesn't work well for tablets, probably it was never really tested or tweaked for that case.

Nicholas Rishel commented

2020-11-02 22:50:13 +01:00

Added subscriber: @PrototypeNM1

Nicholas Rishel commented

2020-11-02 22:50:13 +01:00

@MichalDresner can you test if the issue still exists in Blender 2.92 Alpha ?

With the above build, can you check with the Tablet API set to Wintab and again set to Windows Ink?

@MichalDresner can you test if the issue still exists in [Blender 2.92 Alpha ](https://builder.blender.org/download/blender-2.92.0-316a5914bcc6-windows64.zip)? With the above build, can you check with the `Tablet API` set to `Wintab` and again set to `Windows Ink`?

Nicholas Rishel self-assigned this 2020-11-02 22:52:13 +01:00

Nicholas Rishel commented

2020-11-02 23:01:52 +01:00

Changed status from 'Confirmed' to: 'Needs User Info'

Nicholas Rishel commented

2020-11-14 01:54:49 +01:00

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

Thanks again for the report. If the problem persists please open a new report with the required information.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed. Thanks again for the report. If the problem persists please open a new report with the required information.

Nicholas Rishel commented

2020-11-14 01:55:20 +01:00

Changed status from 'Needs User Info' to: 'Archived'

Nicholas Rishel closed this issue

2020-11-14 01:55:20 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Walk/fly navigation doesn't work with graphic tablets #65559