You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to the docs, the XR_HAND_TRACKING_AIM_VALID_BIT_FB in XrHandTrackingAimFlagsFB indicates that "Aiming data is valid". But it's ambiguous what valid means in this case: my initial assumption was that invalid data would be garbage and unusable, but while integrating support for this extension in Chromium I found that it actually seems more akin to indicating whether the aim pose passes some threshold of certainty. Just occluding the index and/or thumb is enough to make this bit report 0, but the actual aimPose being returned is (functionally) still usable for the majority of rotations, the main exceptions being when the hand is turned towards the user or at an extreme angle.
The text was updated successfully, but these errors were encountered:
An issue (number 2175) has been filed to correspond to this issue in the internal Khronos GitLab (Khronos members only: KHR:openxr/openxr#2175 ), to facilitate working group processes.
This GitHub issue will continue to be the main site of discussion.
According to the docs, the
XR_HAND_TRACKING_AIM_VALID_BIT_FB
inXrHandTrackingAimFlagsFB
indicates that "Aiming data is valid". But it's ambiguous what valid means in this case: my initial assumption was that invalid data would be garbage and unusable, but while integrating support for this extension in Chromium I found that it actually seems more akin to indicating whether the aim pose passes some threshold of certainty. Just occluding the index and/or thumb is enough to make this bit report 0, but the actual aimPose being returned is (functionally) still usable for the majority of rotations, the main exceptions being when the hand is turned towards the user or at an extreme angle.The text was updated successfully, but these errors were encountered: