KhronosGroup / KhronosGroup/OpenXR-Docs
No consistant way to obtain hand and finger positions when controllers are used
- Dominant language
- Python
- Stars
- 181
- Forks
- 74
- PR merge metrics
- No merged PRs in 30d
Description
Currently only SteamVR (and possibly WMR) will provide an inferred hand skeleton through the hand tracking API when controllers are used that will allow a game developer to correctly position the players hand and fingers in relation to the controller.
Other platforms require the game developer to implement this themselves when controllers are used but there are a number of problems with this approach:
1) OpenXR does not define a specification for where the hand should be placed in relation to the controller, the grip pose does not seem usable for this.
2) OpenXR does not define a specification for retrieving controller dimensions that allow the game developer to properly place fingers, for instance differences in sizes between Touch, Quest 1 and Quest 2 controllers leads to issues in properly placing fingers on buttons.
3) OpenXR does not define a specification for obtaining raw input of the controller, this leads to issues for game engine builders who wish to implement this logic but where the game developer may define an action map that does not not provide access to the needed inputs.
Having the XR runtime provide a skeleton that allows the game developer to properly place the hands regardless of whether physical hand tracking is used or if the hand and finger positions are inferred from controller tracking and input, would ensure portability between the different platforms and solve the need for game developers to know much more about the XR system used than is currently provided and for which previous decisions exist that access to the needed data is unwanted.
There are however a number of shortcomings in the specification that need to be addressed:
1) Obviously the OpenXR specification needs to require inferred hand tracking from controller positions is uniformly supported.
2) While OpenXR defines a specification for the required bones and their relations, differences in interpretation between the different platforms prevents portability between the platforms. A properly skinned hand for SteamVR, will not work properly for Oculus nor WMR. More clarity is needed in the specification to ensure the different XR runtimes return a hand skeleton that is usable with the same 3D asset
3) OpenXR does not define a specification that allows the user to know whether physical hand tracking is used or whether the hand tracking is inferred. This can be important if hand tracking is used for direct interactions between the hand and game world. Inferred finger positions can lead to sudden positional changes when the user lets go of a button on the controller so the game developer needs to be able to react accordingly.
4) OpenXR does not define a specification that allows the game (engine) developer to deal with the difference in hand sizes between players that is pulled through when physical hand tracking is used. Multiple options are possible from ignoring the players hand size and re-targeting to a predefined uniform hand, to offering an option for the XR runtime to provide a properly skinned hand asset that matches the players hand size.
It would be great if the OpenXR specification could deal with these issues so true portability between platforms is possible.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reviewing the OpenXR specification sources and the issue's four requested areas: inferred hand tracking, skeleton consistency, tracking provenance, and hand-size handling. Done would require an agreed specification change that addresses the portability and runtime-behavior concerns described here; no specific files or tests are named.
Written by the indexing model from the issue text.
Assessment
- Domain
- ar-vr-xr
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100