lonetech
commented
7 years ago Neither is any more correct until Valve bother to document either behaviour for OpenVR, in my not so humble opinion. Even then, that behaviour applies to OpenVR; I'm curious to know which variants exist in VRPN, WebVR, Google VR, OSVR and so on. There isn't a touch position when there is no touch, so there's no natural logic to reporting one.
Centering makes sense for an interface emulating a joystick, such as perhaps Revive.
Are we trying to imitate behaviour of other drivers? What is the behaviour for e.g. the Daydream APIs?
In looking at documentation for APIs from Google, Oculus (the most limited as it appears the "precise" data reported is 4-direction swipe) and Valve I don't see that any of them have documented a position for when there is no touch.
Found in another (not proofread, as there are copy/paste artifacts speaking of touchpad under app button) documentation of Google VR Controller API that Daydream does retain last position, as the recent nolo-osvr driver does (by not reporting it, which at least leaves the timestamp to indicate it's old).
I'm in favour of collecting information on what implementations are actually doing and adjusting documentation to match. That said, if that end software expects 0 it might be appropriate to report that value in nolo-osvr if we're already putting in a branch (as the decision to not report a change is).
The issue on the table is how to handle the trackpad values when the trackpad isn't being touched. Currently, the controller hardware sends a sentinel value of 255 to signal that the trackpad isn't being touched. When normalized, this value becomes exactly 1. Until the most recent commit, this value was passed through to OSVR even when the trackpad wasn't being touched. This meant that, for example, in some SteamVR games that use the trackpad, the game would act as if the player was touching the trackpad even though they weren't, because those games do not explicitly check for trackpad touch - they simply read the value.
The latest commit has changed the behavior so that the axis only updates when the trackpad is touched, This is a reasonable idea in theory, but after testing it leads to a "sticky" axis. That is, when not touching the trackpad the XY axes simply continue to appear as the previous value.
This seems to be intentional behavior in OSVR, however it appears that in SteamVR this is not intended. Either the device is expected to report a "null" value of some kind when the trackpad isn't touched, or it is supposed to report as centered. The documentation here seems to indicate that the touchpad should always report between -1 and 1; there is apparently no "null" option. Since OSVR will always pass some axis value, it makes more sense for the value passed to be zero when the touchpad isn't pressed, rather than the last value (not explicitly reported, but an artefact of not reporting a new value) or the sentinel value.
The solution is to have the Nolo-OSVR driver report 0 when it detects the edge value that indicates no trackpad touch. Alternatively, the SteamVR-OSVR driver could be made to look for the
controller/hand/trackpad/touchpath and report 0 for the XY axes in the event that touch is false. I am not sure which of these methods would be more "correct". Thoughts?