OpenXR-SDK-Source
OpenXR-SDK-Source copied to clipboard
KhronosGroup
[bug] Please fix the forced haptics around 0.5 grip value.
Hello,
When the grip value reaches around 0.5, OpenXR forces a haptic pulse. This is not suitable for anyone who has customised their grip thresholds, and further is not suitable when nothing was grabbed.
As this behaviour has already shipped with a whole bunch of games, please add some setting that we can use to disable it in future projects.
I find this forced haptic to feel quite wrong and wanted to see if there's any chance of resolving it before I convert my project to use SteamVR.
This sounds like a problem specific to a runtime or an engine, not the standard itself or its software library. What apps and runtimes show this behavior?
Hello and thank you for your response.
I have been told by another developer that this occurs in every OpenXR game they have tried.
In my experience, I played Bonelab just yesterday, which uses OpenXR. It has the haptic pulse around 0.5 grip, even when not grabbing anything. I played using Index controllers and Vive HMD through SteamVR.
It also occurs in my own game that I am developing with Unity.
If this issue is unfamiliar, I'm sure I could share a sample Unity project. I am aware that Bonelab is also Unity, but to the best of my knowledge this is an OpenXR issue. If a sample would help, please let me know.
Thanks again.
EDIT: Accidentally closed the issue but noticed the button to reopen when checking on my desktop.
OpenXR itself does not control this, so it sounds like a SteamVR issue, or a Unity issue. You should be able to control the threshold and haptics through the remapping UI in SteamVR.
I'm not sure the SteamVR Input UI is functional at all for OpenXR games, which is actually another reason I was considering going back to SteamVR; and this would control haptics on the whole - I just need to remove the errant pulse when gripping. I will ask other developers for more information, such as whether it occurs on Quest.
I haven't been able to get any further input.
I have no means of testing other runtimes as I only have my Vive and Index controllers which are SteamVR native devices.
I do believe this is an issue with OpenXR. Perhaps someone will come across this in the future and share whether or not it occurs on Rift S, Quest, or others.
Hello and thank you for your response.I have been told by another developer that this occurs in every OpenXR game they have tried. In my experience, I played Bonelab just yesterday, which uses OpenXR. It has the haptic pulse around 0.5 grip, even when not grabbing anything. I played using Index controllers and Vive HMD through SteamVR.If this issue is unfamiliar, I'm sure I could share a sample Unity project. I am aware that Bonelab is also Unity, but to the best of my knowledge this is an OpenXR issue.Liam Foot -------- Original message --------From: "Ryan A. Pavlik" @.> Date: 01/10/2022 18:07 (GMT+00:00) To: KhronosGroup/OpenXR-SDK-Source @.> Cc: Liam Foot @.>, Author @.> Subject: Re: [KhronosGroup/OpenXR-SDK-Source] [bug] Please fix the forced haptics around 0.5 grip value. (Issue #337) This sounds like a problem specific to a runtime or an engine, not the standard itself or its software library. What apps and runtimes show this behavior?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>
Hey thanks for your question! This is intentional behavior on the part of SteamVR. You can change the behavior using the extension XR_VALVE_analog_threshold: https://registry.khronos.org/OpenXR/specs/1.0/html/xrspec.html#XR_VALVE_analog_threshold
You mentioned you only have access to Valve supported hardware, but this extension does not exist on other popular runtimes. During execution, be sure to check that the active runtime supports this extension before trying to use any of its structs or functions.
Thanks very much! I don't have experience with this but I will research how I can use this through Unity and then report back.
I think I sent that email comment 10 days ago - it seems to have just gone through.
An issue (number 1870) has been filed to correspond to this issue in the internal Khronos GitLab (Khronos members only: KHR:openxr/openxr#1870 ), to facilitate working group processes.
This GitHub issue will continue to be the main site of discussion.
Closing as known runtime behavior (not against the spec) and controllable by developers via an extension.