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

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.

Added subscriber: @MichalDresner

Added subscribers: @brecht, @ZedDB

@brecht can you reproduce this?

Added subscriber: @stephane

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.

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

Added subscriber: @PrototypeNM1

@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?

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

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.

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

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