OpenXR: Fix small hand tracking issues #82722
Conversation
| hand_trackers[i].aimState.pinchStrengthIndex = 0.0; | ||
| hand_trackers[i].aimState.pinchStrengthMiddle = 0.0; | ||
| hand_trackers[i].aimState.pinchStrengthRing = 0.0; | ||
| hand_trackers[i].aimState.pinchStrengthLittle = 0.0; |
There was a problem hiding this comment.
What's the alternative for retrieving this data now?
There was a problem hiding this comment.
The new hand interaction extension (#81533) replaces this functionality in a generic cross platform way.
We never actually implemented the old FB only extension in Godot 4, this code was copied over from Godot 3 without adding all the additional logic.
(do note that the middle/ring/little pinch functionality was not added in the generic solution, if anyone actually uses this, I suggest we move this functionality into a GDExtension as it is very unlikely to be adopted more broadly)
modules/openxr/openxr_interface.cpp
Outdated
| OpenXRHandTrackingExtension *hand_tracking_ext = OpenXRHandTrackingExtension::get_singleton(); | ||
| if (hand_tracking_ext && hand_tracking_ext->get_active()) { | ||
| for (int i = 0; i < MAX_OPENXR_TRACKED_HANDS; i++) { | ||
| OpenXRInterface::Tracker *tracker = find_tracker(i == 0 ? "/user/hand/left" : "/user/hand/right"); |
There was a problem hiding this comment.
This looks fragile. A better approach would be to move the logic below into a function that takes in the XrPath:
handle_hand_tracking("/user/hand/left");
handle_hand_tracking("/user/hand/right");
There was a problem hiding this comment.
We could, but it'll still remain index based as it's hardcoded in the spec that we just access the two hands in hand tracking.
It is us in this case that map hand tracking to the xrPaths which is something I never got why when the hand tracking API was added to OpenXR, wasn't how it worked in the first place.
I'm guessing because while the OpenXR spec focussed on the left hand and right hand, and any controller held would be bound, to a lot of XR runtime implementations treating /user/hand/left not as the left hand, but as the left controller. This likely because it was the approach common before OpenXR changed it. This has led to a lot of issues that were only corrected since the 1.0.28 OpenXR spec, and still has a few left over edge cases in certain XR runtimes.
There was a problem hiding this comment.
Ok, let me know what you think of how I changed it.
|
Ok, did some more testing with this and it resolves pretty much all the issues I was encountering. I even had the Valve hand meshes working properly with hand tracking natively on the Quest Pro, which is something that never worked before (did all sorts of weird mesh deformation). |
BastiaanOlij
force-pushed
the
openxr_fix_hand_tracking_issues
branch
from
9cc30e0
to
c60ef33
Compare
akien-mga
changed the title
|
Thanks! |
This PR fixes a number of long outstanding issues with hand tracking:
xr/openxr/extensions/hand_trackingis a new project setting that enables the hand tracking extension. As existing projects assume this is already enabled, the default is true. But this allows the user to disable this extension if they do not want to use it. Some platforms require the user to accept hand tracking when used.XR_FB_HAND_TRACKING_AIM_EXTENSION_NAMEextension, this was never fully implemented in Godot 4 as this was being superseded byXR_EXT_HAND_INTERACTION_EXTENSION_NAME. We are adding the new OpenXR standard functionality in Add support for OpenXR hand interaction extension #81533XRController3Dnode was never properly implemented, we add support here. Note that OpenXR - add access to hand joint validity flags #82715 should be merged so we can add confidence here correctly. I suggest we merge this and fix this in 82715 before merging that.OpenXRHandsnow also updates the position, not just the orientation, of the bones.There is a demo project (WIP) that can be found here that tests the functionality:
godotengine/godot-demo-projects#973